摘要

  • 对 9 月 11 日冻结的 Hosted DNS 名册逐行计算，可得 48 条 AuthDNS 记录：43 条为运行状态，5 条已退役。这是部署库存的可复核结果，不是获得更短路径或更强韧性的解析器群体数量。
  • RIPE NCC 自己的测量给出了最好的反例：地理上位于巴林的节点主要由沙特阿拉伯的探针访问；身处巴林 Batelco 网络的探针反而几乎从不选择它。

绿色状态只回答一个问题

“Operational”并非空洞标签。公开名册把一个节点编号与服务类型、地点、托管机构、主机名以及部分完成日期连在一起，也把仍在运行的实例与已退役实例分开。对于分布式基础设施，这比只有圆点、没有状态和责任人的地图可靠得多。

本篇冻结的页面共有 48 条 AuthDNS 记录，其中 43 条运行、5 条退役。运行节点 #523 位于米兰，由 LAKENETWORKS 托管，页面记录的完成日期是 2026 年 6 月 18 日；#520 位于柏林，由 BCIX Management GmbH 托管，日期是 7 月 28 日。RIPE NCC 的第三季度计划在 6 月 11 日更新，两次完成都发生在该日期之后。

但时间先后不能自动变成因果关系。公开材料没有说明两项申请何时启动，也没有说明它们是否因第三季度计划而设，更没有指出各自准备填补哪一个已测量的覆盖缺口。因而，43 这个数字可以稳妥回答“冻结时有多少条 AuthDNS 托管节点被标为运行”，却不能回答“有多少接入网因此改走了更近的 anycast 路径”。

计划的计量单位本来就不是城市

《DNS and K-root Quarterly Planning》的 Q3 2026 项目称，RIPE NCC 要改善 AuthDNS 在代表不足地区的覆盖；理想落点是一个国家的大型接入网、与大型接入网对等互联的网络，或者能够连接多方的 IXP 端口。项目状态为进行中。

这些标准描述的都是网络拓扑。大型接入网之所以重要，是因为它承载大量用户和递归解析器；对等关系会改变路由偏好；IXP 路由服务器可以让同一个服务前缀更直接地被多个自治系统看到。城市名称只能说明设备在哪里，不能说明 BGP 会把谁送到那里。

计划页面没有公开覆盖不足国家或网络的分母，没有目标解析器群体、时延门槛、流量占比，也没有判定一个缺口已经关闭的观察期。这并不能证明内部没有工程指标，只能说明外部读者尚无法把公开目标与公开节点逐项连接，重算交付结果。

一个服务，两种部署层

AuthDNS 从 AS197000 宣告 193.0.9.0/24 和 2001:67c:e0::/48。它服务于 in-addr.arpa 与 ip6.arpa 下的反向 DNS 区域、ripe.net、其他 RIR 的基础设施域名、受支持机构的区域，以及部分国家和地区顶级域的辅助 DNS。

其公开架构分成核心与托管两层。阿姆斯特丹、伦敦、斯德哥尔摩和东京的四个核心站点用路由器把查询分发给多台服务器，并混合运行 BIND、Knot DNS 与 NSD。托管节点补充核心容量，通常是在 ISP 网络或互联网交换中心中的单服务器实例。

两层不能混为一个数字。托管实例可以让某些路由更短，却不因此拥有核心站点的服务器和软件多样性；核心站点可以很稳健，却未必是某个解析器群体的优选目的地。“节点”“服务器”“站点”“捕获范围”和“韧性”是五种不同的账目。

巴林节点并不拥有巴林流量

RIPE NCC 在 2024 年已经展示过更合适的验证方法。那项 RIPE Labs 研究从东南欧、中亚和中东的 RIPE Atlas 探针出发，每 30 分钟向 193.0.9.7 查询一次 150.6.0.193.in-addr.arpa，记录由哪一个 AuthDNS 服务器应答，并按探针、按日期汇总，同时观察往返时延中位数。

东南欧的大量探针走向阿姆斯特丹；波斯尼亚和黑塞哥维那、特别是罗马尼亚更常命中本地节点，但仍有探针持续走向堪萨斯城或巴林。研究称当时中亚没有 AuthDNS 实例，观测到的大部分查询前往阿姆斯特丹或斯德哥尔摩。

最能校正地图直觉的是麦纳麦。STC Bahrain 在巴林托管一个节点，但它主要被沙特探针使用。巴林 Batelco 的 AS5416 内部探针几乎从不命中这个近在地理上的节点；Saudi Telecom Company 的 AS25019 探针却在整个观测期持续选择它。对沙特探针而言，这也是较好的路径：往返时延中位数低于 50 毫秒，而走向欧洲约为 100 毫秒，走向委内瑞拉或关岛则更长。

这不是巴林节点失败的证据。恰恰相反，它说明 anycast 节点真正交付的是 BGP 捕获范围。宣告、偏好、对等互联和上游结构共同决定查询落点；机房的邮政地址既不给它划分服务领地，也不保证同城网络会选中它。

对等互联规则揭示了机制

AuthDNS 的公开对等策略称 AS197000 总体采取开放政策。核心站点和 IXP 托管节点从交换中心路由服务器接受不小于 IPv4 /24、IPv6 /48 的前缀，并向路由服务器宣告自身前缀。RIPE NCC 鼓励使用路由服务器及过滤社区；直接对等需满足规定条件，托管 IXP 节点只在没有路由服务器时考虑直接对等。

这些规则说明，同一个物理节点可能获得很宽的有效覆盖，也可能只吸引窄小群体。托管机构名称不是 peer set。公开名册没有逐节点给出托管网络 ASN、实际路由服务器参与情况、进入的解析器群体，或者启用前后的选择变化。

完整公开所有拓扑也不是合理要求。私人对等关系会变化，安全敏感细节不应为编辑便利而暴露。需要的是汇总、限界且可复核的结果证明，而不是网络全景图。

缓存让分母比地图更小

Hosted DNS FAQ 还提醒，绝大多数 DNS 查询由缓存回答。对已经良好互联的网络，本地托管节点的收益可能很小，甚至不可察觉；只有很小一部分相关高层区域查询真正抵达 root 或 AuthDNS。某些反向查询可以因此加快，但不能把一个节点包装成“所有 DNS 都更快”，也不能推导出明显的上游带宽节省。

运营责任同样分层。托管方提供符合规格的服务器或充足的虚拟机、专业托管环境、冗余供电、物理安全和连接，并承担成本；RIPE NCC 远程管理。若 RIPE NCC 发现节点或可达性异常，服务器会撤回前缀，让查询转向其他 DNS 服务器。

撤回路由可以在机房不动时改变捕获范围；新增对等也可以在不添服务器时扩大覆盖。库存变化与路由结果有不同的时钟。

为覆盖另开一张回执

现有节点名册应当保留。它适合证明部署存在和状态变化。与之并列的覆盖回执可以更小，却要对应计划中的实际目标：绑定节点编号或区域部署批次、目标地理范围和初始缺口；引用 RIPE Atlas 测量编号、探针纳入规则和观察窗口；比较启用前后应答节点分布与时延；列明验收条件、例外、样本漂移和代表性限制。

回执不必公开私人 peer，也不必暴露单个解析器。它只需把五个结论分开：库存证明实例存在；可达性证明某个观察点得到应答；捕获范围说明 BGP 选择谁；时延描述特定窗口的路径；韧性检验节点或路由消失后剩下什么。43 不能同时代表五者。

因此，43 条绿色记录不是对 RIPE NCC 的指控。它们是一套已经可用的第一本账；而计划自己要求的，是第二本账。

来源