摘要

  • draft-ietf-dnsop-dnssec-automation-05 是 DNSOP 的活跃 Internet-Draft，不是 RFC、部署证明或迁移结果；Datatracker 与正文页首对预期状态的描述也不一致。
  • 草案把多签名者加入、退出和密钥轮换拆成 DNSKEY、CDS/CDNSKEY、CSYNC、父区 DS/NS 发布以及四类等待窗口。
  • 等待窗口是必要的下限条件，不是收敛收据。每个计时器都必须绑定一个已观察到的起点、受保护对象和结束复核。
  • 草案明确把普通区内容同步排除在范围外。基础设施记录一致、签名可验证，仍可能同时存在相互矛盾的业务答案。

完成的是哪一份合同

RFC 8901 的模型 2 允许多个 DNS 运营商各自保管 KSK、ZSK 或 CSK，共同为同一域签名。修订版 05 把这一结构同 CDS/CDNSKEY 和 CSYNC 组合起来，描述如何建立、运营、拆除多签名组，并在不中断信任链的情况下更换运营商。

它解决的是一组基础设施依赖：每个签名者能否加入别人的公钥，所有签名者能否公布一致的 DNSKEY 和子区信号，父区是否公布组合 DS 与 NS，旧权威和旧密钥何时才可以退出。这个顺序很重要，因为任何一步提前都会让下一步借用尚未存在的权威。

但草案同时明确指出，除 NS、DNSKEY、CDS 等基础设施记录外，普通区内容如何同步不在范围内。于是“自动化完成”只能说明预先定义的基础设施状态机走到了末尾，不能说明 A、AAAA、MX、TXT、否定证明等业务数据已经相同。

领导层首先要问的不是自动化是否成功，而是成功状态覆盖了哪些对象、排除了哪些对象。一个没有内容平面收据的绿色状态，不是错误；把它解释成完整迁移才是错误。

四个等待窗口保护四种暴露

DS-Wait-Time 从父区已经取用并发布新 DS 集合之后开始，最低不短于 DS TTL。子区公布 CDS/CDNSKEY 是意图，父区扫描或收到通知是触发，注册系统接受任务是流程收据；它们都不是公开父区已经服务新 DS 的证明。

DNSKEY-Wait-Time 保护新密钥视图的传播。下限要考虑所有签名者中最大的 DNSKEY TTL，以及把区发布到全部辅助权威所需的时间。主服务器写入成功不能替辅助服务器签字。

NS-Wait-Time 保护查询路径。它建立在父区公布新 NS 集合之后，并取父区与签名者 NS TTL 的最大值。CSYNC 记录正确，只说明子区表达了同步意图，不说明父区已经改变委派。

RRSIG-Wait-Time 保护旧密钥签出的数据。旧签名停止生成以后，旧 DNSKEY 仍须保留到相关签名可能从解析器缓存消失。轮换任务结束不等于最后一份旧签名已经失去效力。

四个值都可以显示成倒计时，但它们的起点、对象与责任人不同。把它们压成一个“等待完成”，就删掉了事故复盘需要的最重要信息。

没有观察起点，时长无法审计

计时器不能替不确定的起点补证。如果控制器从发送 CDS 时开始算 DS 等待，父区尚未发布的时间也被错误地计入安全窗口。如果从注册局确认工单开始算 NS 等待，流程接受就被当成权威 DNS 状态。如果从主机本地写入开始算 DNSKEY 等待，辅助权威的延迟被隐藏。

可靠的起点收据至少包含：准确 RRset、权威观察点、时间、TTL、验证状态、区代际或序列，以及采用的策略版本。计时结束以后还要复核后继状态。睡眠只是经过了时间，不能创造观察。

这不要求枚举全球每个解析器缓存。DNS 的 TTL 提供的是在给定假设下的到期上界，不是全球可见性证明。运营者可以说旧状态按记录的边界已不再有效，却不能说每个解析器都看见了新状态。

加入组意味着把退出条件一起写下

新签名者加入前，应当已经正确服务并签名该区，使用组内兼容算法，并能区分自己的密钥、外来密钥、自己的 NS 与组成员引入的 NS。没有来源标记，未来清理会把“删除哪一个对象”变成猜测。

组内随后分发数据签名公钥，编译覆盖全部 KSK/CSK 的 CDS/CDNSKEY，等待父区公布组合 DS，再编译共同 NS 并推动父区更新。任一签名者的局部正确都不能证明整个组准备好。

因此，加入收据要列出每个参与者看到的密钥和记录，而不只是成员名单。它还应当预先写明退出拥有者、重叠成本、可延长期限、撤销渠道和谁有权在证据不齐时阻止商业下线。

退出先移路径，再移验证材料

退出签名者时，剩余成员先从自身 NS 集合移除它，父区再公布缩减后的委派。经过 NS 暴露窗口后，退出者才停止回答。随后组内更新 CDS/CDNSKEY，等待旧签名的缓存暴露结束，最后才移除退出者的 DNSKEY。

这里有两张不同收据：查询是否还可能到达旧权威；旧权威签出的数据是否还可能被拿来验证。NS-Wait-Time 处理前者，RRSIG-Wait-Time 与继续公布旧密钥处理后者。合同终止日期不能同时回答这两个问题。

若商业关系先结束，协议安全可能要求继续提供一段时间。若协议流程先结束，组织仍要证明凭据、控制通道和外来密钥已经撤销。谁承担重叠服务、谁批准延迟、何种证据释放退出运营商，必须在迁移前决定。

一致的密钥可以签出不一致的答案

基础设施面已经收敛时，内容面仍可能分叉。三个权威可以公布相同 DNSKEY 与 NS，同时一个服务新记录，一个服务旧记录，第三个服务签名的不存在。每个答案都可能在 DNSSEC 规则下有效。

DNSSEC 证明数据来自适用密钥并符合验证链，不证明哪一份数据代表区所有者的最新意图。内容同步需要单独的传输授权、生成号或 SOA 证据、内容比较、签名策略一致性和逐权威查询。

因此，最终状态至少要拆成“基础设施已收敛”“内容已验证”“解析器观察已抽样”“应用结果已验证”。缺少内容集成时，应当明确写“内容未验证”，而不是让读者从密钥状态推断。

中央控制与分布式控制各有盲点

中央模型由一个控制器计算等待并操作全部签名者，易于生成统一账本，也集中大量凭据和判断权。一条过期观察或越权指令能让整个组同时进入错误状态。

分布式模型让签名者彼此通信并各自执行限制，降低单点控制，却引入视图一致性问题。参与者可能拿到不同 TTL、成员列表或父区观察。每个节点的本地计算都正确，组合结果仍可能不安全。

草案要求一个受认证的“信任机制”来修改 DNSKEY、CDS/CDNSKEY、CSYNC 与 NS，但没有规定详细实现。这个机制仍需主体、区与记录类型范围、审批、轮换、撤销和审计。通道认证只说明谁连接，不自动证明这次改变被授权。

草案状态限制公开结论

在证据冻结日，Datatracker 把修订版 05 列为 DNSOP 活跃草案，工作组状态为等待主席放行，IESG 状态为 I-D Exists。Datatracker 页面称预期为 Informational，而草案页首写 Standards Track，并注明 2027 年 1 月 6 日到期。

这项差异应原样保留，不能选取更强的一种作为结论。它不证明共识完成、RFC 发布、软件支持、部署占比或互操作成功。来源也没有证明任何具名提供商、域名、迁移、故障或性能结果；开篇只是用于暴露证据缺口的构造案例。

真正可复用的是状态转移账本

每次转移应记录域名、组代际、参与者、对象、期望与观察到的 RRset 哈希、权威视点、TTL、验证状态、策略、最早下一步时间和批准主体。父区意图与父区发布分开，缓存窗口与全球观察分开，内容同步与密钥同步分开，应用成功与 DNS 收据分开。

未知必须保持未知。无法确定全部辅助权威何时发布新 DNSKEY，就不能制造精确起点；无法看到父区发布，工单状态不能补空白；内容同步不受控，最终状态就不能宣称完整收敛。

草案能够提供的稳健承诺很窄：为多签名 DNSSEC 转移规定必要顺序与最低等待。它不能单独证明全球缓存、普通区内容、解析结果与业务结果。每个更宽的结论都需要自己的观察者与责任人。

来源