摘要

  • RFC 10026 把 clientUpdateProhibited 与 serverUpdateProhibited 视为约束特定参与方和命令路径的控制，而不是“所有 DS 数据都不可移动”的证明。
  • 密钥轮换或算法迁移期间，继续执行经过认证、通过验收检查的 DS 维护，反而可能是维持 DNSSEC 连续性的必要动作；锁状态、子区请求、父区决定和最终发布需要分别举证。
  • “已锁定”徽标既不能自动授权一次变更，也不能证明没有变更。可靠的结论来自按参与方组织的决策记录、通知链和独立恢复通道。

一张截图很容易制造确定感：域名旁边有绿色锁标，账户似乎处于最安全的状态。可是在事故复盘里，截图通常只能回答一个很窄的问题——某个时刻，某个界面向某位用户展示了什么。它回答不了 EPP 服务器当时保存了什么状态，也回答不了后来是谁通过哪条路径改变了父区的 DS 集合。

2026 年 7 月发布的 RFC 10026 是 IETF 最佳当前实践 BCP 246，作者记录为 Steve Sheng 与 Peter Thomassen。文档讨论 DNSSEC 委派签名者记录的自动维护，尤其把一个常被产品界面掩盖的问题说得很直接：更新锁有控制边界。普通语言里的“锁住”不能代替协议里的参与方、权限与命令语义。

锁的前缀已经说明了权力来自哪里

RFC 5731 为 EPP 域名状态规定了一套清楚的命名方式。以 client 开头的状态由赞助客户端设置和移除，通常对应注册商；以 server 开头的状态由服务器控制，通常对应注册局。clientUpdateProhibited 与 serverUpdateProhibited 都要求服务器拒绝更新对象的请求，移除该状态的请求除外。

两个名字看起来对称，权力关系却并不对称。客户端不能改动服务器设置的状态；服务器则可以按照本地政策改变或覆盖客户端状态。于是，“禁止更新”从来不是一条脱离执行者的抽象命令，它是在特定参与方之间生效的规则。

当 clientUpdateProhibited 存在时，主要被挡住的是作为赞助客户端提交的普通注册商更新命令。设置它的注册商能够移除它，注册局也不会因为注册商设置了一个客户端状态就失去自身行动能力。它可以有效降低客户门户误操作或低权限账户滥用的风险，却不能证明注册商和注册局这两个高权限参与方在技术上无权行动。

serverUpdateProhibited 对注册商更强，因为注册商的更新请求应当被拒绝。但它同样没有宣称服务器运营方已从系统中删除自己的本地执行能力。若注册局按照已公开的政策在服务器侧完成一项动作，状态本身并不能判定那项动作是否越权。

所以，锁的第一张有效收据至少包含四项：状态由谁设置、何时存在、拒绝哪类命令、哪些参与方仍能通过其他被授权路径行动。“锁还在”只是其中一格，不是结论。

DNSSEC 的安全状态不能永远静止

把域名配置好、加锁、长期不动，在某些注册操作中可能是一种合理习惯。DNSSEC 的信任链却含有必须随时间维护的状态。签名密钥会轮换，算法会退役，DNS 服务商会改变，父区中的 DS 集合必须在适当时间跟上子区，否则旧值虽然原封不动，验证功能却可能失效。

这正是“全面冻结”会产生反直觉风险的地方。子区已经准备好新密钥，而父区因为把普通更新锁理解成永久禁令，迟迟不能调整 DS；等旧密钥停用后，验证器看到的就可能是一条指向过期信任材料的链。锁保住了旧数据，却破坏了旧数据原本要保护的可验证性。

RFC 7344 允许子区通过 CDS 或 CDNSKEY 表达父区 DS 维护请求。RFC 9615 又为尚未建立 DS 信任路径的委派提供经过认证的自动引导方式。这些信号不是匿名意见，也不是看到就执行的指令。它们是需要经过来源认证、一致性判断与安全投影的协议证据。

RFC 10026 因而建议：不能仅仅因为存在注册商更新锁，例如 clientUpdateProhibited，就暂停自动 DS 维护；当注册局亲自执行自动化时，也不能仅凭注册局更新锁，例如 serverUpdateProhibited，就暂停它。这个原则既适用于首次发布 DS，也适用于之后的轮换。默认加锁的域名不应为了发布一组经过认证的初始 DS，机械地先解锁再重新上锁。

这不是让系统“忽略锁”。更准确的理解是：普通 EPP 更新锁与一条经过认证、且不属于其禁止对象的 DS 维护路径彼此正交。某些专有的带外注册局锁可能覆盖更广，甚至需要多名审批者或线下仪式才能解除；那是另一份产品和权限合同，必须逐项说明，不能借用一个熟悉的“锁”字就假定范围相同。

保留路径，不等于接受所有请求

维护通道没有被锁死，不代表任何 CDS 或 CDNSKEY 都能进入父区。RFC 10026 把验收关卡放在发布之前，首先要求父区代理确认子区意图明确。

如果同时存在 CDS 与 CDNSKEY，它们应当指向相同密钥。相关信号还应在委派列出的全部权威名称服务器上呈现可信的一致状态。随后，系统需要计算拟议 DS 集合带来的结果，确认至少保留一条有效的 DNSSEC 验证路径。意图不一致，或者预期结果会破坏持续验证，都应取消更新。

因此，一次变更至少涉及五个互不替代的判断：锁究竟约束什么；子区是否发布了请求；请求是否可认证且在权威服务器间一致；拟议父区状态是否继续可验证；父区是否真正发布了验收结果。

这些事实不能互相“传递证明”。锁存在，不证明 CDS 真实；CDS 真实，不证明所有权威服务器一致；一致，不证明变更后仍可验证；验收通过，不证明父区已发布；父区已发布，也不证明所有递归解析器已经越过旧 DS 的缓存期。

这种拆分还把本文与针对同一 RFC 的另一种问题区分开来。全权威服务器检查关注子区是否表达了一项一致请求；锁范围关注注册状态能限制哪个管理参与方与命令路径。前一张收据不能顶替后一张。

注册商设置的锁，防不了注册商自己

RFC 10026 的威胁模型并不讨好市场宣传。客户端更新锁无法成为抵御恶意注册商或注册局的充分措施，因为注册商可以移除自己设置的客户端状态，服务器也能依据本地政策覆盖它。若攻击者已经控制其中一个高权限主体，几分钟前出现过锁标，并不会自动阻止后续行动。

这不等于更新锁没有价值。它可以在存续期间拒绝普通更新命令，降低误操作、被盗客户账户和自动化脚本错误的风险。问题只在于不能把这种价值扩张成“所有机构都无法行动”的保证。

事故调查尤其需要抵抗这种扩张。门户截图是展示层证据；服务器状态读回是控制面证据；发起参与方、授权方式、验收日志和父区差异才是变更链证据。如果只有第一项，调查者既不能宣布变更安全，也不能仅凭界面与结果不一致就宣布被入侵。

更强的带外锁当然可能改变结论。例如，注册局产品可以要求电话核验、双人审批、延迟期或单独凭据，才允许解除或绕过某些限制。但评估对象应该是其真实的解除权、紧急例外与审计记录，而不是产品名称。clientUpdateProhibited、serverUpdateProhibited、转移锁、删除锁以及专有注册局锁不能混为一个控制。

正确的变更也需要目击者

在注册人—注册商—注册局的关系中，注册局侧自动化可以不经过注册商的普通更新命令而合法改变 DS。这解决了维护连续性，却容易造成信息不对称：注册商不知道发生了什么，注册人只看到锁仍然亮着。

RFC 10026 要求用单独的报告机制处理这个问题。注册局执行 DS 自动化时，应通过 RFC 8590 定义的 EPP Change Poll 扩展或类似渠道通知注册商；显著更新与停用还应通知有关联系人。注册人或其指定方应当能在管理界面查看当前实际生效的 DS 配置。

父区代理则需要保留结构化决策记录，包括时间、触发它的 CDS/CDNSKEY 数据、采用的通知渠道、查询过的权威名称服务器、各项验证结果、最终决定，以及实际应用的 DS 集合或取消原因。

有了这份台账，“锁着的域名正确地发生了变化”就不再是一句悖论。记录可以证明：锁在它本来要保护的路径上持续有效；另一项经过认证的信号进入了不同路径；验收检查通过；有权处理父区的一方完成发布；相关参与方收到通知；公开可见的父区状态与决定一致。

如果链条中缺一环，结论必须缩窄。没有通知首先证明报告失败，不会自动把 DS 变成未授权；父区 DS 改变只证明发布发生，不证明子区信号真实；界面仍显示锁定，只证明展示状态，不证明服务器决策。

恢复不能依赖已经丢失的那把密钥

自动化也不能成为唯一入口。子区可能丢失为轮换请求提供认证的签名密钥；多运营商环境中的某一家可能拒绝合作；DNS 服务商也可能根本不支持 CDS/CDNSKEY。

RFC 10026 因此要求注册局与注册商提供另一条 DS 维护通道。它可以是人工流程，但必须能在带内证据无法产生时恢复控制。使用当前密钥认证的协议，在当前密钥已经毁损后无法凭空证明过渡；不断重试同一机制不会补出缺失的密码学收据。

人工恢复同样应该可审计：谁代表组织提出请求，做了哪些带外核验，希望形成什么 DS 状态，自动化是否暂时停用，何时恢复，父区最后读回了什么。否则，“人工例外”会变成另一把边界不明的锁。

Sheng 的署名证明贡献，不转移运营权力

RFC Editor 记录 Steve Sheng 与 Peter Thomassen 为 RFC 10026 的两位作者。IETF Datatracker 还列出 Sheng 参与的 RFC 7485 与 RFC 7710。ICANN 官方会议档案显示，他在 2022 年以政策发展支持高级总监身份主持相关会议；其当前公开简介称，他于 2024 年结束在 ICANN 长达十五年的技术政策研究工作，并拥有卡内基梅隆大学工程与公共政策博士学位。

这些材料能定位一种跨越协议与机构运作的公开贡献，却不能把任何注册局、注册商、父区或部署的控制权归给 Sheng。IETF 共识文档不是个人对域名持有人的命令，作者身份也不保证所有运营者已经实施其建议。

这里有一个与锁相似的边界：署名准确指出贡献者，却不因此授予运营权；状态准确指出一项禁止，却不因此束缚系统里的所有参与方。尊重人物的最好方式，不是夸大个人权力，而是把他的可核验贡献放回集体标准与实际部署之间。

最终证据是一份按参与方组织的决策收据

一次可复盘的 DS 变更，应从公开和服务器侧锁状态、设置者与时间开始，接着记录提交者、命令或自动化路径、CDS/CDNSKEY 原始材料、认证结果、全部权威服务器一致性、持续验证投影、本地验收政策与决定。

随后还要补上父区发布时间、最终 DS 集合、相关 TTL、面向注册商与注册人的通知、解析器可见验证，以及独立恢复入口。秘密和无关个人数据不应进入台账；解释权限和结果所需的证据必须保留。

这是一种“运行系统优先”的控制观：规格提供共同最低要求——普通注册锁不能意外摧毁经过认证的 DNSSEC 连续性，自动化也不能消灭恢复通道。运营者可以采用更强的锁、更多检查和不同通知政策，但每项选择都要说明约束哪条路径。

比“锁定就是安全”更持久的规则是：锁只在其公开的参与方与命令边界内构成证据。边界之外，每一项安全主张都需要自己的收据。

来源