摘要

  • RFC 9904 将 DNSSEC 的“使用”与“实现”建议拆分到 IANA 注册表中，分别覆盖签名、委派和验证；这些活表成为后续决策的权威载体。
  • RFC 9905 要求不得再创建基于 SHA-1 的 DNSKEY、RRSIG 和 DS 材料，却继续要求验证端具备兼容能力。因此，合规的注册表状态只是迁移起点，不是区域已经轮换的证明。

一名值班工程师看到 IANA 表中 RSASHA1 的“用于签名”一栏变成了 MUST NOT。与此同时，权威服务器仍在返回带 SHA-1 的 DNSKEY 和签名，父区也保留着旧委派材料。这不是标准自相矛盾，而是两个时间层面：协调记录已经转向，分布式运行状态还在过渡。

2025 年 11 月发布的 RFC 9904，把原先写在 RFC 8624 中的 DNSSEC 算法建议迁入 IANA 注册表。RFC Editor 记录明确了它的状态，以及它对 RFC 9157 等文件的关系。它在发布时并未顺手改动继承来的等级；真正的制度变化，是以后不必等待一篇新的汇总 RFC 才能更新这张清单。

新的表格结构把过去容易混成一句“是否支持”的问题拆开。DNS Security Algorithm Numbers 注册表分别记录算法是否应当用于签名、用于验证，以及签名软件和验证软件是否应实现它。DS 摘要类型注册表则区分委派创建与验证。方向相反的规范词可以同时成立，因为生产新依赖与识别遗留依赖不是同一种责任。

RFC 9905正是这套机制的一次实质运用。它禁止使用 RSASHA1 和 RSASHA1-NSEC3-SHA1 创建新的 DNSKEY、RRSIG 或 DS 材料，但仍要求验证器实现继续支持相关签名算法。换言之，生态系统应停止扩大 SHA-1 依赖，同时不能在尚有区域撤离之前先拔掉验证梯子。

从表格到运行状态之间隔着多个主体和时钟。签名系统在子区生成 DNSKEY 与 RRSIG；注册商或注册局路径负责父区的 DS；权威服务器要收敛到新的区域序列号；递归缓存会在 TTL 到期前保留旧记录；验证器还因版本、算法能力与观测时刻不同而产生不同视图。任何一个控制台显示绿色，都只能说明它自己的步骤成功。

结果也必须精确命名。RFC 9364把 DNSSEC 放在更广的来源认证脉络中，RFC 4035则区分 secure、insecure、bogus 与 indeterminate。RFC 9905 对没有可接受替代路径的特定 SHA-1 情形规定了 insecure 处理；它没有把所有仍出现 SHA-1 的区域一概宣布为 bogus，更没有证明服务必然不可达。

最危险的误判发生在轮换顺序上。RFC 9904 提醒，若在引入新 KSK 的同时改变 DS 算法，验证可能失败，因此应先完成 DS 算法升级。RFC 6781进一步展示了加入或移除算法所需的分阶段 RRSIG、DNSKEY 与 DS 转换，以及传播和缓存到期窗口。签名任务完成，与远端验证器看到安全组合，可以相隔一段不可压缩的时间。

因此，关闭迁移工单需要的是一条相互咬合的收据链：IANA 快照和授权 RFC、签名软件与配置版本、区域序列号、精确的 DNSKEY/RRSIG/DS 集合、父区事务回执、多个独立观测点的权威查询、TTL 窗口、验证器版本与分类结果、错误遥测、回退材料，以及最终的应用目标。每份证据只回答一个层面的问题，不能借用整条链的权威。

Heng Lu 的最小初始规范主张以窄而共同的规范承载协调，同时把落地选择留给可问责的运营者；运行代码优先要求查看实时记录与验证器证据；现实层次则阻止我们把建议、配置、已发布 RRset 和用户结果压成一句机构声明。这些是公开说明的编辑原则，并非给 DNSOP 增添的新要求。

注册表能够决定生态系统该往哪里走。只有带时间边界、可以复查的运行证据链，才能说明某个区域及其验证者是否已经抵达。

Sources