摘要

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02 是仍在推进的 DNSOP Internet-Draft，不是 RFC，也不是部署报告；其 Datatracker 元数据与文稿页眉对预期状态的描述并不一致。
  • DSYNC 负责发现父侧更新接收端，SIG(0) 负责认证请求，但自签名只证明私钥持有，名称范围、引导方式、父侧政策与 CDS/CSYNC 式检查仍决定请求能否获得授权。
  • NOERROR 表示请求已收到并被接受。文稿明确把父区发布写成未来事件，因此它不能证明权威服务器已经发布，更不能证明缓存、解析器或应用已经看到结果。
  • 真正可操作的自动化应分别记录请求、授权、接受、配置、权威发布、缓存暴露和应用结果；任何一步都不能代替下一步。

“已知”与“可信”之间是一项治理决定

修订版 02 允许子区通过普通 DNS UPDATE 把 SIG(0) 公钥提交给父侧接收端。最初的请求可以由待加入的密钥自己签名。验证成功说明发送者确实掌握私钥，却不能说明这个人、进程或服务有权管理该子区的委托。

所以接收端首先把密钥标记为“已知但未可信”。随后，它必须按父侧支持的方式验证授权来源：可以在已签名子区顶点验证 KEY，可以借助位于已签名命名空间中的权威服务器名称，也可以走人工核验。只有这一步结束，密钥才应进入可信集合。

未签名引导更弱。它能够识别当前控制权威服务器的一方，却不能自动证明对方就是注册人。这个差异不是密码学细节，而是控制权归属。如果系统只保留“签名有效”，事后便无法解释授权究竟来自 DNSSEC 链、人工手续，还是对当前服务器控制面的观察。

重新引导时风险更高。新请求可以包含删除旧 KEY 集合的意图，但父侧不得在新密钥验证成功前删掉原有可信密钥。否则，攻击者只需提交一个最终会失败的候选，就能先破坏仍然有效的授权路径。

DSYNC 只回答去哪里，不回答谁能决定

RFC 9859 的 DSYNC 记录为同步请求指出端点与用途。发现这个端点不等于端点身份已得到认证，也不等于任何发现者都获得了修改父区的权限。

文稿的默认授权规则把可信 SIG(0) 密钥名称精确绑定到子区名称。这样，一个子区的密钥不能修改相邻子区。父侧可以选择让注册商密钥管理多个子区，但这会扩大爆炸半径，也把逐项授权责任明确留给父侧。

签名与名称检查完成后，父侧仍要执行原本用于 CDS/CDNSKEY 或 CSYNC 的正确性与政策检查。审计轨迹、速率限制、批准逻辑以及与父区配置系统的集成都没有消失。方案减少的是父侧定时扫描的成本，而不是父侧对委托数据的最终权力。

因此，操作记录至少要保存 DSYNC 目标、解析结果、传输、接收端身份、子区名称、请求 RRset、签名密钥、时间窗口、政策版本和决定。只写“API 成功”，会把发现、身份、授权和政策压成一个不可解释的结果。

NOERROR 是接受凭证，不是发布凭证

文稿对代码零的解释很克制：更新已被收到并接受，父区数据应当在未来某个时间发布。“未来”意味着中间仍有配置数据库、API、区域生成、主服务器加载和从服务器同步。

如果控制器收到 NOERROR 就关闭变更，面板表达的事实比协议事实更强。平时这种捷径可能看不出问题；在更换 NS、更新 DS 或停止旧服务时，它可能让团队在父区仍公开旧委托时撤掉唯一可用路径。

可靠状态机应使用不同动词：已提交、已认证、政策接受、已入配置、主区已发布、父侧权威已收敛、旧缓存暴露期已结束、代表性解析器已观察、应用已验证。它们可能连续快速发生，但仍必须保留独立证据。

父侧主服务器出现新数据也不是最后一步。从服务器可能仍提供旧版本；不同权威地址可能回答不同 RRset。观察凭证应包含查询目标、时间、回答、TTL、验证结果和区版本证据。递归解析器的回答可以说明用户侧暴露，却不能替代权威观察，因为缓存旧值可能完全合法。

返回报文本身也需要反向信任

子区用 SIG(0) 签请求，不会自动让响应可信。父侧接收端应拥有自己的签名密钥，子区还要通过父区 DNSSEC 或人工方式取得并验证它。只有完成这条反向链，响应才是预期接收端作出的声明。

如果父区未签名且没有人工引导，攻击者可以伪造“密钥未知”一类响应，诱发不必要的重新引导。伪造响应不能直接授权父区变更，但足以造成中断、凭据轮换和重复请求。

日志因此要说明响应有没有签名、使用哪把接收端密钥、该密钥如何变成可信、响应代码和扩展错误是什么。即使这些字段全部正确，它仍只证明接收端说了什么，不能证明父区后来公开了什么。

双向引导使职责自然分离：子区控制请求密钥，父侧控制响应密钥，DNSSEC 或带外程序为各自建立信任。单个成功签名从来不能替相邻权力中心签字。

沉默不等于没有执行

没有响应时，发送方无法判断请求在途中丢失、接收端已执行但响应丢失，还是服务失效。修订版 02 给出至少五秒、指数退避和默认不超过五次重试的基线。它约束流量，却不产生状态结论。

重试还必须带有意图代际。旧请求不能在新决策之后重新写回旧 NS 或 glue。SIG(0) 的生效与到期时间限制重放窗口，但工作流仍需处理替代关系，并在重发前检查父区当前状态。

最好的消歧不是继续敲门，而是观察父区。如果权威状态已经等于请求，就不应因为响应丢失再次推进；如果父侧各权威不一致，就应记录“部分发布”，而不是从最后一个返回码推导整体成功或失败。

文稿状态限制结论强度

证据冻结时，修订版 02 日期为 2026 年 6 月 17 日，Datatracker 最近更新为 9 月 25 日，到期日为 12 月 19 日。工作组状态是 Waiting for WG Chair Go-Ahead Other - see Comment Log，IESG 状态是 I-D Exists。

Datatracker 没有显示预期 RFC 状态，文稿页眉却写着 Standards Track。本文保留这个差异，不替来源做统一。拟议的注册值、示例与流程都可能变化、过期或被取代。

被冻结的来源没有证明任何特定注册局、注册商、TLD 或权威运营商已部署它。开头场景是分析构造。本文能讨论证据边界，不能虚构一次真实故障或成功迁移。

自动化应交付证据图，而不是绿色终点

证据图从子区意图开始：旧状态、新状态、原因、代际和批准者。随后追加 DSYNC 发现、双方密钥引导、名称范围、正确性检查、父侧政策和响应。NOERROR 之后继续追加配置任务、父区版本、各权威观察、TTL 暴露期、解析器样本和应用结果。

每条边都有所有者、时间和散列；未知值不被默认成功覆盖。这样，团队才能在父区未发布时延迟撤旧，在响应丢失但状态已生效时避免重放，在引导失败时保住旧密钥，并准确指出故障停在哪一层。

最终结论很窄，也更可靠：SIG(0) 可以认证一个受范围约束的请求，NOERROR 可以证明接收端接受了它。公共父区是否改变，必须由下一份凭证回答。

来源