摘要

  • 根区引导从软件自带的地址开始，但目标是取得当前 DNS 数据并写入缓存。配置只负责让第一次询问成为可能，不是最终权威状态。
  • 合格回答必须是 NOERROR、设置 AA、在 Answer 中包含根区 NS RRset、让 Authority 为空；它仍可在 Additional 中遗漏 A 或 AAAA，而且不必设置 TC，因为引导回答不是 referral，相关地址也不属于 RFC 9471 在该规则下所称的 glue。
  • 解析器必须主动补齐后续证据：无响应时换一个配置目标，识别缺失名称，直接查询其 A 与 AAAA，写入缓存，再用真实解析结果证明这套状态可用。

一台解析器刚刚重启。缓存是空的，软件包里只留着一组据称能够抵达 DNS 根的 IP 地址。它选出一个目标，查询根区 NS，收到 NOERROR，AA 为一，Answer 中也有 NS RRset。运维面板于是亮起绿灯。

但 Additional 没有带回所有地址，TC 仍然是零。绿灯没有撒谎；撒谎的是人对绿灯所做的扩张解释。它证明了这次回答的协议形态与权威性，没有证明本地已经得到完整的可达地址集合。

RFC 9609 在 2025 年 2 月以 BCP 209 发布，并取代 RFC 8109。它处理的是递归解析器如何从空缓存进入工作状态。更重要的是，它把一次“启动成功”拆回一连串可以独立核验的回执。

安装配置只是第一位证人

RFC 1034 早已描述过解析器在没有缓存时使用安全带结构寻找根区的方式。现代软件通常由供应商或发行方附带一组初始地址。它们在交付时可能准确，之后却会老化。根服务器标识符可以长期稳定，标识符所对应的 IPv4 与 IPv6 地址仍可能变化。

因此，引导的目的不是给初始文件加冕，而是用它发出第一次当前查询。查询的 QNAME 是 .，QTYPE 为 NS，QCLASS 为 IN，RD 应为零。UDP 查询可按 RFC 5452 随机选择源端口，并可使用 RFC 7873 的 DNS Cookie；RFC 6891 的 EDNS 则提供更合适的报文容量。

这些机制各管一段风险。随机端口阻碍伪造，却不能更新陈旧地址；Cookie 约束交互，却不会证明 Additional 完整；更大的报文容量减少空间压力，却不强迫对端把所有记录放进一次回答。系统可靠，靠的是这些边界明确的控制被正确串联。

有意义的重试必须改变条件

RFC 9609 规定，引导查询没有收到回答时，解析器必须改用配置中的另一个目标地址。重复敲打同一扇失灵的门，测到的只是坚持，不是恢复能力。第一次目标也应随机选择，以分散负载，并避免配置文件第一行逐渐变成事实上的中心。

引导完成后，证据优先级发生变化。如果根区 NS RRset 仍在缓存中，解析器要在到期前预取，应优先使用缓存地址，而不是退回可能陈旧的安装配置。初始配置的权力在使用后主动缩小：它是一架梯子，不是一张王座。

这与恒鲁关于最小初始规范的原则相符：共同层只规定首次互操作不可缺少的规则，之后由运行代码在本地选择、拒绝或调整。RFC 9609 列出若干根服务器选择策略，但没有把某一种变成全球唯一答案。

合法回答的证明范围很窄

引导回答必须满足清楚的结构：NOERROR；AA 置位；根区 NS RRset 位于 Answer；Authority 为空；相关 A 与 AAAA 可出现在 Additional。这组要求足以识别不合格回答，却不是完整性声明。

标准还明确说，解析器不应期待正好十三条 NS。熟悉的数量很容易被误当作合同，但它不是验证条件。标识符也不等于运营者或物理实例。RFC 发布时提到的一千五百多个实例，是当时的背景数据，不是今天的计数，更不是引导有效性的门槛。

回答应像普通 DNS 数据一样进入缓存。它有 TTL，会过期，需要更新。根区的重要性没有取消缓存模型，也没有让一份 RRset 永久有效。

TC 没有义务替你承认缺口

A 与 AAAA 合起来可能超过一次回答可用的空间。按照 RFC 9471，如果 referral 因报文大小无法带齐域内名称服务器所需的 glue，权威服务器必须设置 TC。然而引导回答不是 referral，其中的根服务器地址不属于该项规则针对的 glue。

所以 RFC 9609 不规定一次回答必须含多少根服务器地址，也不要求遗漏时设置 TC。证据必须逐项阅读：

  • NOERROR 说明此次 DNS 事务没有返回错误；
  • AA 说明回答者对 Answer 中数据具有权威性；
  • NS RRset 说明观察时点上的名称集合；
  • DNSSEC 验证可以认证其验证链实际覆盖的数据；
  • Additional 提供地址材料，但不附带“全部齐全”的承诺；
  • TC=0 只说明 TC 规则没有触发；
  • 后续真实查询才证明某个缓存地址从这台解析器可达。

每一盏绿灯都是真的。问题只在于把几盏灯揉成一句过度结论。

重复同一问题会重复同一盲点

如果服务器按固定顺序装填 Additional，再问一遍可能只会得到相同前半段，并再次丢掉相同后半段。请求数上升，信息增益仍为零。

RFC 9609 的修复路径是识别哪些根服务器标识符缺少地址，然后直接查询相应的 A 与 AAAA RRset。问题从“下一次会不会更完整”变成“这个具体名称缺哪一种地址”。这种逐项对账能够被监控、复现和验收。

因此，面板至少应分别记录：回答结构、NS 集合指纹与 TTL、DNSSEC 结果、每个标识符的 A/AAAA 覆盖、补充查询、缓存准入，以及引导后的首次成功解析。一个总括的“引导成功”可以留给摘要，却不能替代因果记录。

签名名称集合不会自动签名所有地址

RFC 9609 发布时，根区 NS RRset 已签名，可由启用 DNSSEC 验证的解析器认证。对应地址当时位于 root-servers.net 下，而 RFC 说明该区在当时没有签名。这里必须保留时间边界：标准描述的是发布时状态，不是对未来的永久断言。

RFC 4033 界定了 DNSSEC 的安全服务。签名不证明可用性，也不证明回答完整。伪造引导回答的攻击者可能试图把解析器导向其控制的地址；当后续查询进入签名链时，验证器能识别伪造，但未签名委派与未签名区不会仅因根区 NS 已签名就得到连带保护。

这不是削弱 DNSSEC，而是防止把一项真实能力包装成全能保证。随机源端口、Cookie、签名验证、目标多样性和运行观测各自阻断不同失败模式。

本地根改变距离，不改变证据类别

RFC 8806 允许在解析器附近运行完整根区副本。RFC 9609 表明这种架构仍可按相同方法给缓存做引导。距离缩短、外部依赖变化，但配置、区数据、缓存状态和实际解析依然不是同一件事。

本地进程在运行，不代表所载副本必然新鲜；正确区文件已加载，不代表解析器一定查询它；收到本地回答，也只证明回答所覆盖的部分。“本地”回答位置，不回答版本、完整性与结果。

运维记录要呈现权力交接

管理者真正需要审计的是一场交接：安装镜像提供了哪一版初始地址；解析器选中哪个目标与地址族；哪些目标超时并触发切换；回答是否满足结构要求；接受了哪份 NS、TTL 和验证结果；哪些名称缺 A 或 AAAA；直接查询如何补齐；哪些数据进入缓存；首个后续解析是否成功。

恒鲁关于运行代码优先的论点在这里不抽象。RFC 只协调行为；部署中的解析器负责选择、验证、缓存与使用，运维记录负责证明这些动作确实发生。

现实分层则提供最后的防错语言：配置文件不是根区；AA 不是完整性；NS RRset 不是成员可达性；TC=0 不是“没有遗漏”的证书；标准发布也不是产品部署。

可信系统不需要否定任何一层。它只需拒绝让上一层冒充下一层，并用证据完成整条链。