摘要

  • 在“不返回任何响应”的条件下，APNIC Labs 对 116,050,253 个测试名观察到 9,685,775,212 次权威查询。按公开总数复算，每次测试为 83.46 次；正向对照为 3.43，NODATA 为 3.93，NXDOMAIN 为 4.40，REFUSED 为 11.47，SERVFAIL 为 51.73。
  • 这张矩阵证明，在本实验中，响应状态与抵达权威端的负载高度相关；它没有证明重复查询来自终端、stub、转发层、递归引擎、resolver farm，还是多个层级共同作用。
  • 原文正文与汇总表有两处平均值不一致。公开计数足以复算结果，却不足以替作者决定原意。任何运营判断都应保存分子、分母、公式、拓扑与“归因未知”状态。

精确的总数没有带来精确的责任人

APNIC 在 9 月 4 日发布的报告里给出 9,685,775,212 这个总数。它来自权威服务器保持沉默的实验条件。表一同时给出 116,050,253 次测试；两数相除是 83.4619。

算式到这里完全清楚，产生算式的路径却并不透明。

实验通过在线广告里的脚本，让终端解析一个随机且唯一的名字。这个请求可能先交给本机的 stub，再发往一个或多个已配置的递归服务；中间还可能有转发器、前端分发器和后端解析引擎。引擎会选择服务器地址和传输，也可能合并相同请求，或者再次发送。

APNIC 的日志位于这条链条末端。它知道哪些查询抵达自己，却不会随包收到一份经过签名的上游决策记录。因此，“一个解析器对每个名字问了 83 次”不是原始事实，而是一项额外推断。把所有额外查询叫作“重传”也不准确：现代终端可能分别查询 A、AAAA 与 HTTPS，这三项是不同类型，并非同一包重复三次。

实验单位是唯一测试名，不是一次人的点击、一次应用解析、一次 stub 事务或一次可识别的递归事务。新数据的价值正在于这个明确边界：它是一张权威端负载账，不是一张逐层问责账。

六种结果对应六档负载

随机名字排除了同名旧缓存直接回答的可能。测试区没有 DNSSEC 签名；一台双栈权威服务器同时支持 UDP 和 TCP，不提供 DoT 或 DoH。响应体很短，不涉及截断。一次广告触发后的 24 小时内，抵达服务器的查询都进入计数。

根据公开总数复算：

权威端状态 测试数 查询数 每次测试查询数 相对正向对照
正向 A/AAAA 对照 254,894,985 875,316,423 3.43 1.00×
NOERROR/NODATA 115,571,398 454,213,932 3.93 1.14×
NXDOMAIN 115,750,503 509,410,787 4.40 1.28×
REFUSED 115,415,259 1,324,355,211 11.47 3.34×
SERVFAIL 138,643,924 7,171,673,166 51.73 15.06×
无响应 116,050,253 9,685,775,212 83.46 24.30×

这不是简单的“肯定”和“否定”之差。正向回答与两种确定的否定回答都在每次测试约四次附近；REFUSED 明显升高；SERVFAIL 与沉默进入另一个数量级。

语义可以解释这种顺序为何合理。NXDOMAIN 表示名字不存在；NODATA 表示名字存在，但没有所问类型。REFUSED 表示服务器基于策略拒绝处理。SERVFAIL 只表示处理失败，仍留下换服务器、换地址、换传输或稍后重试的可能。沉默连这一层分类也没有，只能由计时器决定下一步。

然而，“这个结果可能诱发探索”不等于“已知谁进行了探索”。表格没有区分软件、配置、队列、请求合并方式，也没有给出均值背后的分位数。51.73 与 83.46 是这个实验的描述值，不是固定写进 DNS 协议的倍数。

合理的基线本来就不等于一次查询

在 NXDOMAIN 组里，48% 的终端同时问了 A 和 AAAA，51% 只问 A，1% 只问 AAAA；另有 39% 产生 HTTPS 查询。按这些类型组合，如果每种只问一次，APNIC 估算应有 2.18 亿次查询。

实际是 509,410,787 次，超出的 291,919,927 次被归为重复。115,750,503 次测试中，有 67,316,541 次对所用每个类型最多只发一次；剩余 48,433,962 次测试承载全部重复量，平均为 6.03 次。

分母若写得不清楚，会出现两种相反误判。把包数直接减去测试数，会把 A、AAAA、HTTPS 的并行需求算成重试；只看最终是否获得答案，则会抹掉近 2.92 亿次重复工作。

覆盖范围也属于分母。样本来自 Google Ads 能触达的区域，报告明确说俄罗斯是主要例外。它带来广泛视野，却不是全体互联网用户与解析器的概率抽样。单台双栈服务器是受控工具，不是常见的多 NS、多运营方权威服务。未签名、无加密、短响应的设置减少了变量，并不能代表加入 DNSSEC、TCP、加密或多服务器后一定得到什么结果。

原文自己的两个数字也需要凭据

SERVFAIL 段落把 51.29 写成每次测试的查询均值，把 51.59 写成发生重复时的均值。公开总数并不支持这个对应关系。7,171,673,166 除以 138,643,924 是 51.7273，表一将其写成 51.73。扣除 3,702,576 次“每种类型仅一次”的测试后，剩 134,941,348 次；6,920,490,780 次重复除以它是 51.2852，对应表中的 51.29。

无响应段落又把测试数排成 11,6050,253，并给出 82.6 的总均值。表一写 116,050,253 与 83.46。9,685,775,212 除以表中分母是 83.4619；重复数除以 113,531,062 个发生重复的测试，则是 83.3822，与表中 83.38 相符。

不应默默沿用正文数字，也不应据此宣布整个实验失效。公开的原始计数和公式可以把排字、标签错误与测量错误分开。只有作者能够说明本来想写哪一个数；读者能够确认的，是哪些数由现有总量推出。

这也映射了更大的问题：一个看似完成的平均值不能替代其来源。分子、分母、排除条件、公式和版本都是证据的一部分。

2019 年的线索不能自动继承为 2026 年的结论

APNIC 在 2019 年对 NXDOMAIN 重复现象做过更细的时间分析。报告看到了来自同一表面解析器地址的重复，也看到了共享地址前缀的一组来源轮流发问，并讨论 Happy Eyeballs、丢包、激进计时器、转发集中与 resolver farm。按 IPv4 /24 或 IPv6 /48 分组被明确称为近似方法。

这些机制都可能存在，却不能给 2026 年汇总数据补上一项确定归因。一个可见地址可能代表多个引擎，多个地址也可能属于同一服务。终端配置的两个递归地址可能最后汇入同一后端。上一项查询尚未结束时，重复任务可能已进入另一个队列。问题与回答任何一边都可能丢失。

新报告本身保留了疑问：它询问重复来自递归实现，还是来自前端分发与后端引擎构成的复杂系统。严谨的报道应保留这个问号，而不是替它填入一个熟悉的软件类别。

微软的官方文档只是一条有界示例。Windows 客户端在沉默时会按已配置 DNS 地址数量安排再次查询，而 Name Error 会停止该路径。但 APNIC 没有证明样本运行 Windows，也没有在终端内部观察这套时序。实现文档证明一种机制可存在，不能证明它解释了另一项实验的汇总值。

标准限制重试，却不能替权威日志补写来源

RFC 9520 要求：同一查询发往同一服务器地址、使用同一传输时，在首次发送后最多重试两次。解析失败还必须缓存至少一秒、至多五分钟，使匹配的新需求在这段时间内不再生成上游查询。

这是抑制故障风暴的明确规则，不是远端归因工具。解析器仍可尝试另一地址或兼容传输；多个客户端请求可以合并为一次递归过程，一次客户端动作也可能经多个系统扩散。权威端计数无法仅凭自身辨认这些边界。

RFC 2308 为 NXDOMAIN 与 NODATA 规定负缓存，也保留较早的服务器故障缓存边界。RFC 8914 允许 Extended DNS Error 携带诊断信息，但明确不得改变 RCODE 的处理。这些机制让失败更可解释，不会让未观测的因果层凭空出现。

响应语义更不能当作降流量旋钮。为了少收查询而故意返回错误的 NXDOMAIN 或 NODATA，会把负载控制变成错误的命名事实。合法的调整应发生在真正拥有计时器、路径选择、请求合并和失败缓存的层，并在本地验证用户成功率、时延与恢复。

下一份测量至少要保存什么

首先应保存实验起止、触发渠道、覆盖缺口与精确单位；列出预期查询类型，再定义何为超额重复。随后记录响应的线格式、服务器数量、地址族、anycast 状态、支持与实际观察到的传输、DNSSEC、响应尺寸和截断。

均值旁边要有原始总量、公式、舍入与分布。更重要的是，未观测字段应保持未知。如果没有分别观测 stub、转发与递归引擎，就不应把它们的贡献估成一个确定比例。

在受控且保护隐私的环境里，运营者可以分别计数客户端请求、已合并请求组、递归事务、同一地址/传输组合的重试，以及改走其他路径的尝试。若无法建立这种托管链，结论便应停在权威边界。

APNIC 已完成艰难的第一步：不同失败状态的成本差异不再可以忽略。下一步不是给“风暴”换一个更强烈的词，而是让测量真正指出哪一层行使了哪一种重试权。

来源