摘要

  • 2026 年 6 月 29 日起，DNS 根服务器运营方观测到查询量约为平时两倍：系统平均值从每秒约 160 万升至 320 万。
  • 一个相关自治系统的代表确认，流量来自其网络，并发生在近期递归解析器软件更新之后。报告称这是非预期结果，未发现根服务的可测量影响，也没有披露网络、供应商、版本或具体机制。

6 月 29 日协调世界时接近中午，DNS 根区收到的工作负载突然变了。根服务器运营方（Root Server Operators，RSO）报告称，系统平均查询量从每秒约 160 万升至 320 万。所有根服务器标识都观察到增长，多个都会区也出现高流量，尤以美国东海岸和欧洲明显；不同标识之间的幅度并不完全一致。

这不是一场由畸形报文堆出的流量洪峰。运营方看到的是格式正常、采用查询名最小化的请求，来自数万个源 IP 地址，主要查询 .com、.net、.org、.info 和 .uk。初步调查将流量指向若干相关自治系统。经过多次联络，其中一个 AS 的代表于 7 月 3 日确认，查询来自其自身网络，并非伪造源地址。该代表表示，近期递归解析器软件更新意外地产生了这一流量变化。

时间线也提醒人们不要把短暂回落当成问题已经解决。7 月 3 日流量下降了约两小时，之后又回到高位。7 月 6 日进一步沟通后，查询量从 7 月 7 日开始恢复正常。公开报告没有说明运营方是否暂停了发布、调整了配置、回滚了版本，或采用了其他修正方式。它把变化与软件更新联系起来，却没有披露是哪项代码或设置改变了查询行为。

抵达根区的一次查询，不等于一名用户查了一次域名。DNS 解析器会缓存答案；运营方 FAQ 解释，通常只有少量普通查询需要重新联系根服务器。因此，大型递归网络中的软件变化可以改变根服务器看到的工作负载，却不必与终端用户需求同步增长。报告没有判断用户是否察觉，也没有量化源网络内部的成本。

服务结论要按报告的范围理解：根服务器运营方没有发现可测量的可用性或性能影响。他们不认为这次流量是蓄意攻击或运营危险，因此没有采取缓解措施。这说明根系统承受了这次已观测事件，并不能证明任意流量增长都无害。报告引用 RSSAC001 的运营预期：各运营方应尽合理努力，为流量的大幅波动准备足够容量。

证据边界同样重要。“所有根服务器标识”说的是报告观察到的标识范围，不代表每个任播实例都承受了相同负载。关于递归解析器更新的归因来自某个 AS 代表确认，但报告没有给出该 AS、供应商、软件版本、配置变化或查询生成机制。报告提到查询名最小化，却没有说这一机制导致了流量翻倍。RFC 9156 说明缓存状态和域名层级可能改变解析器发出的查询数量；这只能提供背景，不能解释本次事件。

这既不是已证实的“攻击”，也不是“什么都没发生”。一次分布式软件更新改变了上游查询模式，根运营方观察到变化，与源网络的沟通随后先于流量恢复。管理层真正需要回答的是：下一次出现类似信号时，能否及时将其与某个发布批次关联起来，从而区分非预期的软件行为、恶意流量和容量问题。

来源