摘要

  • 客户 X 可以控制一个域名及其下属主机，但客户 Y 的域名也可能把该主机当作权威名称服务器；X 无权修改 Y 的域名。
  • 把主机改名到“应该不存在”的外部域名，或指向公共递归服务，会把风险转嫁给未来注册人、解析器和其他客户；RFC 9874 明令不得使用这些做法。
  • 跨客户删除凭证应分别证明授权、依赖范围、DNS 前后状态、通知、赎回期限、恢复能力以及异步清除的真正完成。

设想客户 X 要删除 domain1.example。ns1.domain1.example 是它控制的下属主机。客户 Y 的 domain2.example 却把这个主机列为名称服务器。X 可以整理自己的对象，不能替 Y 修改委派，也未必能看到那条关联；注册局服务器则掌握完整关系。

这时，一条成功响应只能证明服务器按当时政策接受了 X 的命令。它不能同时证明 Y 的 DNS 仍可解析、Y 已收到通知、删除仍能回滚，或所有后台任务已经结束。把这些结论压成一个绿色状态，是审计记录最先发生的失真。

“不应删除”保护的不是表面秩序

RFC 5731 建议：域名仍有关联下属主机时，不应删除域名。RFC 5732 建议：主机仍与其他对象关联时，不应删除主机。这两条提醒同时保护三种一致性。

第一种是 DNS 一致性。删除上级域名可能让下属主机无法解析；删除主机则可能让依赖它的域名失去权威服务。第二种是客户端与服务器的一致性：如果服务器暗中删除或拆开关系，客户端保留的注册状态会落后。第三种是注册局内部的关系完整性，域名和主机可能在数据库中存在强关联。

跨客户场景让问题更尖锐。X 是命令主体，Y 才是部分后果的承担者。阻止所有删除会把 X 永久锁住；忽略依赖则把清理成本和故障风险推给 Y。治理的任务不是假装矛盾不存在，而是让取舍、通知和恢复都有可核验的证据。

“牺牲主机”并不是无人负责的垃圾桶

一种办法是把下属主机改名，使它成为原域名之外的外部主机，从而解除删除条件。这个新名字常被称作牺牲主机。改名没有消灭依赖，只是更换了依赖的保管人。

如果新父域名只是被假定为不存在，第三方日后可以注册它、创建对应主机，并接管仍引用该名称的 DNS 查询。RFC 9874 说，这种已经观察到的做法 MUST NOT 使用。把 glue 指到知名公共递归 DNS 也不安全：递归服务不是这些域名的权威服务器，查询可能返回 SERVFAIL，并触发大量重复查询；这项做法同样被禁止。

允许的客户端自管方案更严格。客户必须长期持有牺牲主机的父域名，并在所列地址上运行权威 DNS。它阻止陌生人取得控制，却把一次删除变成持续的托管义务。域名续费、锁定、名称服务器运行、组织合并后的责任移交，都属于删除之后仍存在的控制面。

因此，“改名成功”不是结束。凭证必须写明新权威是谁、要维护多久、失效时由谁处理。

赎回期把影响与不可逆性分开

另一条路径是允许显式删除，同时由服务器处理跨对象关联。服务器可以在执行前告诉 X 会影响多少其他对象；可以通过 EPP Change Poll 等方式通知受影响客户；还可以借助 RFC 3915 的赎回机制，保留恢复能力。

在这种模式中，域名、下属主机以及与其他域名的关联可停留在 pendingDelete。DNS 中可能先看见删除效果，但关系图尚未永久销毁。如果命令是误操作、恶意行为，或实际影响超出评估，可以在赎回期内执行恢复。期限结束后，才清除域名、主机和关联。

这条路径也不是瞬间完成。RFC 9874 指出，关联域名数量没有固定上限。停用、重新启用和清除可能被拆成多个异步事务。命令接受时间、区域发布完成时间、通知送达时间和最终清除时间，必须作为四个事实保存。

凭证必须跨过同一条权限边界

有效的凭证首先记录请求本身：认证客户、事务标识、目标对象、服务器政策、请求时间，以及允许产生跨客户影响的权限依据。随后冻结依赖快照：何时、用什么方法枚举，下属主机有哪些，受影响域名和客户数量是多少，请求人因隐私或竞争限制看不到什么。

第二组证据是 DNS 前后状态：权威主机名和地址、预期区域变化、实际观测、DNSSEC 与 DS 条件，以及采用的是自管牺牲服务、特殊用途名称还是可恢复删除。第三组是决策证据：向操作员展示了什么警告，服务器提供了什么细节，是否需要人工批准，最终选择为何成立。

第四组连接其他客户：通知是否入队、是否送达、是否确认；无须公开注册人私密信息，但不能把“隐私”当成未计数、未通知的借口。第五组固定赎回期限、恢复权限、保留关联与回滚测试。最后一组关闭异步尾部：任务标识、部分失败、重试、最终清除、清除后的 DNS 观察，以及谁接受了完成状态。

这份凭证不是 RFC 9874 定义的新字段，也不是 IETF 合规证书。它是 Daniel Kade 针对该治理断点提出的运营记录。

DNSSEC 仍然依赖证据的一致性

DNSSEC 和多个名称服务器能减少某些风险，却不能自动修复错误托管。RFC 9874 描述了一种边界情形：攻击者若控制一个名称服务器，而自动 DS 维护没有核对所有服务器的 CDS/CDNSKEY 一致性，攻击者可能影响 DS；结合 CSYNC，合法名称服务器甚至可能被移除。

问题不在于 DNSSEC 本身，而在于自动化采信了哪一组证据。删除凭证应写明 DS 自动化是否开启、查询了哪些服务器、答案是否一致、哪个主体授权了变更。“已启用 DNSSEC”只是能力标签，不是这次跨客户切换安全的证明。

让每一层成功只证明它自己

RFC 9874 推荐三类做法：客户长期维护权威牺牲主机；显式删除并结合影响细节、通知和恢复；或采用合适的特殊用途域名方案。其他捷径把维护成本推给解析器、无关基础设施或未来注册人。

结论不是“不要删除”。域名退出和对象清理本来就是正常运营。真正需要拒绝的是一个成功码代替五项证明：服务器接受了命令；依赖被识别；受影响客户收到通知；恢复窗口仍有效；清除真正完成。只有把这些事实分开，删除才从一项技术动作变成可治理的变更。

来源