摘要

  • draft-ietf-dnsop-dnssec-keyrestore-02 处理一个狭窄但棘手的场景：DNSSEC 私钥失效、没有可用备份，但完整的预签名区域和尚未过期的签名仍然存在。
  • 安全恢复要分别等待 RRSIG 到期边界、子区 DNSKEY 传播、父区 DS 发布、次级服务器装载以及缓存淘汰。签名方能发起部分步骤，却无法独自完成全部状态转换。
  • 运营方应保存“恢复时钟记录”，为每一步标明权限主体、计算依据和可验证结果。这是 Daniel Kade 的治理建议，不是 IETF 的要求。

这种故障最容易被两种直觉带偏。第一种直觉看到解析仍成功，便认为事故尚未发生；第二种直觉看到私钥不可用，便急于清理旧密钥并生成全新状态。前者会浪费剩余签名寿命，后者可能在旧签名真正到期之前，主动把仍然有效的区域变成 DNSSEC bogus。

2026 年 8 月 10 日发布的 DNSSEC Key Restore 第 02 版，是 DNSOP 工作组的活跃 Internet-Draft。渲染文本把预期类别写作 Informational，但它仍是可能修改、替换或过期的工作文件，不是 RFC、BCP 或最终标准。作者隶属 RIPE NCC，也不等于 RIPE NCC 已经承诺某项恢复服务。草案只讨论预签名区域，在线签名架构和根区明确不在范围内。

标题里的“恢复”同样需要限定。若私钥已经丢失且没有可用备份，草案不会还原那把私钥。它要恢复的是签名能力：引入新的密钥材料，同时保留验证者仍依赖的旧 DNSKEY 和 RRSIG，直到各层旧状态都安全退出。

解析连续，不等于区域可变

草案把“失效私钥”定义为无法继续产生签名的私钥部分。硬件故障、自然灾害、操作错误或恶意行为都可能造成这种状态。被攻破但仍能签名的密钥不属于同一类别。前者首先是连续性问题，后者还涉及攻击者可能继续使用密钥。事故分类如果含糊，恢复程序和紧急权限都会错位。

失效发生的一刻，权威服务器仍可能提供一份完全正确的已签名区域。RRSIG 通常还有数日寿命，但“通常”不是服务承诺。真正的剩余时间取决于区域内每类签名的起止时间、当前发布的 RRset，以及递归验证器可能缓存的组合。运营方必须查看实际最早边界，而不是套用配置中的默认签名周期。

这段期间，旧内容可以验证，新内容却未必能安全加入。修改地址、撤回受损服务、调整邮件路径或发布事故修复记录，都可能需要给变化后的 RRset 重新签名。因此，外部看到的稳定，更像是旧状态被成功冻结，而不是日常变更能力仍然健全。

草案要求签名软件不要因为找不到私钥，就自动删掉对应的旧 DNSKEY；旧 RRSIG 也应继续保留。若软件会清理它们，运营方可能需要手动补回。旧公钥已经不能创造新状态，却仍是当前信任链的必要部件。

ZSK 的时钟留在子区，但也不只在一台机器上

当 ZSK 失效而 KSK 仍可用时，运营方可以把新 ZSK 加入 DNSKEY RRset，并用现有 KSK 对该集合签名。新密钥出现在主服务器上，不代表已经可以启用。它必须先跨过权威传播延迟与 DNSKEY TTL：Ipub = Dprp + TTLkey。

等新 ZSK 进入“就绪”状态后，区域才能用它产生新签名。旧 ZSK 仍不能立刻删除。新的签名过程要结束，区域要传播，使用旧 ZSK 生成的 RRSIG 还要退出缓存。草案将这一退休期写为 Iret = Dsgn + Dprp + TTLsig。故障发现、密钥发布、就绪、激活和可安全移除是不同事件。

IETF 126 会议记录里有人指出，只丢失 ZSK 并不会立刻破坏连续性。这个判断恰好揭示治理难点：解析连续性可以保住，但区域的变更能力仍被冻结。不能把前者当作后者的证明。

KSK 把恢复权送到父区边界

如果失效的是 KSK，子区无法单独建立对替代密钥的信任。新的 KSK 需要父区发布新的 DS。草案采用 Double-DS 顺序：先提交新 DS，等待父区登记与发布，再等它传播并走完 DS 的 TTL，之后才在子区激活新 KSK。

父区发布时间等于提交时间加登记延迟：Tpub = Tsbm + Dreg。新 DS 的就绪期还要加入父区传播和 DS TTL：IpubP = DprpP + TTLds。RFC 7583 已经明确指出，涉及父区的 KSK 时序并不完全由区域管理者控制。

因此，“请求已受理”不能代替“父区已发布”，“某台父区服务器可见”也不能代替“已经跨过缓存安全边界”。签名方可以把自己的步骤加速，却不能命令父区的发布流水线或清空递归缓存。

CSK 失效会把两条依赖合并。它既承担 DNSKEY 的信任衔接，又签署区域数据。恢复必须先通过父区的 Double-DS 路径，同时重建区域签名能力。旧 CSK、旧 DNSKEY 与旧签名要保留到新 DS、新密钥和新签名全部走完各自的时间窗口；退休期还要取 DNSKEY TTL 与 RRSIG TTL 中较大的一个。

自动化失败后，仪式不会自动合法

健康状态下，CDS 或 CDNSKEY 可以让子区自动请求父区维护 DS。可是 ZSK 或 CSK 已经无法签名时，新加入的 CDS/CDNSKEY 本身无法按通常方式获得可信验证。草案因此要求受影响的 DS 恢复走手工路径。

手工并不意味着随意。DNS 托管方可能掌握运行账户，注册商掌握客户身份，注册局或父区运营方掌握最终写入权限。谁代表子区、谁核对替代密钥、谁批准绕开自动化、谁区分受理与实际发布，都必须留下记录。密码学事故只是把平时藏在自动化背后的制度链条重新显露出来。

次级服务器形成另一道缝隙。加入新 DNSKEY 时，为避免修改一条无法由旧密钥重新签名的 SOA，运营方可能保持 SOA 不变。依赖 IXFR 或 AXFR 的次级服务器因而未必收到正常的版本变化信号，需要逐台强制装载。主服务器响应正确，只能证明一个观察点，不能证明整个权威集群已经一致。

ZONEMD 也会受影响。DNSKEY RRset 改变后，旧区域摘要失效，必须生成并签署新的摘要。草案对 Knot DNS 的实现说明指出，所述手工流程不支持手动生成新 ZONEMD。这是一项明确的实施边界，不是多厂商兼容性结论。

IETF 126 的讨论要求更细致地比较 TTL 与签名到期，并补充对签名软件的实施证据。报告者表示已在 Knot DNS 上工作，主席要求增加实现章节。第 02 版因此比抽象流程多了一层实证，但证据仍然只覆盖有限实现，不能扩写成普遍部署。

一份不把时间压成单一状态的恢复记录

普通事故单常写“开始时间”和“恢复时间”。对于 DNSSEC 密钥失效，这两个字段会吞掉最重要的权限转换。本文建议的恢复时钟记录，首先写明事故类别、密钥角色和算法，再从实际提供的签名中计算最早的安全边界。

记录随后保存旧 DNSKEY 与旧 RRSIG 仍被提供的证据，列出新密钥在各权威实例出现的时间，以及传播延迟、DNSKEY TTL、DS TTL、RRSIG TTL 与签名耗时的取值。计算公式和输入必须同时公开，不能只留下一个绿色状态灯。

KSK 或 CSK 恢复还要把父区提交、身份核验、受理、观察到的发布和缓存就绪拆成不同栏位。次级服务器要逐个登记强制装载与观察到的内容。ZONEMD 要说明新摘要是否生成；若暂时缺失，谁批准、何时修复。新签名完成、抽样验证、旧材料可退休与真正删除也必须分开。

这不要求公开秘密。私钥、HSM 配置和个人事故资料都不应进入公共记录。制品哈希、key tag、时间戳、政策版本、已观察 RRset 和组织职责，足以建立可审计的链条。

记录也不能假装看见所有缓存。没有任何运营方能够遍历全球递归解析器。TTL 提供的是保守边界，多地观测提供的是样本。诚实的证据应说明观测范围，并让第三方根据 Dprp、TTLkey、TTLds、TTLsig 与 Dsgn 检查运营方为何认为某一步已经安全。

“已提交、已受理、已发布、已就绪、已激活、可退休、已删除”不是同义词。把其中任意一个写成“已恢复”，都会让结论先于证据。

第 02 版提供了扎实的技术路径：利用尚有效的旧签名，为新签名能力争取时间，同时避免故意把区域变得不安全或 bogus。它没有提供统一 SLA、父区承诺、全网缓存证明或通用审计格式。其治理价值在于揭示：剩余签名寿命是一笔由多方共同消耗的预算。只有每个时钟都对应一个能推动它的主体和一份证明，恢复才真正可问责。

来源

  1. DNSSEC Key Restore 第 02 版
  2. Datatracker 文件记录
  3. 草案历史
  4. IETF 126 DNSOP 会议记录
  5. DNSOP 活跃文件
  6. DNSOP 章程
  7. RFC 9364：DNS 安全扩展
  8. RFC 7583：DNSSEC 密钥轮换时序
  9. RFC 8078：通过 CDS/CDNSKEY 管理父区 DS
  10. RFC 8976：DNS 区域摘要
  11. RFC 9499：DNS 术语