摘要

  • 10月16日的一份公开意见要求ICANN将DNSSEC委派签名者（DS）自动化评估与IETF已发布的RFC 10026对齐。
  • 6月的报告一处称，遇到注册局更新锁就应暂停自动化；后文却说注册局侧的自动化可以继续。硬性要求HR-4只明确写到了注册商侧的锁。
  • ICANN表示会审阅意见，并可能更新评估报告。征询将于11月23日截止，意见摘要报告预计12月7日发布；目前还没有最终决定或合同条款。

争议并非DNSSEC是否适合自动化，而是父区的DS记录发生变更时，注册状态锁究竟限制哪一方。Quynh Nguyen在10月16日向ICANN提交的意见，将这一问题带入DNSSEC DS自动化安全与稳定性评估的公开审查。

Nguyen认为，评估已覆盖主要风险，但对serverUpdateProhibited应给出一致说法。她注明意见以个人身份提交，因此它不是ICANN的结论，也不能代表社区共识。不过，这一具体规则可能影响ICANN计划建立的快速RSEP程序：希望自动维护DS记录的注册局运营方将以这份评估作为技术依据之一。

Interisle Consulting Group编写的评估报告日期为2026年6月23日。第4.4节采纳了一种解释：只要存在serverUpdateProhibited，就应暂停DS自动维护。该节同时提到当时引用的IETF草案持相反立场，认为在由注册局主导的自动化中，这个状态要求EPP服务器拒绝注册商提交的更新请求，却没有禁止注册局自行修改记录。

这份草案后来成为RFC 10026，并于7月作为最佳当前实践BCP 246发布。第6.1(2)条明确规定：当注册局执行DS维护时，不得仅因存在serverUpdateProhibited而暂停自动化。第6.2.1节解释了权限边界：这一状态挡住的是注册商通过EPP提交的变更，不是注册局自己执行的流程；向注册商发送通知有助于让变更可见。

报告内部也存在张力。第4.7节称，在clientUpdateProhibited和serverUpdateProhibited两种状态下，部署都可以继续；第6.1节又指出，如果注册商可以退出注册局主导的自动化，这两种锁不必令日常维护停下。然而，HR-4只明确要求不得仅凭clientUpdateProhibited暂停自动化。Nguyen希望ICANN写出一条与RFC 10026一致、不会产生两种读法的规则。

版本时间线提供了另一项参照。安全与稳定咨询委员会（SSAC）于8月31日发布SAC126v2，称该版本已按RFC 10026更新建议，并说明BCP 246解决了旧版第4.4节提出的问题；SAC126第一版已退役。换言之，ICANN手上这份6月评估早于正式RFC及更新后的SSAC建议。

这份意见还提出其他澄清：权威名称服务器被认定为永久不可达时应使用什么判据和重试间隔；响应不一致导致密钥轮换延迟时如何处理；撤除DS记录会给依赖DNSSEC的服务带来什么后果；对成功变更、拒绝请求及其他故障分别需要怎样的通知和审计记录。这些都是一位评论者的建议，不是已经生效的要求。

ICANN的征询页面表示，将发布意见摘要、考虑是否修改评估，并随后刊发附录式更新。征询截止日为2026年11月23日，报告预计12月7日提交。快速RSEP的合同修正草案则将在另一次程序中征求意见。无论这份评估还是个人意见，都没有批准部署或决定未来条款。

来源