摘要

  • DNSOP 草案第 02 版让子区用普通 DNS UPDATE 提交 NS、glue 与 DS 的精确变更，以 SIG(0) 保护交易，并通过 DSYNC 寻找父区接收端。
  • 新 KEY 的自签名只证明私钥在手。父区必须先把它记为 known，再依照明确的引导方法把它提升为 trusted。
  • 重新引导时，新钥匙通过验证之前不得删除旧可信钥匙；之后即使收到 NOERROR，也只证明接收与接纳，不证明父区已发布或解析器已看见。

这份草案最值得警惕的不是密码算法，而是一条删除指令。

draft-ietf-dnsop-delegation-mgmt-via-ddns-02 规定，引导可以从一条自签名更新开始：删除子域名下原有的整个 KEY RRset，再加入新的 KEY。接收端可以用新 KEY 验证它自己的签名。因此，“某人确实拥有这把私钥”是可验证事实。但如果这个事实自动等于委派授权，任何人都可以现场生成一对密钥，签署一条替换请求，先把正在工作的钥匙赶出去。

草案用两个状态挡住这条捷径。新 KEY 到达并通过自签名检查后只是 known：系统知道它存在，也知道发送者能使用它。随后还要执行父区选择的独立验证，成功后才成为 trusted。旧可信 KEY 在此期间继续有效。只有新候选完成提升，删除和替换才可以落地。

这个状态机正处在一个实时标准节点。DNSOP 在 8 月 20 日发起工作组最后征求意见，公布的截止日是 9 月 7 日。9 月 4 日，一位主席明确要求更多正面支持与建设性意见，因为“没有反对”还不够。Geoff Huston 支持推进，认为它比父区轮询更高效。Johan Stenstam 强调未签名子区的价值，并披露了自己的实现角色。Michael Richardson 表示文字已足以据此写代码，同时要求更清楚地区分 KEY 与 DNSKEY、说明密钥状态和未来算法，并建议画出状态机。这些是个人技术意见，不是工作组共识、IETF 批准或互操作部署证明。

方案刻意复用旧协议。子区发送 RFC 2136 的普通 DNS UPDATE；RFC 2931 与 RFC 3007 的 SIG(0) 规则为交易签名；RFC 9859 的 DSYNC 记录发布父区是否接收、接收端在哪里。UPDATE Receiver 是父区授权下的逻辑角色，可以与主权威服务器分开，也可以只把请求交给配置数据库或 API。

因此，签名包不是自动执行许可证。接收端要限制可以修改的 RRset，默认只允许与子域同名的可信 SIG(0) KEY 管理该子域，还要继续执行 CDS/CDNSKEY 和 CSYNC 所要求的父区检查。推送解决的是发现与传递成本，不会取消父区的决定。

不同引导路径证明的主体也不同。已由 DNSSEC 签名的子区可以在 apex 发布 KEY，让父区沿签名链验证。未签名子区若使用位于已签名区域的权威服务器，可由该服务器的运营方在自己的签名区里发布专用 KEY 信号。少量委派还可以走人工渠道。

完全未签名的情形只能依靠多次观测。父区从不同位置、时间和传输方式查询子区权威服务，比较看到的 KEY 是否与提交值一致。这会提高路径劫持的难度，却不会凭空生成注册人权利。草案明确说，它认证的是当前权威服务器运营者，而不是注册人；证明强度不可能超过这些服务器本身。

记录类型也不能含糊。这里使用的是 KEY，不是 DNSKEY。DNSKEY 参与 DNSSEC 区签名信任结构；KEY 在这里用于验证一条 SIG(0) 交易。若资产清单把二者都写成“DNS 密钥”，轮换、保管、泄露响应与授权范围都会失去负责人。

返回码仍然只是局部收据。NOERROR 表明接收端已经收到并接纳 UPDATE，父区数据预计稍后改变。它没有证明配置任务完成、权威区发布、缓存到期或解析成功。REFUSED 可能来自策略、限流或配置错误，一次拒绝未必是永久结论。BADKEY 表示接收端缺少验证所需的公钥，但不能独自描述所有引导中间态。没有响应，更无法区分请求丢失与应答丢失。

真正可审计的链条应逐项保存：DSYNC 端点与策略版本、UPDATE 摘要与前置条件、KEY 身份、采用的引导方式、known 与 trusted 的时间和证据、接收决定及其签名、配置交易、父区序列号、权威 RRset 观测、TTL 后各解析视图，最后才是业务服务结果。

这正是 Heng Lu 所强调的现实分层。一条数据库记录可以准确说“钥匙已知”，却没有资格把它改写为“权力已经成立”。草案可以完成技术描述，却不等于采用。父区可以接纳请求，公共 DNS 仍然没有变化。自动化只有在这些层次没有被一个绿色勾号吞掉时，才值得信任。

来源