摘要

  • APNIC 报告 Table 1 显示：SERVFAIL 每次测试平均触发 51.73 次权威端查询，完全无响应则是 83.46 次；NXDOMAIN 为 4.40，NOERROR/NODATA 为 3.93，正向对照为 3.43。
  • 实验记录的是抵达权威服务器的数据包，并未贯穿浏览器 stub、本地转发器、递归解析器前后端、备用地址和传输路径。原作者也明确把重复查询的成因留给后续研究。
  • RFC 9520 要求缓存解析失败并限制重试，却允许换服务器、地址或传输继续尝试。管理层需要的是分层重试预算和可追溯证据，而不只是一个超时总数。

“再试一次”没有唯一的发令者

浏览器里的广告脚本只触发一次随机域名解析。到了权威 DNS，这个意图可能已经展开成 A、AAAA 和 HTTPS 多种查询。终端 stub 有计时器，家庭网关可能转发，递归平台可能由前端分配到多个后端，后端还会换权威地址或从 UDP 转向 TCP。每一层都可以认为自己的重试很克制，合起来却形成没人认领的流量。

Geoff Huston 在 9 月 4 日发表的 APNIC Blog 报告把这种叠加摆上了表格。APNIC Labs 借在线广告向终端投放脚本，请求其解析实验域名下随机生成、此前不可能命中同名缓存的名字，再统计实验权威服务器收到的查询。

结果按响应语义分成明显的阶梯。正向回答每次测试平均 3.43 个查询；表示名字存在但所问记录类型不存在的 NOERROR/NODATA 是 3.93；表示名字本身不存在的 NXDOMAIN 是 4.40；政策性拒绝 REFUSED 升至 11.47；信息含糊的 SERVFAIL 达到 51.73；完全沉默则达到 83.46。

这不是把六种状态换成六个同义标签。明确的否定可以进入缓存并结束问题。REFUSED 告诉查询者服务器不愿回答，却不说明名字是否存在。SERVFAIL 只说当前无法给出答案，通常会被当成暂时故障。沉默连 DNS 层的判断都没有，只能让各级计时器决定是否继续。

大数是真的，责任人仍是未知数

原文自身有两处数字冲突。SERVFAIL 段落把每次测试平均查询写成 51.29；Table 1 则列为 51.73，并把 51.29 放在“平均重复次数”一栏。无响应段落把测试数写成 11,6050,253、均值写成 82.6；表格是 116,050,253 和 83.46。本文采用原文汇总表的数值，并保留这项披露，而不是把差异悄悄抹掉。

表格中的规模足够惊人：138,643,924 次 SERVFAIL 测试收到 7,171,673,166 个查询，其中 6,920,490,780 个被归为重复；只有 3,702,576 次测试在每种所用查询类型上各发一次。无响应测试收到 9,685,775,212 个查询，其中 9,466,474,491 个是重复。

可是，规模不会自动产生因果。权威服务器通常只看见递归系统送来的请求。它无法仅凭日志判断重复来自浏览器 stub、局域网转发器、递归前端、后端引擎、丢包、另一个客户端事件，还是规范允许的备用地址尝试。Huston 也把“是递归实现，还是更复杂的前后端系统”列为待解问题。

因此，实验直接证明的是：在受控响应条件下，权威端收到的查询数量分布截然不同。它没有证明每个 SERVFAIL 都会带来 51 次查询，没有证明某个产品应负责任，也不能把广告样本乘成全球 DNS 账单。

四次左右并不等于四次重试

NXDOMAIN 阶段在 2026 年 8 月 5 日至 11 日进行，共覆盖 115,750,503 个通过 Google Ads 招募的终端。作者称样本具有广泛的地理与平台多样性，并特别说明俄罗斯是主要缺口。

一次测试出现多个查询，首先可能是查询类型不同。48% 的终端同时查询 A 与 AAAA，51% 只查 A，1% 只查 AAAA；另有 39% 发出 HTTPS 查询。若每种已观察到的类型只查一次，预计约为 2.18 亿个查询，实际却有 509,410,787 个。两者之差 291,919,927 才被计作重复。57% 的终端没有超过每种类型一次；发生重复的那组终端平均产生 6.03 个重复查询。

实验边界同样关键。测试区域没有 DNSSEC 签名，因此解析器不能依靠 RFC 8198 的 NSEC/NSEC3 缓存证明，为其他随机名字直接合成否定回答。权威服务支持 UDP 与 TCP，不提供 DoT 或 DoH；回答很短，没有截断；广告投放后 24 小时内抵达的查询都计数。这些条件并不能说明终端到递归解析器使用了什么传输。

本次 NOERROR/NODATA 的 3.93 还略低于 NXDOMAIN 的 4.40。它值得继续研究，却不是为了省流量而互换响应码的理由。两者陈述的事实不同。RFC 2308规定其否定缓存，RFC 8020允许缓存中的 NXDOMAIN 终止对该不存在名字之下的继续查询。语义正确必须先于均值优化。

RFC 9520 约束一条回路，却没有消灭所有支路

2023 年发布的 RFC 9520之所以要求缓存 DNS 解析失败，正是因为事故早已证明失败会诱发更激进的解析行为。文中回顾了 Dyn 遭遇超过日常十倍的重试风暴、根 KSK 轮换期间 80 倍的 DNSKEY 流量、2021 年实验里某僵尸网络域名在 SERVFAIL 下从约 50 qps 升至 60,000 qps，以及 Facebook 故障期间 .COM/.NET 基础设施从 7,000 升至 900,000 qps。

该标准把有用的否定回答与解析失败分开。它要求缓存 SERVFAIL、服务器不可达和 DNSSEC 验证失败等结果；初始缓存时间至少一秒、最多五分钟，并采用可配置下限与退避。对同一个服务器地址和同一种传输，原始查询后最多再重试两次。

“同地址、同传输”就是边界所在。解析器仍可尝试其他权威服务器、其他地址或其他传输，也无法禁止更靠近客户端的层重新发起工作。所以，合并尚未完成的等价问题，与限制单一循环的次数同样重要。

RFC 8914 的 Extended DNS Error 可以解释 SERVFAIL 是过期数据、DNSSEC、政策或其他原因造成的，但它只是诊断信息，不得改变 DNS 处理。解释得更清楚，有助于定位故障；它不会把模糊失败变成“名字不存在”。

APNIC 的平台不是 APNIC 的政策立场

文章署名 Geoff Huston，并附有作者观点不一定代表 APNIC 的免责声明。APNIC 提供发布平台与 APNIC Labs 测量系统，并不意味着这份个人分析已经成为注册管理机构的政策。

这份报告足以支持运营商复现实验、检查重试分布、审计 RFC 9520 的实现，却不足以要求为了流量效率而改变 DNS 响应语义，也不足以裁定任何具名运营商不合规。