摘要

  • RFC 8806 允许递归解析器向同一主机上的本地权威服务查询完整 DNS 根区。该服务只能回答本机解析器，所载数据必须与公共根完全一致，并包含 DNSSEC 验证所需的全部记录。
  • 本地副本受 SOA 时间约束，绝不能继续提供过期根区。刷新失败时，解析器必须在 expiry 之前立即改用非本地根。因此，这是一条带强制出口的本地执行路径，不是根权威的转移。

一台主机里可以同时运行两个看似矛盾的角色：一个递归解析器不断替客户端寻找答案；另一个权威服务却只保存根区，而且拒绝回答这台主机之外的任何人。

拒绝不是功能残缺，而是 RFC 8806 的安全核心。完整根区副本离解析器越近，网络路径越短；服务范围越小，一次错误能够波及的解析器也越少。副本因此获得本地可用性，却没有获得对外发言权。

Paul E. Hoffman 在 RFC 8806 的两位作者中名列第二，另一位作者是 Warren Kumari。该文档于 2020 年 6 月作为体现 IETF 共识的信息类 RFC 发布，并取代 RFC 7706。这能证明 Hoffman 参与了集体标准工作，不能证明他独占发明、要求所有运营者部署，或控制任何具体根区副本。

同一主机是访问边界，不是部署建议

RFC 8806 的做法是：取得完整根区，把它载入与递归解析器同一主机上的权威服务，再让递归进程把根查询交给这个本地服务。

上一版 RFC 7706 把服务绑定在 loopback 地址上。RFC 8806 放宽了具体实现方式，也允许解析器在需要时退回远端根，但“只能服务同一主机上的解析器”没有改变。本机以外的解析器不得获得响应。

若一份错误副本能被整个园区共用，局部配置就会变成共享故障源。限制在本机后，错误区文件、损坏进程或不正确的刷新策略首先伤害的是作出这项部署选择的解析器。

这条规则也防止语言膨胀。所谓 local root 不是一台新增的公共根服务器，不是国家根、地区根或替代命名空间。它不决定顶级域是否存在，只在本地执行公共根已经表达的状态。

因此，运营者拥有的是采用权与退出权。最小初始规范保留本地实现空间，同时把不可跨越的共同条件写清：同一主机、同一份数据、可验证、可过期、可回退。

副本可以在本地，参照物不能被改写

RFC 要求本地根区与公共 DNS 根完全一致，并明确不应修改 glue。副本还必须完整包含 DNSSEC 记录，不能只挑常用顶级域。

部分副本的问题不是覆盖率不够漂亮，而是语义错误。递归解析器无法预知下一位客户端会查询哪个 TLD。若本地文件没有某项记录，解析器不能把“我没有复制”当作“公共根不存在”。

DNSSEC 给本机服务增加了独立验证。递归解析器必须像对待远端根响应那样，验证本地服务返回的已签名数据。物理距离近不能代替来源证明；解析器需要当前公共根 KSK 的信任锚。

Hoffman 还是 RFC 7958 的四位作者之一。该文档记录 IANA 如何发布 DNSSEC 根信任锚，并说明验证链为何需要一个协议外确定的起点。把文件下载到自己的磁盘，不会自动让它变成可信起点。

真正的去依赖发生在传输层：查询不必经过外部网络。权威层反而保持不变。本地副本只有持续证明自己与公共根相同，才有资格缩短路径。

SOA expiry 是本地性的终点

根区会变化，本地副本不能成为永久快照。RFC 8806 要求按根区 SOA 中的计时值刷新。完整区域可以通过 AXFR 或公开根区文件取得，具体取决于服务与实现。

本地副本可能短暂落后。公共根运营者可更快收到变更通知，而本地取得路径未必有相同通知机制。RFC 接受的是计时范围内的延迟，不是无限延期。

expiry 到来前，解析器必须立即切换到非本地根。本地服务绝不能继续提供 stale root data。这里的回退不是可选增强，而是使用本地副本的组成条件。

刷新失败的影响可覆盖整个顶级域。例如公共根出现新委派，而本地 serial 停止前进，后面的客户端会看见过时的命名空间。权威进程仍可能响应得很快，端口健康检查也可能完全正常。

所以应监测“区域还能被证明多久”，而不是只看进程是否活着。证据至少包括公共与本地 SOA serial、最近一次完整取得时间、DNSSEC 记录完整性、验证结果、信任锚状态、距 expiry 的余量，以及解析器真实选择的查询路径。

Priming 只是在更新去根的地图

Hoffman 参与共同撰写的 RFC 8109 讨论 resolver priming。解析器从 root hints 起步，向远端根查询当前 NS RRset 与相关地址，以便更新自己对公共根服务器位置的认识。

Priming 没有把完整根区加载进本地权威服务。root hints 是起点，priming response 是可达位置的更新，完整区传送是数据取得，本地权威服务才是执行副本。四者不能用一个“根已配置”状态代替。

收到正确 priming 响应，也不证明本地根区仍在 SOA 有效期内。反过来，本地区域验证成功，也不证明远端回退路径真实可用。每条路径都需要自己的收据。

一旦审计把它们混在一起，最危险的失败恰好会被隐藏：解析器认为自己有根配置，运营者却不知道是哪一个机制仍然成立。

隐私与韧性把责任搬进主机

根查询留在主机内部，可减少网络路径上的观察者看到查询与响应的机会。当外部根不可达或遭受攻击时，本地副本也能延续解析。

普通性能收益不一定显著。有效 TLD 数据的 TTL 较长，递归解析器通常已经缓存，不会为每一条客户端查询都访问根。

新的风险集中在本地。递归解析器与权威服务共享主机、资源、变更窗口和部分故障命运。一次软件错误、内存压力或配置失误可能同时破坏两者。外部路径依赖减少，内部运行责任随之增加。

区域取得服务也不是永久承诺。RFC 列出 AXFR 与文件服务，但提醒其可用性没有保证。IANA 在 2026 年 8 月 30 日复核时公开根区文件、root hints 与信任锚材料；这个时间点的可用，不等于未来合同。

Running-Code Primacy 要求把规范动词变成现场证据。区域是否完整、签名是否通过、serial 是否更新、外部请求是否被拒、expiry 前是否确实回退，都只能由运行系统证明。

人物归因也有一条不可跨越的线

2026 年 8 月 30 日复核的 IETF Datatracker 资料为 Paul E. Hoffman 列出 83 份 RFC、三个工作组主席角色和 RFC Production Advisory Team 成员角色，并收录 RFC 7706、7958、8109 与 8806。

现任角色和数量会变化。RFC 的作者记录能够证明他参与标准形成，却不能证明全球部署比例、所有实现合规，或他个人拥有 DNS 根的决定权。

这与本地副本的边界完全相似。作者名字是贡献证据，不是运行权威；本机文件是持有证据，不是根区权威。把证据扩张成权力，反而会损坏证据本身。

RFC 8806 最有价值的地方，不是让根“落地”，而是让副本始终知道自己不是根：只回答本机、只复制公共数据、只在验证通过且时间未到时工作，并保留一条必须走得通的退出路径。

来源