摘要

  • 当前征询审查的是一份署期为六月的 DNSSEC DS 自动化安全与稳定评估；RFC 10026 七月成为 BCP 246，ICANN 的征询页面已经把它列为技术依据。
  • 评估之后还会有一轮独立的公开征询，讨论 Fast-Track RSEP 的标准修订文本。“快车道”前面仍有两道公开关卡。

一条快车道要开两轮公开意见征询，听上去不像在赶时间。问题在于，先得确认这条路承载的是什么。

ICANN 于 10 月 12 日启动本轮征询，问题很具体：一份 41 页的评估，是否正确识别了 DNSSEC 委派签名记录（DS）自动化涉及的安全与稳定问题；提出的缓解措施是否足够、适度、可执行。意见截止日期是 11 月 23 日，汇总报告定于 12 月 7 日提交。

相关机制对 DNS 运营者并不陌生：子区发布 CDS 或 CDNSKEY 记录，表示要更新 DS；父区一侧——通常是注册局或注册商——检查信号，再更新父区里的 DS。密钥轮换因此可以少几次人工工单。可如果父区接受错误信号、漏掉权威服务器之间的不一致，或没处理好多签名者，自动化也能把信任链一脚踢断。

报告把判断分成三档：七项硬性要求是得出正面安全与稳定结论的前提；七项披露要求必须写进运营设计，但具体选择留给运营者；四项建议做法能改善部署，却不是报告所述标准环境下取得正面结论的必要条件。报告还点名多签名者情形、变更可观测性，以及用于启动流程的名称服务器必须位于已签名区域等残余问题。

时间差藏在文件里。评估署期为 2026 年 6 月 23 日；文中仍称 draft-ietf-dnsop-ds-automation 正处于 IETF 评审阶段，并预测它发布为 BCP 后会成为操作参考。RFC Editor 记录的 RFC 10026《DNSSEC 委派签名自动化操作建议》则在 7 月发布，编号为 BCP 246。10 月的 ICANN 征询页面已经把 RFC 10026 列为描述相关机制的文件。征询页面是新的，PDF 里几句将来时已经过期。

这给评论者留下了一个明确的问题：后续附录会如何把最终 RFC 的状态和文本纳入评估？哪些仍是 ICANN 自己的 RSEP 判断标准？RFC 10026 写下操作建议；ICANN 的评估则依据 RSEP 标准审查注册局服务。

ICANN 董事会在 2025 年 9 月 14 日要求为注册局运营者建立 Fast-Track RSEP，前提是没有发现安全或稳定问题。ICANN 计划考虑本轮意见、酌情更新评估并发布附录，之后再单独征询标准修订文本。目前并没有公布第二轮的日期。

一手文件