摘要

  • 私钥不可用时，尚在服务的预签名区与未过期 RRSIG 只证明旧状态暂时可验证；它们不能恢复私钥，也不能证明替代密钥、父区 DS、所有缓存与所有权威实例已经同步。
  • ZSK 失效应走 Pre-Publication，KSK 失效应走 Double-DS，CSK 失效则需要更长的调整版 Double-DS；三条路径的等待区间和旧材料退役条件不同，不能用一次成功查询替代时序证明。
  • 功能恢复必须形成从旧区保存、父子区发布、从服务器装载、正负查询验证到业务路径观测的连续证据链；任何一环仍依赖旧 DNSKEY、DS 或 RRSIG 时，都不应撤掉旧状态。

尚可验证，不等于已经恢复

私钥失效与密钥泄露不是同一类故障。前者指信任链中的某个 DNSKEY 所对应的私钥已无法继续签名；后者则可能仍能产生签名，只是其可信性已被破坏。本文讨论的是前一种情形，而且有一个关键前提：完整的已签名区仍然存在，可能保存在签名系统之外，也可能只能从权威服务器上取回。如果私钥没有可用备份，密码学意义上的密钥无法“恢复”；能做的是在旧签名寿命耗尽前，让新的密钥接续签名功能。

这一边界来自 IETF DNSOP 工作组的 draft-ietf-dnsop-dnssec-keyrestore-02。截至 2026 年 9 月 13 日核验，Datatracker 将其列为 active DNSOP WG Internet-Draft，revision 02，更新日期为 2026 年 8 月 10 日；它不是 RFC，预期状态为 Informational，仍可能继续修改。文档处理的是预签名记录架构，不涵盖在线签名，也明确排除根区，因为根信任锚的分发时间可能长于 RRSIG 的有效期。

故障发生的一刻，权威服务器上的现有 RRSIG 往往还有数天有效期。这个余额就是恢复窗口。它同时受最早到期的关键签名、DNSKEY 与 DS 等记录的剩余 TTL、父子区传播延迟以及各权威实例装载进度约束。运营者自己的动作也会缩短窗口：过早删除旧 DNSKEY 或旧 RRSIG，或者修改一个再也无法由旧私钥签名的 RRset，都可能把“仍可验证”迅速变成 bogus。

因此，第一项工作不是轮换，而是冻结并留存最后一个正确状态。应不可变地保存完整已签名区，列出 DNSKEY、父区 DS、各 RRSIG 的 inception 与 expiration、SOA、NSEC 或 NSEC3，以及 ZONEMD；同时逐一记录哪些权威节点仍在提供什么版本。签名器在收到明确指令之前不得删除 DNSKEY，并且应保留旧 RRSIG。若软件不能保留旧签名，除旧 DNSKEY RRset 的签名外，其他旧签名须在发布前手工恢复。此时顺便更换算法只会增加未知量；除非算法迁移早已在进行，否则应先以现有算法恢复功能，再按正常程序做算法轮换。

三种失效，三条时钟

KSK 可用、ZSK 不可用：先让新 ZSK 被看见

分离 KSK/ZSK 的区如果只丢失 ZSK 私钥，现有区数据暂时不能改变，因为每一次变化都需要旧 ZSK 无法产生的新签名。可用的办法是 Pre-Publication，而不是立即用新 ZSK 改写所有内容。

在 Tpub，运营者把新 ZSK 加入 DNSKEY RRset，同时保留旧的不可用 ZSK 及其全部 RRSIG。由于可用 KSK 能为变更后的 DNSKEY RRset 签名，这一步可以建立新密钥的入口；但不应仅为引入新 DNSKEY 而递增 SOA，因为旧 ZSK 无法为改变后的 SOA 重新签名。更隐蔽的风险在否定应答：即使已有记录的查询仍能通过验证，不存在类型或名称所需的 NSEC/NSEC3 证明也可能因状态变化而变成 bogus。

新 ZSK 出现在一台服务器上还不够。必须等待 Ipub = Dprp + TTLkey：Dprp 是新 DNSKEY 到达全部权威实例的传播时间，TTLkey 是旧 DNSKEY 缓存可能继续存在的最长时间。到 Trdy = Tpub + Ipub 之后，新 ZSK 才算 ready。此后区内容才可改变并由新 ZSK 签名，旧 RRSIG 可以逐步撤下，但旧 ZSK 仍须留在 DNSKEY 中。

旧 ZSK 的退役还要再等待 Iret = Dsgn + Dprp + TTLsig，覆盖签名延迟、权威传播以及最长 RRSIG TTL。只有当依赖旧签名的缓存路径已越过这个区间，旧 ZSK 才能安全移除。理论上的 Double-Signature 也能构造轮换，但在这种恢复场景中更慢，因为数据要到 Dsgn + Dprp + max(TTLkey, TTLsig) 之后才能改变。

KSK 不可用：父区先建立第二条 DS 路径

旧 KSK 无法给改变后的 DNSKEY RRset 签名，所以 Pre-Publication 不成立；必须使用 Double-DS。若 KSK 与 ZSK 同时不可用，应先恢复 KSK 功能，而不是把两次高风险变化叠在一起。

流程从父区开始。在 Tsbm 提交新 DS，经过注册处理延迟 Dreg 后才在 Tpub 出现在父区。注册商或注册局显示“已接受”，最多证明管理请求进入了相应系统，并不证明 DS 已发布到所有父区权威服务器。发布后仍须等待 IpubP = DprpP + TTLds，其中 DprpP 覆盖父区所有权威实例的传播，TTLds 覆盖递归解析器中的旧 DS 缓存。只有 Trdy = Tpub + IpubP 到达后，新 KSK 才具备激活条件。

激活时把新 KSK 加入子区 DNSKEY，并用它签署 DNSKEY RRset。此时旧不可用 KSK 可以从子区 DNSKEY 中退出，但 ZSK 必须保留；如果 ZSK 也失效，则保持 SOA，确认从服务器装载，再按前述 Pre-Publication 路径恢复 ZSK。父区的旧 DS 不能随旧 KSK 一起立即删除：在 Tact 后还要保留 Iret = DprpC + TTLkey，让持有旧子区 DNSKEY RRset 的解析器仍能沿旧 DS 验证。父区旧 DS 的最早移除时刻是 Trem = Tact + Iret。

依赖 CDS/CDNSKEY 的自动化也不能被想当然地视为救援通道。当负责签名的 ZSK 或 CSK 不可用时，新引入的 CDS/CDNSKEY 不能得到可验证的签名；增加这些类型还会改变区顶点的 NSEC/NSEC3 类型位图，而旧密钥无法为其重新签名。因此 KSK 或 CSK 恢复可能需要父区允许的带外或人工更新程序。RFC 8078 与 RFC 10026 提供了 DS 自动化及恢复决策的背景，但一次请求被接受仍不能代替父区发布和缓存时窗的证据。

CSK 不可用：一把钥匙使两个退役区间耦合

CSK 同时签署 DNSKEY 与普通区数据，失效后没有可用旧钥匙为任何变化兜底。因此只能采用调整版 Double-DS：先在父区发布新 DS，等待 Dreg 与 IpubP = DprpP + TTLds 全部完成，然后才激活新 CSK。

激活时加入新 CSK，用它签署 DNSKEY RRset，但必须继续保留旧 CSK 和旧 RRSIG，避免不安全的 SOA 变化，并强制需要的从服务器加载该版本。退役区间是 Iret = Dsgn + DprpC + max(TTLkey, TTLsig)。到 Trem = Tact + Iret 之前，父区旧 DS、子区旧 CSK 与旧签名必须共同存在；到点并经观测确认后，三者才可一起移除，正常区变更才能恢复。这里最短的 TTL 不是决策依据，真正约束来自最长仍可能被缓存使用的验证路径。

状态一致性的几个陷阱

恢复动作改变 DNSKEY RRset 时，已发布的 ZONEMD 摘要随即失效。必须为改变后的区重新生成 ZONEMD 并用 DNSSEC 签名。RFC 8976 所描述的顺序很重要：区内容、ZONEMD、覆盖它的 RRSIG，以及 NSEC/NSEC3 构造是一个有序整体。某个 ZONEMD 验证成功，是该摘要方案下区内容完整性的有力证据，但它既不能替代从 DS 到 DNSKEY、RRSIG 的信任链验证，也不能证明线上每台服务器和每条应用路径都正确。

SOA serial 相同也只是传送与版本线索，不是两份区文件逐字一致的密码学证明。恢复的受限阶段刻意不改变 SOA，还会使依赖 NOTIFY、IXFR 或 AXFR 的从服务器无法仅靠常规 serial 变化收敛。主服务器上的文件已经编辑好，并不代表所有 anycast 后端、unicast 节点和从服务器都已经装载；需要强制传送或重载，并为每个实例留下装载回执与查询证据。

同样，一次有效的 NSEC/NSEC3 否定应答只说明该名称、该类型、该实例在该时刻的证明可以验证，不能推及整套名称空间或所有类型位图。一次由新密钥验证成功的 RRSIG，也只证明特定 RRset、签名和 DNSKEY 的关系，并不证明所有 RRset 都已重签、ZONEMD 一致，或者旧路径可以退役。

从控制面完成到用户仍可用

称“签名功能已经恢复”至少需要四组相互独立的观察。第一组是父区：分别记录 DS 提交、管理接受、每个父区权威实例的发布，以及 TTLds 已经走完。第二组是子区：分别记录新密钥 publication、readiness、activation、全量 RRset 重签、各权威节点传播和旧材料 retirement。把这些状态压缩成一个“完成”标记，会掩盖最容易出错的等待区间。

第三组来自独立运营的验证递归解析器。应从多个网络和地域做冷缓存、暖缓存测试，查询 DNSKEY、DS、正向业务记录和不存在名称或类型，记录 RRSIG 到期时间与反复观测结果。一台解析器返回 Secure，只能证明它当时看到的链与缓存状态；清空同一台解析器再测，不能代表全球缓存已经跨过 TTL。

第四组才是业务连续性。HTTP、TLS 或应用事务成功，只证明某条解析与访问路径可用；它不证明所有 DNS 客户端都会验证，也不证明其他权威节点、流量调度或客户网络没有故障。应在完整重叠期和退役期内，从多个网络持续进行应用检查，并把解析结果与业务结果对应起来。协议层的保守公式建立在传播上限和 TTL 已知且发布得到验证的前提上；无法枚举的递归缓存与异构权威架构，会把不确定性继续向外推。

实现支持也不能被过度推断。该 Internet-Draft 记录了以 Knot DNS 验证相关程序的情况，但其中包含人工步骤，而且所述路径不支持手工生成新的 ZONEMD 摘要。这说明一套实现曾完成演练，不代表所有权威软件、托管平台或部署拓扑都具备同等恢复能力。组织应在自己的版本和配置上预演，并把无法自动完成的步骤纳入事故授权与值守安排。

证据边界

观察 可以证明 不能证明
一台权威服务器上的旧 DNSKEY 与未过期 RRSIG 该节点在该时刻能给出可检验的旧状态 私钥仍存在、新签名可用、全区一致或全球解析器仍有完整链
一台服务器可见新 DNSKEY 新材料已到达一个发布点 全部权威实例已装载或旧 DNSKEY 缓存均已过期
注册商或注册局接受新 DS 管理提交被接受 父区已全面发布、TTLds 已走完或解析器均可见
新 RRSIG 可由新密钥验证 一个 RRset 的新签名关系有效 所有 RRset、否定证明、ZONEMD 与退役条件均正确
匹配的 SOA serial 版本与传送的线索 区内容逐项一致或所有从服务器已装载
独立解析器返回 Secure 该解析器当时的路径与缓存可验证 全球收敛或业务没有受损
HTTP/TLS/应用成功 一条端到端业务路径可用 DNSSEC 转换整体可关闭

一份能够关闭事故的证据档案

证据应按时间而不是按系统归档。起点是最后正确区的哈希、密钥标签、算法、RRSIG 起止时间和父区 DS 快照；随后是每个权威实例在旧状态保存、新材料发布、激活和退役四个阶段的应答。对 anycast 服务，仅查询公开地址并不能自动区分所有后端，运营者还需要供应商提供的节点级观测，或能说明覆盖范围的探针结果。看不到的节点不能被默认为已经同步。

父区记录应同时保存提交时间、受理主体、首次发布时间、各父权威的回答和最后一次旧缓存仍可能有效的时刻。子区记录则应把 DNSKEY、普通 RRset、否定证明和 ZONEMD 分开检查。每台从服务器的强制传送或重载要有独立回执，并在装载后从该节点实际查询，而不是只保存发送 NOTIFY 或启动 AXFR 的日志；RFC 1996 与 RFC 9103 描述了通知和传送机制，但请求发生本身并不等于预期版本已经投入服务。

验证侧还应保留带时间戳的原始 DNS 结果，使后来审查者能够判断当时使用的是旧链还是新链。正向查询覆盖关键业务 RRset，负向查询覆盖不存在名称与存在名称下的不存在类型；两类结果都要跨越 publication 和 retirement 边界重复采样。业务观测则记录解析器、接入网络、目标地址、TLS 结果和应用事务，避免把 DNS 成功与应用成功混成一个指标。只有这些证据在同一时间线上闭合，事故负责人才能说明某项旧材料为何已经没有观察依赖。

最终的安全原则很朴素：旧状态不是垃圾，而是恢复期间仍在承载验证的桥。只要任何必要观察仍依赖旧 DS、DNSKEY 或 RRSIG，就应维持它们并保留回退点。恢复完成不是某个控制台变绿，而是旧状态保存、父子区交接、缓存跨越、区内容一致、权威实例装载、独立验证与业务连续性在时间线上彼此吻合。

来源