摘要

  • 一项列入 RIPE 93 的研究测量七家大型 NTP 时间服务。Microsoft拥有十二个服务器地址，但约九千个 RIPE Atlas 观测点中，超过一半收到的 DNS 回答只有一个地址。
  • 另一次由四个 GPS 校时测点进行的实验中，三个Microsoft服务器曾连续数小时出现时钟偏差，其中一个达到约 40 至 50 毫秒。论文所列安全协议示例可以容忍这一幅度。

墙上挂满钟，柜台却只递出一张号码牌。接过号码牌的电脑不知道隔壁还有多少钟，也无从拿第二个读数校验第一个。SIDN Labs 发表的原始论文在RIPE 93 日程上亮出的，正是这个小小的分配动作。

研究团队查看Microsoft、Apple、Google、Ubuntu、AWS、Cloudflare 和 Meta 的时间服务。三家使用 IP anycast，另外四家主要由多个单播地址提供服务。服务器总数看起来是冗余，客户端收到的名单才是实际选择。团队从约九千个 RIPE Atlas 观测点查询Microsoft时间服务；过半地点的 DNS 答案只列一个服务器地址。这里的分母是测试点，量到的是各地查询时收到的答案。

RFC 8633建议使用多个独立时间来源。只给一个地址，客户端遇到离谱的读数时，就缺少对照。论文作者建议Microsoft至少为每个客户端返回四个地址。测量时它已有十二个服务器地址，所以这一要求首先指向 DNS 的选派规则：门后的钟够多，柜台该多递几张票。

研究还测了钟本身。四处以 GPS 同步的测点，在 2025 年 5 月至 2026 年 6 月间安排多轮二十四小时实验。一次实验里，三个Microsoft服务器连续数小时偏时，其中一个约偏 40 至 50 毫秒。论文明确说明，文中举出的 TLS、DNSSEC 和 RPKI 等安全协议可以承受这个偏差。真正值得问的是：如果下一次偏差大得多，而设备手上只有一个来源，它凭什么识别？

SIDN Labs 的论文目录把扩展版列在 2026 年 10 月。研究也逐项检查 IPv6、DNSSEC、RPKI 与 RFC 8915 定义的 Network Time Security。在观测窗口内，七家之中只有 Cloudflare 同时部署四项；Ubuntu 也支持 NTS。屏幕上那串时间没有显示这些选项，决定这些选项的人却很具体。