摘要

  • ICANN 技术研究组讨论了这样一种情况：DNS 名称到期后停止全球解析，但另一套系统中的同名名称可以继续有效，前提是该系统允许、登记人也选择保留。
  • “同一字符串、同一控制人”必须经得起续期、转移、暂停和删除等状态变化。服务需要规定每一步由谁授权、如何确认、未完成时如何限制影响，以及何时可以重新分配名称。

到期的是哪一项权利

设想登记人不再续费 example.tld 的 DNS 注册，却希望保留另一套命名系统中的同名名称。ICANN 技术研究组（TSG）的初步报告专门列出这个场景。这不是对某次真实事故的描述，也不是一项适用于所有替代系统的统一政策。报告指出，DNS 名称会被撤出全球解析；另一套系统中的名称是否继续有效，则取决于该系统的续期规则，以及登记人是否希望保留它。

如果登记人不想继续使用替代名称，处理也不是简单删除一条 DNS 记录。报告给出的顺序是：先在所有关联系统中停用名称，再解除分配，最后从集成关系中移除。完成这套步骤后，名称才重新可用。在这个过程中，可能会暂时存在“DNS 已到期、另一边仍然活跃”的合法状态。风险来自服务没有说清楚谁能选择这种状态、各方如何知道它、以及旧名称何时允许交给新登记人。

所以，到期不是后台的一次清理动作，而是一次治理决定。“同一字符串、同一控制人”很适合作为集成的起点，却不是对持续状态的完整说明。续期、注册人内部变更、注册商转移、滥用处置和暂停都会改变名称状态。只检查某个时间点的两条记录相同，不能证明是谁启动了变更，也不能证明另一套系统已经接收。

技术研究不等于服务批准

ICANN 成立 TSG，是为了研究全球 DNS 通用顶级域名（gTLD）与替代命名系统使用同一字符串时，能否以安全、稳定的方式运行，以及需要哪些技术条件。2026 年 8 月 10 日发布的初步报告标注为草案。它没有批准任何集成，也没有把某一种架构定为唯一答案；报告讨论了通过注册局共享注册系统（SRS）操作，以及依靠统一事实来源（USoT）进行分布式协调等方式。

ICANN 的公开征求意见页面说明，每个希望提供这种注册局服务的运营方都要单独通过注册局服务评估政策（RSEP）。TSG 报告将为后续个案评估和标准合同条款提供依据；合同草案还要进入之后的公开征求意见。该页面记载意见提交于 9 月 21 日截止，报告预计在 2026 年 11 月 16 日发布。

共同研究可以减少每个申请人重复回答相同技术问题，却不能替某个具体服务证明它掌握了必要数据、知道谁控制另一套系统，或者有能力处理不一致。个案申请必须把“同一控制人”变成运营方、注册商和替代系统运营者之间可检验的承诺。

两种架构，各自要交代证据

在 SRS 模式下，如果两套名称的改变都经过注册局的共享注册系统，注册局可能可以协调发布，并保留对应关系。一个域名对象只关联一个登记人，状态相对容易辨认。但报告也提醒，共享 SRS 本身不足以证明两个名称始终由同一控制人掌握。注册局仍需要适当的数据，或可靠的技术与合同保证。

分布式方案可以让数据留在不同参与方手中，再通过 USoT 建立共同判断。它减少了把所有记录集中到注册局的需要，但也提出更尖锐的问题：某一边确认了转移、另一边尚未完成时，哪一边的状态有效？每个参与者如何收到变化？谁能在事务超时后决定继续、撤销或暂停？如果没有明确答案，“统一事实来源”只是架构名称，并没有提供可审计的事实。

报告中的注册人内部转移案例说明了观察权限为何重要。如果注册商只在自己的业务系统里更换注册人，注册局可能根本不会收到通知。此时，同一控制人的保证要依赖合同遵守，除非注册局拥有持续有效的身份关联或其他证据。如果 DNS 名称和替代名称属于两个不同对象，并可能分别关联不同控制人，报告认为由注册局提供一条命令、同时转移两个对象，是一种可能的保障方式。

暂停也不能和所有阻断动作混为一谈。TSG 认为集成名称的暂停要同时覆盖所有命名系统。若某个系统因外部原因停用名称，例如滥用问题或法院命令，报告提出注册局应在所有关联系统停用它。注册商发出的 clientHold 则不同：它可能只是暂时停止 DNS 解析，不应自动关闭替代名称。把这些原因压缩成一个“已暂停”标记，读者就无法判断适用的规则和后续影响。

评论意见要求状态可以被观察

Unregistry 在 ICANN 网站提交的意见支持报告的大方向，同时认为面向注册局的要求比用户端要求更完整。它建议公开集成状态，并为无法解决的同步故障规定安全处理方式。这是一家提交者的主张，不代表社区共识。

印度电子和信息技术部的意见要求在 RSEP 批准前把宽泛原则转成可衡量、可验证的条件，包括明确事务状态、限制未解决事务、制定失败保护和经测试的退出方案、防止到期后过早重新分配，并进行独立安全测试。这些是该部门提交的建议，并非已经生效的 ICANN 要求。

知识产权选区提醒，权利保护问题仍要由更广泛的政策讨论处理。技术安排可以证明两条记录是否协调，却不能决定谁应优先取得一个字符串、名称冲突如何救济，或受影响的用户可以向谁申诉。

因此，每个服务申请都应该能回答几个具体问题：哪个角色能授权续期、转移、暂停或移除？每个系统收到了什么确认？未完成的操作可以停留多久？怎样防止 DNS 名称已分配给新用户时，旧的替代名称仍可被访问？出现争议后，由谁更正记录并提供复核？

为每次状态转换留下凭据

有价值的并不是再复制一份名称清单，而是保存状态转换的凭据：发起变更的权限和角色、适用的规则版本、变更前后的目标状态、受影响的系统、事务标识、各方确认、时间或顺序信息、超时后的处理、通知和复核途径。公开页面只需告诉用户集成名称当前是有效、撤回、暂停还是待处理；运营审计则需要足够证据还原为什么发生了变化。

这是一项本文提出的服务设计建议，不是 TSG 已通过的要求。它回应的是责任分布问题：注册商了解客户关系，注册局控制 DNS 发布，替代系统运营者执行另一侧的记录变化；一旦两边分叉，实际后果却落到登记人和依赖该名称的用户身上。合同即使写明各方职责，如果事后无法看到证据，也很难追究谁延误了哪个步骤。

ICANN 的RSEP 政策及其实施说明已经要求申请人说明服务及其对外部用户的影响。下一步应把 TSG 的共通技术基线转成申请前能实测、上线后能复核的服务条件。“同名同控”只是起点。治理要求解释的是，这项承诺如何跨越不同系统的时间、权限和失败边界而继续成立。

来源