摘要

  • ICANN 于 2026 年 8 月 10 日至 9 月 21 日就技术研究组初步报告征求意见，研究全球 DNS 的 gTLD 如何与替代命名系统中的相同字符串整合。
  • 报告的核心是“字符串 + 控制者”约束：所有系统中的名称与控制者都必须一致，可以依靠共享注册系统，也可以采用分布式架构，但必须维持统一事实来源。
  • 报告明确没有认可整合本身。每家注册局仍须通过 RSEP 或 2026 轮申请程序取得个案批准，拟议合同条款还会另行公开征询。
  • 一项实质政策问题被留在技术报告之外：替代系统已有的名称，可能迫使 DNS 端预留相应字符串，即使该名称从未在 DNS 中启用。

这是门槛测试，不是上线公告

ICANN 8 月 11 日发布的公告，很容易被简化成“DNS 要接入区块链名称”。实际范围要窄得多。自 2022 年以来，一些现有 gTLD 注册局和 2026 新 gTLD 轮潜在申请者询问，能否把全球 DNS 中的字符串与其他命名系统里的相同字符串关联起来。ICANN 因而召集 Technical Study Group，先回答一类共同的注册局服务问题。

研究对象并不包括所有钱包地址、应用账号、私有名称或替代根。它只处理一种情形：gTLD 运营者在全球 DNS 和一个或多个替代系统中控制同一字符串，且希望把它们作为整合服务提供。

当前也没有通用许可。8 月 10 日的 39 页文件标明是草案，公开征询页面称其为初步报告。技术组受命回答 RSEP 前置问题：这种有限模型能否在安全和稳定方面成立，需要哪些技术条件？

报告给出带条件的肯定答案。技术组认为，只要运行控制充分，“同名称、同控制者”不太可能在 RSEP 意义上产生重大安全或稳定风险。它同时强调，这不代表优先选择该机制，不代表否定其他机制，甚至不代表认可跨命名系统整合这件事。技术可行与制度同意，在文件中仍是两个不同动作。

真正的不变量不是区块链，而是控制

报告把模型称为“string+controller integration”。同一个名称在每个系统里，都必须由同一主体控制；若没有启用，则必须为该主体排他预留。只要无法持续满足其中任何一项，该命名空间就不属于报告所研究的整合类型。

约束也向下覆盖二级名称。一个名称在某个系统里被分配、转让、暂停或停用时，其他系统不能出现不相容的控制者。国际化域名还要先完成变体和标签生成规则处理；如果各系统的字符规范化不同，“同一个字符串”本身就可能失真。

报告提出两类架构。第一类让注册局的 Shared Registration System 成为统一登记入口，替代系统像后端扩展一样接入。传统注册局—注册商—注册人的责任链得以保留，但 EPP 需要扩展以操作新增状态，RDAP 也要扩展以公开相应数据。

第二类允许数据和运行分散在不同组件，却要求逻辑上只有一个事实来源。任何参与系统都不得接受会破坏“同字符串、同控制者”的变更。钱包、持久标识或密码学证明可以用于确认控制；分布式系统结算较慢时，DNS 注册操作可能需要进入等待状态，直到另一侧完成确认。

申请者要证明的不只是各方愿意同步，而是任何参与方都不能绕过控制者的指令或批准破坏整合。区块链的存在不会自动分散责任。即使多个技术运营者各自保管一部分状态，注册局运营者仍是对整个服务负责的单一法律主体。基础设施可以分布，责任不能被拆散后消失。

第一处权利冲突已经写在草案里

如果替代命名系统在整合前已有名称，技术约束会立刻带来分配后果。为了避免同一字符串落入两个不相容的控制者，这些已有名称必须进入共同登记状态；DNS 一侧至少要预留对应名称，即使它永远不会出现在 DNS 区域里。

报告承认这项技术结果“可能具有政策影响”，随后明确把它排除在研究范围之外。这里正是唯一性协调与权利分配的分界。预留能阻止冲突控制，保护整合服务的一致性；但它也会把原本可能开放注册的 DNS 名称移出市场。反过来，DNS 注册也可能限制替代系统中的使用。

工程约束无法独自回答：哪个系统的在先记录应当优先，如何通知失去可用性的申请人，防御性预留是否收费，错误控制证明如何纠正，两套历史相互冲突时由谁复核。同步数据库的能力，不会自动产生决定这些问题的授权。

ICANN 章程提供了一条边界。ICANN 可以协调为了 DNS 的开放、互操作、韧性、安全或稳定而“合理必要”的事项。初步报告也承认，ICANN 不负责互联网上的每一种命名系统，其介入不应超过替代系统实际影响全球 DNS 的部分。

Lu Heng 所强调的“薄协调”能进一步校准这条线。唯一性、控制证明、可审计状态和连续性可以属于公共层；既有主张之间的商业优先级、名称用途和价值分配，不会因为技术整合而自动变成公共层权力。阻止双重控制可以是一项狭窄的技术拒绝。更广的后果仍需明确决策者、受影响主体、公开理由与复核路径。

批准仍将是逐案、合同化的行为

本次征询没有建立通用许可证。ICANN 表示，每家希望提供该服务的注册局仍须单独走 RSEP，或走新 gTLD 轮适用程序。RSEP 会审查安全、稳定与竞争问题。统一报告的作用，是避免每个申请者为同一基础技术问题重复承担 RSTEP 成本，而不是取消对具体架构的审查。

最终合同也尚不存在。ICANN org 正根据技术组工作准备注册局协议修订文本。公开征询页面称，最终报告草案会与拟议合同条款一同进入后续征询；技术组章程预计还有第二轮意见期，并在 2027 年 1 月发布最终报告。因此，证据标准、监测频率、违约门槛、补救期、执行措施和申诉程序都还没有定型。

退出与进入同样重要。报告建议每项申请都必须有关闭整合的方案。它还指出，替代名称整合似乎不属于 Emergency Back-End Registry Operator 必须维持的关键注册局功能。注册局若严重失败并进入 EBERO，DNS 可能继续运转，替代系统整合却会中止。

这不是边角问题。一项以“多系统同一名称”销售的服务，恰可能在机构危机中分裂。申请者必须说明哪套状态继续有效、陈旧记录如何处理、注册人还保留什么，以及用户怎样获知变化。“同名”不是上线当天的标签，而是贯穿整个生命周期的承诺。

两轮征询需要分开的四件事

当前征询首先应检验技术条件：控制证明、同步、分布式结算、国际化名称、RDAP 可见性、转让、暂停、EBERO 和关闭机制。高质量意见应指出一条可复现的失败路径，而不只是表态支持或反对区块链名称。

后续合同征询必须把四项行为分清：技术组认定某种设计可以安全运行；ICANN 批准某个具体服务；合同授予监测和执行权；政策决定整合中被排除的名称或权利主张如何处理。四项行为的决策者、依据和救济并不相同。

初步报告的价值，正是把“连接 DNS 与区块链”的模糊口号，压缩成一个运行不变量、一个负责的法律主体和一个关闭难题。它若要保持正当性，就必须守住自己写下的限制。技术可行性能打开评估之门，不能独自决定谁拥有门槛。

来源