摘要

  • RFC 9904 是一份 IETF Standards Track RFC，发布于 2025 年 11 月；它正式替代 RFC 8624，并更新 RFC 9157。
  • 它把 RFC 8624 中关于 DNSSEC 算法实现要求和使用指导的建议，移入 IANA 的 DNS Security Algorithm Numbers 与 DS Digest Algorithms 注册表。RFC 9904 本身不改变任何继承而来的 MUST、MAY、RECOMMENDED 或其他建议状态。
  • 对每个算法编号而言，验证器实现、签名器实现、验证使用和签名使用是四个不同的建议栏。未来修改这些栏需要经过 Standards Action，并说明迁移与互操作后果。

这不是一次新的算法评级，也不意味着 IANA 可以自行改变建议值。RFC 9904 改变的是权威建议的承载位置和更新流程：需要了解当前适用的建议时，应查看相应的 IANA 注册表；需要了解如何改变这些建议时，则应回到 RFC 9904 规定的流程。RFC 9904 纳入并更新了 RFC 9157 的 DNSSEC 注册表考虑事项，同时没有改变继承而来的建议状态。RFC 9364 提供 DNSSEC 身份验证和否定存在证明的协议背景，但不为 RFC 9904 添加新的建议变化。

四个单元格必须分开阅读。验证器是否必须实现某个算法，与签名器是否必须实现它，不是同一个问题；验证方是否应使用它，也不等于签名方是否应使用它。一个算法编号可以在这些维度上承担不同职责。若把四栏压缩成一个“支持/不支持”标签，迁移中的不对称风险就会被隐藏，决策记录也无法说明究竟改变了哪一种工作负载。

Theo March 的分析提出，运营团队可以保存注册表名称、完整快照、观察时间和用于决策的四栏值，并分别确认递归验证器、权威签名器、验证策略和签名策略的责任人。Theo March 的分析还提出，在考虑退役前进行新旧算法的重叠签名与验证测试，保存成功、失败、时间窗口和恢复步骤，并以分阶段方式推进变化、保留可执行的回滚路径。这些是分析性的运营建议，不是 RFC 9904 新增的强制要求。RFC 9904 的安全警告是：过早退役一个算法，可能使只用该算法签名的区域在验证器眼中实际上像未签名区域。因此，弃用应当审慎，最好逐步进行。

来源