摘要

  • ICANN 正在征询公众意见，评估自动管理 DNSSEC 委派签名者（DS）记录的安全与稳定性要求是否完整、适度且能够执行。
  • 报告的正面结论附带条件：部署必须满足七项硬性要求，并披露七类运营选择；这不是对所有注册局的一揽子批准。

注册锁的处理是这条 DNSSEC 快速通道最需要澄清的实质问题。 ICANN 征询公告列明了意见期限和审议范围。

这份 41 页的评估标注日期为 6 月 23 日，研究范围也很具体：子区 DNS 运营者发布 CDS 或 CDNSKEY 记录，父区一方——通常是注册局或注册商——验证后决定是否更新父区中的 DS 记录。报告覆盖已有信任链的维护、首次启用和转为不安全委派三种流程，但不涵盖推送式通知、带外 API 或 CSYNC。因而它讨论的是一类自动化机制，不能直接代表所有委派变更方法或任一运营者的具体实现。Interisle 的评估报告给出的结论是：达到要求后，该机制不构成 RSEP 定义下的重大安全或稳定问题。

七项硬性要求决定了这个结论的边界。父区必须确认拟发布的每条 DS 都能对应到子区的 DNSKEY，并由新 DS 指向的密钥签名；还必须从所有权威名称服务器检查信号是否一致，不一致就停止并稍后重试。运营者也须保留人工管理接口，提供注册商退出自动化的途径，正确处理删除全部 DS 的信号；若注册局执行更新，还须通知赞助注册商。另有七类事项必须写入运营文档，包括扫描频率、响应时限、多签名者策略、通知接收人和自动引导所需的条件。报告还列出四项建议做法，但不把它们列为正面结论的前提。

这个结构把共同底线和运营者自主选择分开。RFC 9975 所要求的跨名称服务器一致性属于共同底线；扫描间隔、通知渠道和回滚时间则取决于部署，必须透明披露。后一类选择会决定错误更新能否及时发现，也会影响域名持有人能否知道 DS 已改变。报告指出，相关 RFC 并未规定所有成功、拒绝或状态漂移都要通过统一渠道报告。因此，机制可验证，并不等于每个受影响的人都能及时获知结果。

时间线上还有一个值得在意见中核实的变化：评估日期是 6 月 23 日，IETF 的 RFC 10026 于 7 月发布为 Best Current Practice。ICANN 当前征询页面已将 RFC 10026 列为支持材料，六月版本的评估正文则保留了当时的草案时间线。如今该状态已经改变：RFC 10026包含接受检查、报告透明度、注册锁和多方更新等操作建议。这并不自动使六月的评估失效，却让征询产生一个具体问题：七项要求和披露清单如何与已发布的 BCP 246 对照，未来注册局申请是否需要逐项说明这种对应关系。

分歧具体出现在报告对注册锁的分析中。报告沿用 SAC126 的观点：serverUpdateProhibited 应暂停注册局主导的自动化；只有 clientUpdateProhibited 时则应继续。后来定稿的 RFC 10026 对注册局锁采取相反解释：注册局可以覆盖自己设置的状态，因此不能仅凭该锁停用注册局自身执行的自动化；注册商退出机制才是表达不同意愿的控制。报告汇总的硬性要求明确写入了客户端锁规则，却没有并列写出注册局锁规则。ICANN 当前征询页面已将 RFC 10026 列为支持材料，参与者可以据此询问后续申请和合同条款究竟采用哪项规则。

ICANN 董事会在 2025 年 9 月已经要求组织为注册局建立快速 RSEP 路径，前提是未发现安全或稳定问题。董事会同时说明，注册商无需获得 ICANN 批准即可部署该服务。RSEP 原有流程仍包括初步判断；若存在重大风险，仍可转交技术评估小组。因此，这份评估是未来注册局申请的共同技术依据，不是某个注册局的批准书，也不是已经生效的新合同规则。董事会决议和RSEP 政策界定了两者分工。

评论者可以把问题落到三处：硬性要求是否覆盖现行 BCP；披露能否让域名持有人了解等待多久、向谁求助以及如何恢复；后续合同文字是否仍保留对不同实现的逐案核验。当前技术评估征询将在合同草案公开之前结束，故 12 月的意见汇总与下一轮合同征询是两份不同的过程证据。清单最终能否改善决策，要看它是否既可复用，也不抹掉每项部署的差异。