摘要

  • 2013 年《注册商认证协议》、现行《注册数据政策》和 2025 年托管规范逐项限定注册商必须托管的数据。登录凭据、支付授权、客服工单、托管内容和邮箱不在这一核心数据包内。
  • 注册商负责制作数据，托管代理负责验证和保管，ICANN 在约定条件下触发释放并只获得过渡用途许可；注册局和一个已经具备运营能力的接收注册商仍须分别执行迁移。
  • 所有注册商每周提交完整数据；每个 ICANN 财政季度达到 100,000 个 registration-years 的注册商还须每日提交差异数据。新鲜且有效的文件仍然不是客户门户。
  • 2024 年一次有选择条件的审计中，进入最终报告的 58 家注册商里有 5 家没有把部分隐私/代理服务的底层客户资料正确放入托管。这个样本不能外推为全行业比率。
  • 问责不应止于“文件已收到”，而应测试签名释放、解密、导入、与注册局状态核对、客户认证和可用账户恢复的完整链条。

字段表决定了制度究竟保护什么

ICANN 的强制力来自一份可以指出条款的合同，而不是抽象的 stewardship。在 2013 年《注册商认证协议》第 3.6 节，获认证注册商同意按照 ICANN 规定的时间、条件和格式，提交特定注册数据的电子副本。

现行 Registrar Data Escrow Program 页面要求注册商和托管代理执行自 2025 年 8 月 21 日生效的 2025 版规范。注册商可以免费使用 ICANN 指定的托管代理，也可以自费选择获 ICANN 批准的代理。选择供应商不会改变数据必须通过的规则。

2025 年规范先规定频率。所有注册商每周提交一次完整文件。一个注册商在 ICANN 某个财政季度达到或超过 100,000 个 registration-years，就要在完整提交日之外每天提交差异文件。只做周度提交的数据不得超过六天；日度提交不得超过二十三小时。

托管代理不是把文件原样放进硬盘。它检查 SHA-256、数字签名、加密、UTF-8 编码、文件命名、CSV 结构和必填值。任意一条 Escrow Record 出错，整个提交都被视为失败。代理须在二十四小时内向 ICANN 报告缺失、有效或失败的提交，并可人工审查以帮助修复验证问题。

这些控制解决了一个真实风险：注册商失去合作能力时，外界不必面对一个只能由原厂软件读取的数据库备份，也不必相信从未测试过的“我们有副本”。格式、频率、校验和第三方保管使记录具有可迁移性。

但可迁移的对象有严格边界。现行《注册数据政策》第 8 节要求注册商托管域名、注册商注册到期日、注册商 IANA ID，以及注册人的姓名、街道、城市、州/省（适用时）、邮编（适用时）、国家、电话和电邮。注册人组织如果被收集或生成，就必须提交；经销商、电话分机、传真和部分技术联系人字段如已存在，可以提交。

注册商或其关联方提供 privacy/proxy 服务时，规范另外要求托管底层客户的姓名、地址、电邮和电话。否则，出现在公开层的代理身份可能成为恢复时唯一可见的人。

随后规范明确说，不应加入它所描述范围以外的额外数据。这意味着，注册商托管包不要求账户密码、多因素认证密钥、会话令牌、支付授权、预付余额、客服工单、网站文件或邮箱内容。

现行政策也取消了《注册商认证协议》和注册局协议中有关行政联系人、账单联系人的处理要求，包括收集、保留、传输、公开和托管。账单联系人并不等于完整支付账本；这里应得出的结论更窄：当前托管包不是注册商的财务系统。

另一个容易混淆的边界是注册局托管。域名服务器、DNSSEC 元素和域名服务器 IP 地址出现在政策对 registry operator 的托管要求中，不在 registrar 的第 8.1 至 8.3 节字段表里。注册局和注册商的托管数据可能在过渡时共同发挥作用，但不能把一方拥有的字段自动算到另一方头上。

保管者、释放者和运营者不是同一个角色

“托管”很容易让人想象成：域名持有人只要证明身份，就能直接向第三方领取完整账户。合同没有授予这样的直接提款权。

在释放之前，托管数据只能用于核验完整性、一致性和正确格式。《注册商认证协议》把未续约到期或协议终止列为释放条件。2025 年规范要求，托管代理在收到符合要求、由 ICANN 以规定方式电子签名的书面通知后，于二十四小时内向 ICANN 释放记录；适用法律要求额外通知时另行处理。ICANN、注册商和代理也可以共同同意把数据释放给指定一方。

数据释放后，ICANN 或其受让方取得为提供注册商服务所需的非排他、不可撤销、免版税许可，但用途只限于过渡。这是一个使用权桥梁，不是域名所有权转让，不是收购原注册商，也不自动裁决两个申请人之间的控制争议。

托管代理也不会因此变成注册商。它的权力是接收、验证、安全保管并按约释放。域名在注册局系统中的 sponsorship 变更仍需注册局执行；客户账户、续费和更新仍需一个获认证并在相应 TLD 上运营的注册商处理。

ICANN 的 De-Accredited Registrar Transition Procedure在 2008 年通过，文中的历史数量不能作为今天的行业规模。然而它对权力链的划分仍然有价值。ICANN 先评估注册数据是否可得和可靠，并与注册局协调避免域名因为失去认证的注册商作为或不作为而被删除。之后需要一个有能力的接收注册商。

接收方必须已经获认证并在受影响 TLD 上投入运营。程序关注它能否迅速导入记录、管理相似规模的客户组合、配备客服、处理控制争议并向 ICANN 报告。如果数据不可用或不可靠，文件列出的替代路径包括从其他来源收集资料、诉讼或仲裁、与原注册商谈判、允许其有限运营，甚至让域名按到期日失效等困难选择。

一份2023 年接管申请问卷把“有数据”和“能运营”拆得更清楚。ICANN 询问候选注册商是否提供电话、邮件/工单和实时支持；在数据可用后需要多少天才能让注册局启动批量转移；首个续费期如何定价；是否有足够经验并保持合规。问卷还说明，选中的接收方可能由托管代理向其移交托管数据，并必须保护这些资料。

如果一个有效文件本身就是业务连续性，上述客服、时间和定价问题就没有必要。实际情况正相反：托管数据是输入，运营组织是另一项必须另行选定的能力。

失效企业内部仍然可能锁住什么

第一项是认证状态。接收注册商可以获得注册人的电邮和电话，却不能把这些字段直接当作当前登录会话。资料可能过时，原注册商也可能因为安全事件而失效，甚至有人正在争议控制权。稳健的接管需要新的账户恢复流程、证据审查和新凭据，而不是复制旧密码。

第二项是商业状态。托管数据可以显示注册到期日，却不一定能回答客户是否已预付数年、是否购买了组合服务、是否存在退款或拒付。2023 年问卷专门询问接收方续费价格，说明数据释放并没有决定新的商业条件。

第三项是经销体系。一个 reseller 字段可能指出销售渠道，但它不是经销商权限树、子账户清单、余额表、白标门户和客服路由。知道关系名称并不等于恢复关系的实际运作。

第四项是依赖服务。许多客户从同一家公司购买域名注册、权威 DNS、邮件、证书和网站托管。注册商 escrow 主要保护第一个对象。注册局能够保存 sponsorship 或委派资料，不代表被指定的域名服务器仍在回答；新注册商能够续费，也不代表它持有原网站或邮箱内容。

因此，任何 stability 主张都必须说明稳定的究竟是什么。注册记录稳定、DNS 解析稳定、邮箱稳定和客户企业运营稳定，是四个由不同系统、合同和人员控制的结果。

成本也沿着这条链分配。注册商承担制作与修复提交的成本；选择批准代理时还承担代理费用。ICANN 为指定代理安排和协调工作付费。代理承担加密保管和验证。接收注册商投入导入、核对和客服资源。注册人承担等待、身份复核、迁移依赖服务以及无法立即访问账户的损失。

受益者首先是注册人：原注册商即使不合作，也不再天然掌握唯一可读记录。接收注册商获得标准化起点，注册局获得更清晰的迁移输入，整个域名系统减少对一个失败中介的依赖。

最有力的制度辩护也来自有限范围。把所有密码、支付工具、通信和内容集中给托管代理，会制造巨大的安全目标和跨境数据责任；文件更难验证，也更难合法交给接收方。一个最小核心之所以有用，正是因为它没有假装复制整家公司。

这项辩护并不免除结果责任。它只是把正确问题从“为什么 escrow 不保存所有东西”改成“这份最小数据包是否真的能在危机中被合法释放并由接收方使用”。

审计百分比和投诉数量不能替代恢复率

ICANN 的2024 年 1 月至 7 月注册商审计按报告披露的历史和集团选择规则抽取 62 家注册商。四家因不同原因没有完成审计阶段，最终报告覆盖 58 家。其中 5 家存在一项具体缺陷：privacy/proxy 服务底层客户资料没有进入数据托管。

这个结果证明审计确实检查了具体字段义务。它不是普查。不能把 5/58 直接改写成全球注册商的当前违规率。

2025 年 3 月至 2026 年 2 月合规仪表板显示，在针对注册商的前五类投诉表中，Registrar Data Escrow 占收到投诉的 10%。这里统计的是收到的提交，不是认定的违约。

2025 年 4 月提供了最重要的解释边界。当月 ICANN 收到 645 件数据托管投诉，比此前十二个月平均数高一倍以上；ICANN 同时说，大多数投诉无效，因为相关注册商已经完成托管提交，因此无需联系合同方就结案。

投诉量可能反映自动监测、重复报告或审查工作负荷。有效提交数量反映文件合规。两者都不直接告诉注册人：如果今天释放数据，接收方多久能让其重新获得可用账户。

2013 年 Xin Net 违约通知记录了当时多次缺失或无效的周度提交，并显示 ICANN 使用了合同升级机制。它是一个有文件支持的历史执法案例，不是今天故障发生率的证据。

公开资料最强的部分仍在链条入口：是否应提交、是否收到、是否通过验证。链条出口——解密、导入、注册局核对、客户认证和服务恢复——缺少同样清晰的当代分布数据。