摘要

  • RFC 9905 是 IETF Standards Track 文档，发布于 2025 年 11 月，更新 RFC 4034 与 RFC 5155；它让 SHA-1 退役明确成为“停止生产、继续读取”的非对称变更。
  • RSASHA1 与 RSASHA1-NSEC3-SHA1 MUST NOT 用来创建 DS、DNSKEY 或 RRSIG。若委派只有这些算法的 DS，验证器须按规定将该委派及其下数据视为 insecure，而不是把这个结果表述成 bogus 或普遍性的验证失败。
  • 验证器实现仍 MUST 继续支持这两种算法的验证。验证器运营者可以推进更强算法迁移，但不能据此声称现在所有部署都可以移除 SHA-1 验证；已经移除它的软件，可能需要手动构建以满足实现义务。
  • 实际变更必须把权威签名、父区 DS 发布、递归验证能力分别盘点，并用重叠期与回滚证据证明较强算法已可用。

这不是把三个角色合并成一个“SHA-1 状态”。权威系统面对的是禁止新生成；父区委派面对的是 DS 不得新建以及仅有受影响 DS 时的 insecure 处理；递归软件面对的是持续拥有验证能力。RFC 9905 的表格单元因此可以成为变更控制输入：同一算法在生产列是 MUST NOT，而在验证实现列仍是 MUST。

**Theo March 分析：**软件生命周期会把一次看似简单的算法退役变成锁定问题。若先删除验证代码，操作者以后就无法证明剩余旧委派仍能被读取；若只保留旧签名，又没有可接受的更强算法和 DS 共存证据，撤回将没有安全的落点。这里的“继续验证”不是鼓励继续签名，而是为安装基础留下有界的兼容路径。

运作顺序与检查

第一步检查权威签名器：列出每个区域当前生成的 DNSKEY 和 RRSIG 算法，确认 RSASHA1 及 RSASHA1-NSEC3-SHA1 不再被用于新记录，并选择 IANA 注册表推荐的更强算法迁移路径。RFC 9905 建议使用 SHA-1 算法的区域所有者立即转向更强算法；本文不推断某一算法的采用率或未来推荐。

第二步检查父区 DS：确认不会提交受影响算法的新 DS；验证每个委派是否已有使用可接受算法的 DS。只有 SHA-1 DS 的委派，在没有其他可验证 DS 时按 RFC 9905 的规则作为 insecure 处理。这是规范规定的委派结果，不应被改写成 bogus、failed 或“所有验证器都可删除 SHA-1”。

第三步检查递归验证：在实际构建和配置中确认两种算法仍能验证，记录测试查询、DNSKEY/RRSIG 链和结果。若供应商版本已经删除 SHA-1 验证，不能凭空假定它符合要求；应评估手动构建，以满足继续实现验证的义务。这里没有关于任何特定供应商、默认值或部署普及度的断言。

迁移证据应包含时间重叠：较强 DNSKEY/RRSIG 已发布且能验证，父区 DS 已发布并可形成链，递归侧也在保留旧算法读取能力。再安排撤回旧签名或旧 DS，并保存撤回前后的查询、链验证和监控记录。若新算法链验证失败，或 DS 发布与权威响应不同步，回滚到最近一个已验证的兼容配置；回滚不是重新创建 SHA-1，而是恢复已经准备好的更强算法与委派状态。对每个阶段写明负责人、窗口、成功条件和停止条件。

来源