摘要

  • draft-skoglund-epp-registry-lock-00 提议让受保护域名的变更进入待审批状态，在规定时限内由一名或多名锁定联系人授权。
  • 政策可以写明所需批准数，最终轮询消息也能列出批准联系人 ID；但身份保证、挑战内容、信道绑定与审批者独立性没有被标准化。
  • 运营方需要另存“审批仪式记录”，把变更前后状态、独立控制域、挑战、答复、例外、时间与最终交易结果连成证据链。这是治理建议，不是 IETF 草案要求。

法定人数的安全感来自数字：两个似乎一定比一个稳妥。可如果两个地址由同一家邮件系统托管，两个手机号由同一管理员管理，账户又能通过同一个帮助台恢复，那么攻击者突破的是一个控制域，只是系统最后收到了两份答复。

注册局锁定本应在注册商账户之外增加一道机构边界。名称服务器被更改可能重定向流量，持有人或注册商被更改可能移动法律与操作控制。对于关键域名，这道外部边界的价值就在于单一凭据失陷不能直接完成变更。自动化若只保留票数、不保留独立性，便可能消解锁定服务最重要的理由。

第 00 版草案发布于 2026 年 6 月 30 日。渲染正文的页眉写着 Standards Track，但 Datatracker 将其列为个人 Internet-Draft，没有 RFC 流或拟定状态，并明确说明它在 IETF 标准流程中没有正式地位。因此，它不是 RFC，也不是 REGEXT 已形成的共识。

一条命令开启审批事件，而不是立即完成变更

草案指出，现有注册局锁定流程各不相同，且往往含有人工环节。新的域名映射扩展让赞助客户端通过 EPP 设置和管理锁定。

锁定生效后，域名必须带有 serverDeleteProhibited。变更等待授权时，必须带有 serverPendingUpdate。设置锁定或更新已锁定域名会返回 1001，表示命令已被接受，但仍有后续动作。时限内获批后，服务器通过 poll 消息报告成功；未获批则报告失败。

这改变了证据的时间结构。最初的 clTRID 与 svTRID 不再对应一次已经完成的状态跃迁，而对应一段审批过程的起点。轮询数据可指出域名、操作、先前的服务器交易标识，以及被计入的联系人 ID；RFC 5730 的外层队列还提供入队时间和新的交易标识。

这些字段可以把开始与结局连接起来，却无法说明中间究竟怎样验证了人和权限。

多行联系人记录不等于多条权力链

政策可包含时限和一个正整数批准数；第 00 版将字段拼作 quorom。服务器能够限制取值和联系人总数。这个数字至少让客户端与服务器明确需要多少份响应。

但它不说明联系人是否为不同自然人、不同雇主、不同设备或不同恢复渠道。三个联系人行可以指向共享邮箱；两家子公司的账号可以由同一个身份供应商控制；多个电话可以属于同一个企业移动账户。

“多个”是数据库属性，“独立”是架构属性。后者要求单次入侵、单个管理命令或一次身份恢复不能同时产生全部所需批准。协议可以不解决公司治理，但运营方不能在没有独立性规则与执行证据时，把 quorom=2 宣传为双人控制。

方法名称不是身份保证等级

每个锁定联系人具有 ID，并可选择审批方法。草案给出 email、text、letter、phone、token 五个常见字符串，也允许服务器接受其他值。

这些名称只描述传递类别。“邮件”可能是签名链接、普通回复或客服对话；“短信”不说明号码是否近期复核、是否可被重新分配；“token”可能是硬件认证器，也可能是可转发代码；电话与信件同样需要被记录的挑战和接收者。

草案没有规定挑战内容、与具体变更的绑定、防重放、渠道登记、身份核验或恢复流程。对于早期 EPP 映射，这种克制可以理解，各注册局也确有不同模式。但它限定了 approvedBy 的证明力：它只表示注册局按照自己的流程记下了批准，不能证明所有流程提供相同安全强度。

冻结联系人对象，并未冻结整个授权结构

与已锁定域名关联的联系人对象不得被更新或删除。这堵住了直观攻击：先把联系电话或邮箱换成攻击者控制的值，再通过新端点批准。

可是，注册局锁定自身的更新语法仍能增加、移除联系人，并修改时限或批准数。问题因此变成递归的：谁有权批准“更换有权批准的人”？

删除唯一处于外部身份系统的联系人，不等于普通名称服务器更新。降低票数或缩短时限，会在下一次业务变更前削弱制度。授权集合的变更应由请求开始时的旧政策和旧联系人集合审查，并永久保留变更前后状态。新规则不能倒过来授权自己的诞生。

例外才划出锁定的真实边界

锁定并不阻止所有动作。续费仍可进行。注册局还可以允许自动化 DNSSEC 供应绕过审批，草案以 CDSS/CSYNC 扫描器为例。解除锁定则是规范范围之外的人工运行程序。

这些边界有合理性：阻断续费可能把安全控制变成到期风险，DNSSEC 自动化也能避免密钥切换失败，而把解除锁定保留为更强的人工仪式能够保护紧急通道。

但“已锁定”因此只是带有具名开口的边界，不是绝对静止。自动例外应记录扫描器身份、观察到的记录、允许绕过的政策，以及委派变更前后状态。EPP 外的人工解锁也应生成可与协议历史关联的仪式标识。否则，权力最大的路径反而最难审计。

现实服务说明同一个名称可以有不同仪式

IANA EPP 扩展注册表已经列有瑞典互联网基金会的 Registry Lock Extension，状态为活跃、文件类别为 Other，适用于 .se 与 .nu。它是既有运营方扩展，不等于新的个人草案已经获批。

Internetstiftelsen 的公开说明把持有人核验方式交给各注册商，由注册商解锁、执行操作，再立即或在注册商设定期限后重新锁定。DENIC 对 .de 描述的是另一套仪式：指定锁定联系人，向已登记手机号发送批准令牌并同时发邮件；七个日历日未确认则拒绝，DENIC 还会另行检查设置、更改、移除锁定以及域名数据变更请求。

这些说明都不能证明第 00 版已部署。它们证明的是，同一个“注册局锁定”名称可以包含不同登记、验证、超时、解锁与恢复安排。未来的统一 EPP 语法不会让差异消失，只会使公开差异更必要。

记录赋予法定人数意义的审批仪式

我建议每次待处理的锁定变更都产生审批仪式记录。这是 Daniel Kade 的编辑治理建议。

记录首先固定域名、已认证客户端、会话、clTRID、svTRID、请求时间、操作类型，以及变更前与拟变更后的规范化状态。旧政策版本、时限、所需票数和联系人集合必须冻结，后来的更新不能覆盖起点。

对每一名审批者，记录其代表的授权主体、登记时间、方法，以及判断独立性所需的控制域：雇主、身份供应商、邮箱租户、设备管理、电话账户、令牌发行者与恢复服务台。敏感详情可以用受控引用或稳定的匿名域表示，而不必公开。

每次挑战都以随机数或摘要绑定到确切变更、传递端点、发出与到期时间、响应时刻、验证结果和防重放状态。最终决定说明采用哪条独立性规则、哪些批准被计入或排除、是否调用例外或人工越权，以及谁批准了偏离。

流程结束时，把原始待处理交易、轮询结果、实际应用状态和通知绑定起来。DNSSEC 自动绕过必须留下自动化身份与政策；EPP 外解锁必须把外部仪式 ID 纳入同一时间线。

法定人数回答“服务器数到了几票”。审批仪式记录回答更重要的问题：这些票是否代表锁定服务承诺的彼此独立的权力。

来源