摘要

  • ICANN 技术研究组只研究一个受限模型：同一字符串同时用于全球 DNS 的 gTLD 与一个或多个替代命名系统，由同一主体控制，并由注册管理机构协调。
  • 初步报告建议在服务评估时强制提交停用计划，同时指出这种整合似乎不属于 EBERO 接管的五项关键注册服务功能。
  • 第一轮公众意见征集将于 2026 年 9 月 21 日结束；当前文件不是最终政策、获准服务或任何现实故障的证明。

名字相同，不等于权利相同。

ICANN 技术研究组 8 月 10 日发布的初步报告，正是从这条边界出发。它没有试图为所有替代命名系统建立统一规则，而是把范围收窄到“字符串加控制方”的整合：全球 DNS 中的 gTLD 字符串必须与另一命名系统中的字符串相同，控制这些名字的主体也必须相同。注册管理机构负责协调；即使某些技术组件交给服务商运行，政策责任仍留在注册管理机构。

报告认为，在具备适当运营控制的前提下，这个模型不太可能造成 RSEP 意义上的重大安全或稳定性问题。这个判断不是零风险承诺，也不是对替代命名系统的普遍背书。报告明确保留其他设计的可能性，也没有把研究对象写成已经获批的产品。

停止解析只是退出的一小部分

这套模型区分多种名字状态：可用、已纳入、已分配、已保留、已激活、已停用、已暂停以及完全禁用。状态之所以要细分，是因为“关闭”可能指向截然不同的结果。

停止新注册，不会自动处理已有名字；停止替代系统中的解析，不会说明名字是否仍归原控制方；从界面上删除条目，也不能证明缓存、分布式账本、外包系统和合同权利已经同步。若 DNS 名字完成转让，而替代身份仍由旧注册人控制，两个系统都可能按各自规则正常运行，治理关系却已经断裂。

因此，整合需要维护的不是单纯的字符一致，而是字符、状态与控制者三者的一致。名字在一个系统被分配后，另一个系统不能把同名身份留给不同主体。名字转让、到期、暂停或服务终止时，也必须有明确的同步动作。

IETF DNSOP 工作组的活跃草案从生命周期角度描述了同一风险。它把控制验证、完整覆盖与持续同步分开，并指出过期的整合可能让当前注册人之外的主体继续控制关联身份。这份 Internet-Draft 仍是进行中的工作，不是 ICANN 规则；但它说明了为什么入口验证不能替代退出验证。

EBERO 的连续性有明确边界

当 gTLD 注册管理机构面临无法维持关键职能的风险时，ICANN 可以启用 Emergency Back-end Registry Operator。EBERO 保护的五项职能分别是：注册名字的 DNS 解析、共享注册系统、注册数据目录服务、注册数据托管，以及维持正确使用 DNSSEC 签名的区域。

替代命名整合不在这份列举中。研究组报告据此认为，相关整合似乎无法在 EBERO 接管期间继续运行，所以申请服务时尤其需要准备停用计划。

这不是在说 EBERO 设计失败。恰恰相反，报告把它的授权范围说清楚了：EBERO 接管特定 DNS 注册服务职能，并不自然继承围绕注册管理机构新增的每一项产品。若运营者把“注册局有应急连续性”包装成“所有附加身份服务都会持续”，就借用了一个并不覆盖该服务的保障。

计划不能替代演练结果

报告建议，注册服务定义应当列明整合提供的能力，以及在商业上不可持续或运营上需要退出时如何停用这些能力。在积累充分的实际经验前，停用计划应成为评估中的强制内容。

这个要求很重要，但它回答的是“准备怎样做”。它没有回答“做过以后发生了什么”。计划可能依赖故障期间无法联系的供应商，遗漏部分停用状态，把最后一步交给已经离场的注册人，或假定 DNS 与替代系统总能按预定顺序恢复。一次演练也可能只验证停止新接入，却没有验证旧名字如何释放或保留。

RSEP 提供了制度路径。注册管理机构通过该程序提出新增、修改或移除注册服务，ICANN 评估潜在的重大安全、稳定性与竞争问题。报告还强调，不能仅为了商业可行性而削弱最低技术条件；如果删去这些条件，得到的是另一项服务，应当另行评估。

同样的约束应当适用于退出测试。若演练后仍有未统一的状态，正确做法是记录例外、修正设计并重新验证，而不是事后缩小“已经停用”的定义。

公众意见仍在塑造文件

当前报告仍标有草案属性。第一轮公众意见征集于 8 月 10 日开启，9 月 21 日结束。研究组章程随后安排处理意见、在 10 月发布第二版并再次征求意见，最终报告目标为 2027 年 1 月。这些都是预定步骤，不能当成已经完成的采纳决定。

现有一手资料没有证明某个具名注册管理机构已经运行这种整合，没有显示实际控制者发生分裂，也没有出现 EBERO 接管该类服务的案例。本文讨论的是一个尚可提前设计的证据问题，而不是给未发生的故障定责。

来源