摘要

  • RFC 5731 对 clientTransferProhibited 与 serverTransferProhibited 的规定既强又窄：域名对象的转移请求必须被拒绝。
  • 前缀能够指出状态由注册商一侧还是注册局一侧控制，却不包含政策原因、人的授权、复核期限；连用于说明理由的文字也是可选项。
  • 可靠的转移决定需要把带时间的“状态凭据”与独立的“决定凭据”关联起来，并把更新、删除、续费、DNS 与账户控制分别核验。

先相信它能阻断什么

理解域名锁，第一步不是削弱它。RFC 5731 使用的是“必须拒绝”：只要 clientTransferProhibited 或 serverTransferProhibited 存在，转移域名对象的请求就不能被服务器接受。对监控系统而言，这是一条有明确对象、动作和当前时点的事实。

误差出现在下一步。产品把这条事实改写成“持有人已保护”“发生安全事件”“注册局锁定”，甚至笼统的“安全”。状态代码没有说这些。它规定服务器如何处理一类命令，没有交代为什么形成这个决定。

RFC 5731 允许状态附带一段供人阅读的理由说明，但这里是“可以”，不是“必须”。合规的域名对象完全可能只有状态，没有案件编号、持有人指示、到期日或最近复核记录。没有说明文字不代表协议失效，只意味着原因必须从别的记录取得。

恰恰因为语义狭窄，这个状态才容易互操作。若把同意、身份、政策和事件史全塞进一个代码，它反而会失去可比较性。协议负责清楚地阻断命令，制度负责说明为何这样做。

client 与 server 指向不同的门

两个禁止转移状态并非同义词。RFC 5731 规定，以 client 开头的状态由赞助客户端添加或移除；在注册局—注册商关系中，这通常是注册商。以 server 开头的状态由服务器控制，通常对应注册局。客户端不能改动服务器设置的状态；服务器则可依本地政策改变或覆盖客户端设置的状态。

这套命名定位了控制面，却没有点名某次操作背后的自然人或政策。注册商可能在新注册时默认加锁，也可能响应持有人请求、执行限时政策锁，或处理账户异常。注册局一侧的禁止状态可能与争议、赎回期、持有人购买的服务或其他本地规则有关。同一个公开代码可以是多种决定的投影。

ICANN 面向注册人的 EPP 指南给出了实用分工：客户端状态由注册商设置，服务器状态由注册局设置。解除前者通常向注册商提出；解除后者往往还需要注册商与注册局协作，耗时可能更长。这能告诉持有人从哪里开始，却不能替他推断理由。

原因属于政策层

在其适用范围内，ICANN 现行《转移政策》补上了 RFC 5731 有意不承载的那一层。它区分谁有权批准转移、接收方注册商怎样提交请求、原注册商何时可以拒绝，以及在何种情况下必须说明拒绝理由。

这些条件不能被压缩成一个安全故事。欺诈证据与持有人身份存在合理争议不是一回事；规定范围内的欠费与持有人明确反对也不是一回事。法院或争议程序、新注册或刚转移后的时限、变更注册人后的六十日锁，各自拥有不同的权限与时钟。把所有禁止状态解释成“疑似劫持”，是在虚构证据；一律解释成“持有人主动要求”同样错误。

政策还限制了“注册商锁定”这项裸事实的效力。如果持有人在发起转移前没有得到合理的解锁机会与能力，就不能只因处于注册商锁定状态而拒绝转移。若持有人明确选择普遍反对转移，知情选择与可达的解除路径也是决定的一部分。EPP 状态执行当前结果，政策记录才回答这个结果是否有依据、如何结束。

因此至少需要两张凭据。状态凭据记录：哪个域名、哪个精确状态、从何处观测、何时观测、后来被什么状态取代。决定凭据记录：谁提出或施加限制、适用哪条规则、使用何种授权、何时生效、何时到期或复核、怎样通知、由谁解除。

三只时钟会把一枚图标撕开

转移限制至少有三只时钟。服务器时钟标记状态何时进入权威 EPP 数据；政策时钟标记理由何时成立、何时应当复核；观测时钟则标记 RDAP、Whois、注册商门户或监控供应商何时看到并呈现它。

三者并不总是一致。公开响应可能被缓存，门户可能在后台操作后仍保留友好标签，政策案件可能已经到期而技术状态尚未移除，也可能服务器已解锁而下游面板尚未刷新。截图只能证明某个界面在某个时点显示过什么，不能自动证明当前权威状态、设置者或决定原因。

RFC 5731 还给出一项很实用的一致性检查：pendingTransfer 不得与任一禁止转移状态同时存在。前者表示转移动作已经处理但尚未完成；后者要求拒绝转移请求。若一份数据同时展示两者，首先应查时间偏差、缓存年龄、多来源拼接或展示错误。矛盾说明证据链需要重建，却不能直接证明欺诈或注册局不合规。

“锁定”没有覆盖所有动词

日常语言里的“锁”像是把一切封住。EPP 分别定义转移、更新、删除、续费的客户端与服务器禁止状态，还用 hold 状态影响 DNS 委派发布，正是因为这些动词由不同控制面承担。

域名可以禁止转移，却仍可能遭遇注册商账户被接管、联系人被修改，或客户端锁被有权限者移除。反过来，一个管理严格的商业 registry-lock 服务也可能加入电话回拨、独立凭据、双人批准与强制等待，远比公开 EPP 代码表达得更多。对这些额外控制，应依据真实合同和运行证据给予信用，不能从状态名称臆测。

ICANN 的域名安全提示同样把层次分开：转移锁是有用的一层，但不是万无一失；账户信息保护与多步骤认证需要另外落实。完整的运营记录还应分别保存账户认证、权限变更、authInfo 处理、更新与删除限制、DNS 委派、续费和恢复联系人。它们能够相互增强，却不能互相冒领证明。

人名也有证据边界

RFC 5730 与 RFC 5731 都把 Scott Hollenbeck 列为作者。IETF Datatracker 的当前资料称，他自 1990 年代中期起积极参与 IETF，主持过多个工作组，并在 2004 至 2006 年担任应用领域主任；页面目前列出 39 份 RFC。

这足以证明一项深厚的标准贡献，却不意味着 Hollenbeck 运营任何注册局、制定某个具体转移案件的理由，或控制某人的域名。他的名字属于规范的来源链，正如注册商或注册局属于某次状态变更的来源链。准确归因不会减损贡献，只会防止贡献被误写成不存在的操作权力。

让命令结果和决定理由并排存在

最低限度的证据包从域名、精确状态、权威或公开来源、观测时间及下一状态开始；条件允许时，再加入 EPP 查询或事务标识。它随后关联但不吞并外部决定：政策或合同版本、请求方、负责的注册商或注册局角色、授权凭据、生效时间、到期或复核触发器、通知、解除路径与最终结果。

一旦实际发起转移，还需要第三张凭据：请求时间、适用的授权处理、服务器返回、任何 pending 状态、依适用政策传达的拒绝理由，以及后续解决结果。秘密和不必要的个人信息不应写入公开记录，但用于解释重大拒绝决定的来源不能丢失。

最有力的反方事实必须保留：禁止转移是真控制。在合规服务器状态中，它确实阻止转移请求。默认注册商锁与操作严谨的注册局锁服务都能显著增加劫持难度。错误不在于相信协议，而在于要求协议替它字段之外的决定作证。

Hollenbeck 的映射给了运营一个完整的短句：拒绝这类命令。实施限制的机构必须完成剩余句子：谁决定、依据什么、维持多久、谁能撤销。锁可以停止转移，只有可归属的证据能够解释这把锁。

来源