摘要

  • APNIC PING 在 9 月 3 日介绍了一项 2026 年 1 月完成的受控研究，它把普通根查询流量与维持本地根区副本的更新流量放在同一尺度上比较。
  • 四天测量中，采用 IXFR 的 BIND 日均每台解析器 4.35 MB，采用 DNS 更新的 Unbound 为 3.93 MB，Knot Resolver 每日一次 HTTPS 更新为 2.65 MB。
  • HTTPS 版 Unbound 测得 105.12 MB，是因为它每 30 分钟完整下载一次 2.19 MB 根区。研究明确记录这是已获确认的软件缺陷，不能当作 HTTPS 的固有代价。

测试环境里每天 12 时 06 分，有一台解析器完整取回根区。另两台先看序列号，变化后再接收增量。还有一台不管根区是否变化，每半小时都把整份文件下载一遍。

它们都可以被概括为“本地提供根区”，但四张流量账单完全不同。

APNIC PING 9 月 3 日发布的文章把这项差别带到台前。George Michaelson 与阿姆斯特丹大学项目作者 Ilyas Rahimi、NLnet Labs 的 Willem Toorop 讨论实验。这里的问题不是本地副本是否获得 DNS 根的管理权——它没有——而是日常小查询被区分配替代后，流量在哪里发生。

四种刷新方式，四个结果

Rahimi 的研究报告用“每台解析器每天多少 MB”统一两边。普通模式取 1 月 1 日至 7 日的 RSSAC002 数据；除 F-root 的 11.18 MB 异常高值外，多数根字母在 0.67 至 1.34 MB 之间。本地根区一边则来自 1 月 20 日至 23 日、受控虚拟环境里的数据包捕获。

本地根区配置 观测到的更新行为 日均 MB/解析器
BIND，经 DNS IXFR 序列号变化后传输，每日 2 至 4 次 4.35
Unbound，经 DNS IXFR 序列号变化后传输，每日 2 至 4 次 3.93
Knot Resolver，经 HTTPS 约每日完整更新一次 2.65
Unbound，经 HTTPS 每 30 分钟完整下载 105.12

BIND 每次增量约 1.45 MB，DNS 版 Unbound 约 1.31 MB。四天里根区序列号分别引发 2、3、4、3 次更新，因此每日总量随更新次数变化。这是“有变化才传”的账单。

Knot 选择了另一种交换：被测配置每天完整取回一次，四天平均 2.65 MB。它在本实验中最低，却不是普遍优胜者。更保守的更新频率意味着变化不一定马上进入本地副本。字节量与新鲜度必须一起评估。

105.12 MB 最容易被误读。被测 Unbound HTTPS 配置每次取回 2.19 MB，一天执行 48 次，因为它没有先判断序列号是否变化。报告称，开发者确认这属于缺陷，并预计改为先检查变化。APNIC 的说明也保留了这个边界。把数字写成“HTTPS 成本”，反而会丢掉实验最有价值的发现：重复完整下载由更新逻辑造成，不是传输协议强制要求。

不是部署公投

在选定窗口里，四个本地配置都高于论文使用的普通查询基线。这不等于“本地根区浪费流量”。本地测量只有四天，对照只有七天；研究测量字节，却没有测延迟、DNSSEC 计算成本、恢复复杂度，也没有给减少外部根路径依赖的价值定价。

“解析器数量”同样是近似值。论文把 RSSAC002 的唯一源地址当作解析器实例。NAT、IPv6 地址聚合与重复出现都会破坏一一对应关系。随后按约 5914 万台解析器计算的 TB/日，只说明线性放大方式，不是现实部署预测。

稳定规范仍提供底线。RFC 8806要求完整、当前并能通过 DNSSEC 验证的副本，也要求在陈旧数据被提供前切回非本地根服务。较新的个人 Internet-Draft 第 07 版提出整区获取前先检查状态，并讨论高效 HTTPS 分发。尽管文件名保留了 bcp，它的编辑说明已经明确不按 BCP 推进；它仍是没有正式地位的工作草案，不是现行 IETF 政策。

因此，可靠结论很朴素：本地提供根区，把一串小查询变成了一项刷新义务。这项义务可能高效，也可能浪费；可能保持当前，也可能悄悄落后。序列号检查、传输类型、单次字节、每日次数、验证结果与副本年龄，才是正在运行的事实。