摘要

  • 客户 X 可以控制待删除域名及其下属主机，但客户 Y 的另一个域名仍可能依赖该主机；X 无权替 Y 改写关联。
  • 改名、进入 pendingDelete、通知、恢复、最终清除和用户侧 DNS 恢复是不同事实，不能由一条成功回执代替。

域名删除常被描述成所有权边界内的动作：赞助客户提交请求，服务器核对规则，然后返回结果。RFC 9874 说明这套直觉为何会失效。客户 X 同时赞助一个域名和它的下属主机；客户 Y 则把这个主机关联到自己的另一个域名。X 能解除自己的关联，却不能更新 Y 的域名对象。

早期 EPP 映射已经看见这种依赖。RFC 5731 不建议在下属主机仍有关联时删除域名；RFC 5732 也不建议在主机仍被其他对象使用时删除主机。这两条约束避免把整洁的对象删除变成静默的 DNS 中断，却留下一个真实难题：一个客户如何结束自己的责任，同时不把持续服务义务无限期背在身上？

一种已观察到的做法，是把主机改成待删域名之外的名称。服务器中的关联可以保留，控制风险却可能被转移。如果新的父域名可以注册，或后来落入第三方手中，新注册人就可能重新创建该主机并接收仍依赖它的域名查询。因此，改名不一定是清理，也可能是把潜在控制面交给未来的陌生人。RFC 9874 明确禁止使用假定不存在的外部主机名。

把地址指向知名公共递归解析服务同样不成立。递归服务不是委派所需的权威服务，依赖域名可能直接失效。AS112 也不是通用“牺牲主机”设施；误用会带来本地劫持机会和额外运维负担，并偏离其原始目的。

作为 BCP 244 发布的 RFC 9874，把可接受路径收窄为三类。第一，客户自己维护专用牺牲权威主机，同时保持父域名注册、地址记录和实际权威服务。第二，服务器显式删除主机及关联，但提供影响明细、受影响客户通知和可恢复阶段。第三，建立特殊用途的牺牲域名；如果这条路径未来成立，文档建议 sacrificial.invalid。后两类潜在实践没有被文档宣称为当前部署事实。

可恢复设计揭示了时间顺序的重要性。域名、下属主机和跨域关联可在 pendingDelete 期间继续被表示。公共 DNS 可能已经不可用，提前暴露损害；在最终清除前，RFC 3915 的赎回期机制仍允许反转。请求接受、可逆状态、受影响方响应窗口和不可逆清除必须各有时间戳。

通知也有证据边界。服务器可以先向删除方展示受影响对象，让其评估爆炸半径；也可以借助 RFC 8590 的 change poll 通知其他赞助客户。但是，投递 poll 消息不等于注册商已经读取，更不等于注册人收到通知、委派得到修复或用户恢复访问。

关联数量没有固定上限，服务器可能分批停用、恢复或清除。异步处理只解决工作量，不增加权限。后台任务完成，也不证明所有关系同时改变、所有通知到达或所有递归解析器已经收敛。

Heng Lu 的现实层级把链条拆为：声明的删除意图、保存的关系图、已接受与排队的状态变更、权威区状态、解析器观察和用户结果。前一层证据不能自动升格为后一层事实。最小初始规范支持一套窄而可互操作的删除约定，同时允许本地决定审批、节奏和恢复；运行代码优先则要求能重放的记录，而不是对成功码的信心。

DNSSEC 可以约束部分风险，却不是万能答案。多个名称服务器和签名委派能提高韧性；但若自动化只信任一个已被攻击者控制的名称服务器所发布的 CDS/CDNSKEY，不一致信号反而可能把临时故障升级为更深的控制转移。

SAC125 与 IETF 115 的 Risky BIZness 演示提供注册商名称服务器管理的生态背景。它们不证明任何具名运营方当前存在漏洞或不当行为。RFC 9874 是对一类风险的设计回应，不是事故通报。

来源