摘要

  • RFC 9859 让子区可发现父侧公布的 DSYNC 端点，并提示其尽早检查 CDS、CDNSKEY 或 CSYNC 的变化。
  • 端点发现、消息发送和响应确认只构成信令链；它们不证明父侧已验证、接受或公开发布委派变更。

委派维护最容易被误报的地方，不是技术细节，而是把“系统开始动了”说成“系统已经决定了”。RFC 9859 解决的是真实的效率问题：子区一旦发布新的 CDS、CDNSKEY 或 CSYNC 记录，不必被动等待父侧周期扫描。它可以通过 DSYNC 找到已公布的接收端，并以广义 NOTIFY 提醒对方现在就检查。这个设计缩短了等待时间，却没有缩短决定所需的责任链。

RFC 的表述非常克制。通知只是让接收者比原定计划更早启动一项预先存在的动作；它不改变该动作本身，也不改变动作中的安全检查。DSYNC 记录提供的是 RR 类型、方案、端口和目标地址。它回答“提示可以送到哪里”，并不回答“提示中的状态是否成立”“谁有权接受”“父区最终会写入什么”。

这一点在注册局、注册商和受托服务商共同参与时尤其重要。RFC 9859 明确不规定父侧内部如何分工。一个公开端点能够让子区把通知送达，却不会因而披露或授予最终决定权。把端点当作同意，把可投递性当作授权，正是将协调记录误写成治理结论的开始。

同样，NOTIFY 响应也必须被精确理解。接收方可以确认收到，然后立即安排 CDS/CDNSKEY 或 CSYNC 的检查；它也可以在不处理请求时仍然确认，以免发送方持续重试，例如当速率限制生效时。因此，响应只说明这一次消息交换足以让发送方结束重试队列。它不是“变更成功”的回执，也不是父区已写入 DS 的证明。

真正承担后果的工作发生在随后。RFC 9859 建议子区先等相关记录在公共权威服务器上形成一致视图，再发送通知，否则父侧可能过早读取到不一致数据。即使已确认收到，后续处理仍可能异步失败，例如不满足连续性要求。对于 DNSSEC 初始引导，RFC 9615 要求父侧代理分别从权威服务器取回数据、验证信号链、比较 RRset，并在特定错误下中止；RFC 8078 则保留父侧对初始 DS、轮换和回到不安全状态的接受政策。通知能触发这套程序，不能代替这套程序。

因此，一套能经得起审计的记录应至少分开保存七类事实：DSYNC 的发现及其 DNSSEC 状态；发出的 NOTIFY；传输确认；父侧实际取得的权威数据；验证和连续性结果；有权主体的接受或拒绝决定；以及父区发布后从外部解析到的状态。把这七步压缩成一个绿色“已同步”标记，得到的不是委派完成的事实，只是一段看上去很顺畅的消息流。

这正符合 Heng Lu 的基本要求：协调工件应描述已被采用的现实，而不是凭记录宣告未来现实。DSYNC 是协调工件，NOTIFY 是时间工件。它们因边界清晰而有价值。委派是否完成，必须由真正执行验证和发布的一方，在可追溯的规则下作出并留下证据。

RFC 9859 所支持的结论很有用，但也很有限：它能缩短“子区已发布”到“父侧开始审查”之间的间隔。它并不证明子区已经获得一项委派变更。对承载信任链和可达性后果的系统而言，守住这个边界不是拖延，而是责任仍可被识别的前提。

来源