摘要

  • DNSSEC 轮换是一组密钥状态的有序迁移，并非一个仪式时间点。
  • 权威传播、缓存过期、父区 DS 和信任锚等待各有自己的时钟。
  • 只要仍有合理的验证组合依赖旧材料，旧密钥就不能被删除。
  • 激活、退役和移除应由一份轮换证据记录控制。

设想一次按计划进行的密钥仪式顺利结束。新 DNSKEY 已经出现，签名系统能产生有效签名，控制台也显示成功。团队于是按日程删除旧密钥。随后，一组使用验证型递归解析器的客户开始收到 SERVFAIL，但靠近权威服务器的探针依然全部正常。

密码学没有突然失效。真正的问题是运营流程把几个独立时钟压缩成了仪式时钟。

RFC 7583 把轮换描述为密钥依次进入“已生成、已发布、已就绪、已激活、已退役、已失效、已移除”等状态。状态名称之所以重要，是因为密钥可见并不代表它已经就绪；密钥开始使用也不代表所有验证器都能使用；密钥停止签名后，缓存中的数据仍可能依赖它。安全的含义，是在 DNSKEY、RRSIG 以及 KSK 所涉及的 DS 发生变化时，始终保留至少一条可验证路径。

第一个时钟是权威传播。新密钥出现在主服务器上，并不等于所有权威节点都已经取得它。RFC 7583 把传播时延计入密钥达到就绪状态之前的等待区间。RFC 6781 对 ZSK 预发布给出了同样的操作纪律：先引入新的 DNSKEY，让它传播到权威集合，再至少保持一个 DNSKEY TTL，之后才用它签署生产数据。

第二个时钟属于递归缓存。验证器可能保留旧 DNSKEY RRset，却获取了新的 RRSIG；也可能更新了密钥集合，却仍持有旧签名。轮换方法必须保证这些交叉组合仍可验证。预发布方法让新密钥先等待，签名切换后再保留旧密钥；双签名方法让两代密钥和签名重叠，以更大的响应换取更直观的兼容窗口。

第三个时钟位于父区委派。ZSK 轮换可以在一个区内完成，KSK 轮换通常还要把子区 DNSKEY 与父区发布的 DS 接起来。子区可以提交新 DS，却不能把“已经提交”当成“DNS 已经发布”。运营方必须实际观察父区的新 DS，计算旧 DS 的 TTL，并在后继验证路径成立前保留原有路径。

第四个时钟适用于依据 RFC 5011 管理已配置信任锚的解析器。新的 SEP 密钥先进入等待状态。解析器必须等完加入保持期，然后再次获取并验证一个仍包含该密钥的 DNSKEY RRset，才能把它接受为信任锚。加入保持期是三十天或首次 RRset 原始 TTL 的到期时间，两者取更长。对于移除流程，信任锚只有在满足规范规定的撤销或缺失观察后才进入 Removed 状态；解析器还要保留该状态三十天，之后才能清理内部记录。这个期限只管理解析器中的信任锚状态，并不是从区中删除 DNSKEY 的通用许可。这个时钟存在于验证器内部，不受区运营方直接控制。

这四个时钟不是同一个倒计时的四块表。它们从不同的可观察事件启动，由不同组件拥有，证明不同的迁移。控制台显示“新密钥已发布”不能授权激活；一处探针验证成功不能授权删除旧密钥；父区门户的受理回执不能证明缓存已经过期；日历走过三十天，也不能证明 RFC 5011 要求的后续获取已经发生。

合适的证据对象是一份轮换证据记录。它记录区名、轮换方法、密钥标签和算法；记录每把密钥何时进入各个状态；保存来自明确观测点的 DNSKEY、RRSIG 和 DS；注明 TTL、传播上界和签名有效期；并把提交、权威可见和缓存到期分开。

对于 RFC 5011 群体，记录还要包含信任点、首次验证观察、保持期截止时间，以及完成接受所需的后续验证观察。对所有群体，都要保留有代表性的解析器验证结果，并写明谁有权推进每一步、什么证据触发回滚。

这样才能准确表达完成。“仪式已经执行”只说明管理动作发生；“新密钥已经激活”说明所选方法达到相容验证状态；“旧密钥可以移除”说明任何适用的缓存或信任锚状态都不再需要它。这些日期可能相近，但三个判断不可互换。

来源

RFC 7583 — DNSSEC 密钥轮换时序；RFC 6781 — DNSSEC 运行实践；RFC 5011 — DNSSEC 信任锚自动更新。