摘要

  • draft-ietf-dnsop-ns-revalidation-14 允许递归解析器优先采用子区顶点的权威 NS 集合，却同时要求它按时回到父区核验；否则，被移走委派的旧子区可以靠自己的回答不断续活旧权限。
  • 可审计的结论必须连起父区 referral、NS 与 DS 的重叠、三个支撑 TTL 中的最短者、变更点以下缓存失效、重新解析和服务观察。任何一个成功信号都不能替代整条证据链。

没有故障的旧服务器

一次 DNS 托管迁移完成后，父区已经指向新运营方，新权威集群也已经上线。可是部分递归解析器仍把查询送往旧集群。旧服务器保存着一份可用的区域数据，能够返回格式正确的响应，也能把自己标为权威。

如果监控只问“DNS 是否回答”，迁移似乎没有问题。如果监控只看父区，迁移已经生效。如果应用恰好命中旧缓存，它看到的仍是旧世界。三种观测可以同时成立，却不能被压成同一个“委派状态”。

2026 年 9 月 2 日的 draft-ietf-dnsop-ns-revalidation-14 把这种冲突写成解析器的明确责任。它是 DNSOP 工作组的活跃 Internet-Draft，拟进入 Proposed Standard；Datatracker 状态为等待工作组主席放行，IESG 状态仍是 I-D Exists。它不是 RFC，也不能证明任意生产解析器已经实现或启用这套可选算法。

它提供的是更基础的判断边界：一台服务器能够权威回答，只能说明它如何看待自身数据；当前父区是否仍把这段命名空间交给它，必须由另一份证据回答。

一个区界，两套 NS

传统 DNS 委派在区界两侧留下两套 NS 记录。父区保存委派 NS 集合，子区在自己的顶点保存权威 NS 集合。RFC 1034 要求双方管理员保持一致，但协议没有给它们一笔原子事务，也没有让一侧更新自动改写另一侧。

RFC 2181 的数据可信度规则把子区顶点 NS 排在父区非权威 referral 数据之上。这个顺序有实际价值：子区运营方最清楚自己使用哪些服务器，也可以设置更短 TTL，在父区只能提供固定长 TTL 时更快地完成服务器调整。

草案因此建议解析器跨越一个新发现的区界时，主动向被委派服务器查询子区顶点 NS，并在缓存中优先使用这份权威集合。安全委派本来就要查询 DNSKEY，NS 查询可以与之并行。作为 glue 或附加数据获得的 A、AAAA 地址，如果只有较低可信度，也应在可能时重新查询，以权威地址答案替换它们。

但“数据更可信”并不等于“权限永续”。子区可以权威说明自己的 NS，却不能用自己的权威回答证明父区仍授权它。如果允许这种自证，旧运营方只要持续回答并刷新 TTL，就能让已经撤回的委派在缓存中无限延长。

因此，草案把经常混为一谈的两步拆开：向子区提升数据可信度，以及回到父区重新确认委派资格。

三只时钟约束一次授权

重新验证最迟必须在三类缓存 TTL 的最短者到期时触发：父区委派 NS 的 TTL、存在 DS 时父区 DS 的 TTL，以及子区顶点 NS 的 TTL。

三只时钟表达三种不同权力。父区 NS TTL 限制当前委派路径可以被相信多久；DS TTL 限制委派签名者关系可以被相信多久；子区 NS TTL 限制子区自述服务器集合可以被相信多久。采用最短者，意味着任何一方都不能用自己的长寿命记录延长另一方授予的权力。

草案还允许解析器设置合理的最小 TTL 下限。否则，恶意或错误的区域可以用极短 TTL 强迫解析器持续查询，制造计算型拒绝服务。这个下限是本地可用性防线，不是委派在延长时间内未改变的证明。运行记录必须同时保存原始 TTL、所用下限与实际重新验证期限。

把这三只时钟折叠成一个“DNS 缓存过期时间”，会抹掉谁在限制什么。事故复盘需要知道，是父区委派先到期、签名者关系先到期，还是子区自己的服务器声明先到期。

连续性不是“看起来还熟悉”

到达重新验证点后，解析器重新向父区询问。要把委派判为“仍然有效”，父区必须继续对同一个点返回 referral，新旧父区 NS 集合至少共享一个服务器名称；如果前后都存在 DS 集合，则至少共享一个委派签名者。

如果父区不再返回 referral、返回了不同区界、给出完全不同的 NS 集合或完全不同的 DS 集合，层级形状或授权已经改变。DS 从空变为非空，或从非空变为空，也属于授权变化。

“至少有一个重叠”允许渐进迁移。运营方可以在保留一台服务器或一个签名者的同时替换其余部分，不必假装所有记录同时切换。可是重叠只支持缓存连续性判断，并不证明新旧配置完全相同，更不证明所有地址、密钥、区域内容和应用服务都已一致。

它同样不裁决域名所有权或注册合同。解析器做的是“旧缓存是否仍有足够的当前父区支撑”这一技术判断。组织层面的授权和争议仍属于其他证据体系。

上层资格一变，下层结论失去支点

一旦发现委派层级或授权变化，草案要求不得再使用重新验证点及其以下的缓存数据。实现可以立即删除，也可以标记旧世代、延迟回收；但对外行为必须等同于数据已经移除。

这项要求不只影响 NS。旧委派下方可能缓存了主机地址、邮件路由、服务发现、否定答案和更深层委派。如果只换掉父指针却继续使用这些后代结果，就会留下没有当前授权链支撑的结论。

所以重新验证应从根向下进行。更高层的变化可能让下层验证全部失去意义。RFC 8020 说明一个 NXDOMAIN 结论可以影响其下命名空间；这里是另一面：支撑链的上层发生变化时，即使下层字节尚未自然过期，其旧证据基础也已经消失。

“缓存里还有”只是存储事实。“现在还能用”是授权与时间共同决定的运行事实。

严格模式用可用性换更强证明

严格模式可以暂缓触发查询的答案，直到解析器确认回答服务器的名称和地址都以权威方式取得。如果基础设施数据受 DNSSEC 保护且验证成功，这能减少伪造与旁路窃听风险。

代价是没有低可信度数据兜底。子区 NS 集合配置错误，或者权威服务器错误处理顶点 NS 显式查询，都可能让解析直接硬失败。草案因此建议把严格可信度提升限制在根区和根区直接委派的区域。

机会式模式选择另一种平衡。解析器可以先回答触发查询，再在后台完成验证；必要时退回父区 referral 数据。如果子区服务器错误地拒绝 NS 查询，解析器应针对该区放弃这套算法，改用父区信息。

两种模式不能在仪表盘上合并为一个“重新验证已启用”。严格模式的成功意味着答案等过基础设施证明；机会式模式的成功可能只意味着验证查询已经发出。必须分别记录等待时间、先行答案、回退、硬失败以及缓存实际切换的时刻。

DNSSEC 没有签下整条基础设施路径

DNSSEC 能认证关键记录，却通常不签 referral 中的 NS、glue 与附加区的 A、AAAA 地址。攻击者若篡改这些未签地址，可能把解析器引向恶意服务器；恶意服务器随后还能影响树下方更多未签 referral 数据。

RFC 5452 通过更严格的事务匹配和熵提高来降低伪造回答被接受的概率。第 14 版草案处理的是另一层问题：事务完成后，解析器所跟随的基础设施是否可信，以及这条基础设施是否仍得到当前父区支持。

有效 DNSSEC 签名也只是有范围的证据。它不能证明解析器在最短 TTL 前回到了父区，不能证明结果已被执行，不能证明全部后代缓存已失效，也不能证明应用最终到达预期服务。

错误码可以解释，不能修复

草案请求 IANA 为 referral NS 集合不匹配分配 Extended DNS Error 代码。RFC 8914 让解析器向客户端或运维人员给出更精确的失败原因。诊断信号很重要，但它不会修改父区、修好子区，也不会自动让其他缓存同步。

一条有用的 EDE 记录应关联具体父区回答、被比较的 NS 与 DS、解析器版本、模式、TTL、失效动作和随后采用的新解析路径。脱离这些附件，错误码只是结果标签，无法复现授权判断。

RFC 9471 则限定了 referral 中何时需要 glue。一个地址是抵达权威服务器所必需，不代表它本身拥有父区授权；一个地址可以连通，也不等于上层委派或应用交付有效。

实现历史不是生产普查

草案的实现状态附录称，Unbound 很早便通过 harden-referral-path 支持机会式重新验证，但该选项默认关闭；第 7 节的委派重新验证逻辑自 1.4.17 版存在。它还记录 Knot Resolver 自 1.5.1 版起在根 priming 时重新验证响应。严格模式则未发现作者原型与工具之外的实现。

这些陈述证明机制有运行代码历史，却不能证明某个现场实例的配置、某一发行版今天的默认值、跨网络采用率、成功率或互操作结果。能力来自版本资料；运行状态必须从实际二进制、配置、计时器、查询与缓存世代变化中观察。

这正是“运行代码优先”的边界：不是把产品名称当作事实，而是要求可重现地看见特定代码在特定时间做了什么。

一份不会把回答误当授权的收据

可辩护的运行记录至少应包含：解析器构建与实际配置；严格或机会式模式；初始父区 referral 的 NS、DS、glue 与时间；子区顶点 NS；重新取得的服务器地址；三项 TTL 与本地下限；从根开始的支撑链；新父区响应；NS 与 DS 重叠计算；DS 空/非空转换；被失效的缓存世代与范围；回退、硬失败或 EDE；最终选中的新服务器；以及独立的应用或服务观测。

这份收据不会让分布式 DNS 瞬间同步。它做的是更现实的事情：旧子区可以继续发包、继续说话，但组织能够证明为什么这些回答已经不能代表当前委派权力。

来源