摘要

  • RIPE 93 的 RootViz 演示称，2026 年 1 月 22 日至 26 日，约 2000 个 RIPE Atlas 探针经 IPv4 访问 L-Root 时出现超时；22 日两个十分钟窗口的对比中，有 1773 个探针只在事件窗口超时。
  • 研究人员追查发现，受影响探针此前连接的 L-Root 任播站点仍能被其他网络访问；演示将问题定位在网络路径上。

监测屏报警很快，找出该叫谁来修路却花了好几个小时。RootViz 在 RIPE 93 公布的原始演示中，把这个落差摆在了台面上。

研究团队回看一月的 L-Root 数据：22 日起，大约 2000 个探针的 IPv4 查询陆续超时，到 26 日才恢复常态。IPv6 和其他根服务器标识的同期曲线没有同样的跳升。团队还把 22 日凌晨 04:00—04:10 与 13:00—13:10 UTC 两个窗口并排，数出 1773 个只在后一个窗口超时的探针。这个数字记录的是测量点，不是断网人数。

RootViz 用的是已经在运行的 RIPE Atlas 测量。它筛去网络栈失效的探针和服务器标识不符的答复，以半小时为单位汇总超时探针。团队对 5 月 6 日的测量视角作过比较：全体探针有 14,528 个，DNSMON 锚点为 999 个；覆盖国家数分别为 180 和 109。 RIPE NCC 的原始测量目录把编号 10308 列为针对 L-Root 的 IPv4 UDP 定期查询。视野扩大十四倍，屏幕上的红灯更难被漏看，灯却不会指出坏在哪一段。

研究人员接着追查这些探针原来连接的任播站点。事件期间，其他网络仍能到达那些站点；路径追踪和路由核对把问题指向中间网络。演示没有为一月事件点名一个已经证实的上游责任方。ICANN 自己的说明确认它运营 L-Root，因此告警天然先落在它头上；但数据包走过的每条路不归它管理。

真正需要设计的是跨机构的故障记录：哪个地址族异常，哪些探针受影响，其他根标识怎样，原先的站点是否仍可达，路径在哪一跳失去回应。把这些字段和调查时间一同公布，运营者才能接过属于自己那一段的维修单。否则，最容易被看见的名字，就会先成为最容易被责怪的名字。

原始资料：RIPE 93 RootViz 演示、RIPE Atlas 内置测量目录、ICANN 根服务器说明。