Summary

  • APNIC 刊载的实验里，Geoff Huston 用空缓存的 BIND 9.20.23 查询 www.potaroo.net，从根区一路走到最终地址，共发出四次查询。
  • 查询 teams.microsoft.com 时，Huston 的 BIND 9.20 轨迹是 94 次；文中另记 BIND 9.16 的 247 次和 9.21 的 29 次。版本与条件不同，数字说明路径复杂度，不是同场竞速。

一台刚启动的递归解析器，手里只有根服务器的起点，没有后来积累的捷径。Huston 是 APNIC 首席科学家，他把自己的本地 BIND 放到这种状态，追踪 www.potaroo.net。解析器先问根，再问 .net，随后找到 potaroo.net 的名称服务器，最后拿到目标地址。四次问答，账目清楚。

换一个名字，账目就不再适合写在便签上。Huston 的记录引用 Ondřej Surý 的实验：BIND 9.16 为 teams.microsoft.com 发出 247 次查询；Huston 在 9.20 上看到 94 次，Surý 在 9.21 上看到 29 次。不能把三组数字直接当作软件升级的提速率。它们来自不同的解析器版本和测试条件，却共同揭开了一个事实：屏幕上的一个名字，背后可以是一串需要分别查找的名字。

其中四级 CNAME 把解析重新启动了多次，形成五段解析。有的别名仍落在已知的区域里，可以借用刚学到的信息；有一段把查询带回 .net。委派也只告诉解析器“该问谁”，未必直接给出“怎样找到他”。如果名称服务器就在被委派的区域内，glue 记录可以把地址一并交出；若服务器名字散在不同域甚至不同顶级域，解析器又得先替这些服务器找地址。

DNSSEC 验证再添上密钥查询。解析器还要选择是否预先收集更多备用服务器信息：多问一些，故障时可能多一条路；少问一些，正常情况下更快抵达。域名发布者决定别名和服务器的摆法，全球各处的递归解析器执行首次到访的工作。热缓存把这笔跨机构成本藏起来，Huston 把它翻了出来。

这份轨迹没有测出全球平均延迟，也没有证明某次服务故障。要断言具体运营损失，还缺相同配置下的耗时与故障测试。但它已经足以让域名设计会议多一道问题：配置表里轻轻加的一跳，准备让多少刚启动的解析器重新跑一遍？