摘要

  • BigTime 的 2025 年测量结果于 RIPE 93 分享：在超过 9,000 个使用 Microsoft 时间服务的 RIPE Atlas 测点中，约一半从 DNS 收到一个 NTP 地址；研究列出的该服务 IPv4 地址共有 12 个。
  • RFC 8633 建议 NTP 客户端使用多个时间来源。DNS 地址数、Anycast 站点数和独立时钟数不是同一指标，一个数字不能替另一个作证。

时间设置平时安静得像空气，一旦错了却能让一整套系统吵起来。证书按时钟判断是否过期，日志靠时钟排列事件，缓存和密钥也要看时间。大多数人从不打开时间设置面板，直到出事。于是那个藏在系统设置后面的服务，掌握了一种很少被看见的权限。

研究者 Pascal Huppert 在 RIPE 93 介绍了 BigTime。它调查七家大型时间服务怎样部署服务器副本，又怎样把请求送到这些服务器。原始测量写在 2025 年发布的报告里。2026 年 10 月的演讲介绍了这批结果，没有在当月重做实验。一个发现把问题说得很直接：服务商说自己服务器很多，终端究竟能拿到几路时间源？

研究团队用 500 个 RIPE Atlas 探针检查 DNS 答案。每个探针每十分钟直接询问一次时间服务的权威 DNS，也就是负责给该域名作答的服务器，连续八小时。这样就不用依赖递归解析器替用户查询并缓存的结果。另一项分析查看每个客户端实际收到几个地址，覆盖超过 9,000 个 Atlas 测点。每个测点在 12 小时内直接查询 72 次，每十分钟一次。Microsoft 样本有 9,010 个测点。

在 9,010 个 Microsoft 测点中，约一半从 DNS 收到一个 NTP 服务器地址。报告同时列出该服务的 12 个 IPv4 地址。前一个数字是客户端拿到什么，后一个是服务方的地址库存。研究测的是 RIPE Atlas 样本，不是全球 Windows 电脑；Atlas 观察部分网络，不会逐台清点全世界的设备。

“复制”至少有几个不同层次。DNS 可以为同一个名字返回多个地址。Anycast 则让多个站点同时发布同一个地址，再由网络把请求送到其中一处。站点内部还可能有负载均衡器，把请求分给多台服务器。这些方法可以分流，也能应付部分故障；它们不会自动给客户端第二个时钟读数。

报告调查的七家服务也各有架构：三家使用 Anycast，四家使用单播地址。Huppert 说，团队无法排除站点内还有负载均衡器。因此，地址数不能当成机器数，也画不出各自独立的故障区域。测量能回答的是，样本里的客户端从 DNS 收到了什么。

RFC 8633 把这个架构问题拉到了客户端这一端。它建议 NTP 客户端接入多个时间来源，对比读数，保留可靠的来源并丢弃差的来源。文档还解释了 Anycast 的陷阱：一个地址背后可以是很大的分布式服务器池，但客户端看见的依旧可能只有一个来源。运营方若设置多个彼此分开的 Anycast 池，客户端就能比较多路读数，配置也仍然简洁。

服务商的地址总表和一台客户端能选什么，是两回事。一个地址后面可以有集群，帮服务商增加容量或在站点内切换机器。客户端仍拿不到第二个读数来核对。如果唯一来源出错，列表里没有独立的第二票。研究记录的是一种配置：DNS 只给一个来源时，客户端就无法按 RFC 8633 的建议进行多源对比。报告没有记录大范围时钟故障。

报告另做了一项精度实验，只用了两个接入参考时钟的测点；它们不属于大规模 DNS 样本。地址数量结论来自许多 Atlas 测点，精度实验只看了两个。现在还缺少一轮独立测量，直接检查各操作系统今天的默认配置。那才能说明 2025 年的结果是否仍适用于当前设备。

时间服务公开成绩单时，应分开报三个数字：客户端收到多少地址、这些地址能通到多少站点、客户端能比较多少个独立时间源。服务器地图能显示服务商的规模，却看不出终端手里有几路时钟读数。

来源