Summary

  • An EPP client may control the domain and subordinate host it wants removed while another client still depends on that host for a different domain.
  • Renaming, pendingDelete, notification, restoration, final purge and public DNS recovery are different events; no single success response proves the whole transition safe.

Deletion sounds like the most local of registry actions. A sponsor asks a server to remove an object it controls; the server checks policy and replies. That mental model fails when the object is a subordinate host. In the case at the centre of RFC 9874, Client X sponsors both a domain and a host below it, while Client Y has associated that host with another domain. X can remove its own association. It cannot rewrite Y's domain.

The older EPP mappings already recognised the dependency. RFC 5731 says a domain should not be deleted while subordinate hosts remain associated with it. RFC 5732 says a host should not be deleted while other objects depend on it. These constraints prevent a neat object-store operation from becoming a quiet DNS outage, but they leave a commercial problem: how does one client exercise a legitimate deletion right without indefinitely carrying infrastructure for somebody else?

One observed workaround is to rename the host so that it is no longer subordinate to the domain being deleted. The relationship in the registry can survive, yet the risk has not disappeared. If the new parent name is registrable, or later passes to another registrant, that party may gain the ability to create the host and receive queries for domains that still name it. A rename can therefore move a latent control surface rather than retire one. RFC 9874 says a presumed nonexistent external name must not be used.

Pointing the host toward a prominent recursive service is no substitute. A recursive resolver is not the authoritative service the dependent delegation requires. Nor does the AS112 project provide a general dumping ground for sacrificial names. Misusing it can produce local interception and impose maintenance outside its intended purpose.

RFC 9874, published as BCP 244, narrows the safe choices to three families. A client may maintain a dedicated sacrificial authoritative host, provided it keeps control of the parent, publishes addresses and actually runs authoritative DNS. A server may explicitly delete hosts and their associations under a restore-capable process that supplies details and notifies affected clients. Or the community may establish a special-use sacrificial domain; the document recommends sacrificial.invalid if that route becomes available. It does not claim that the latter two practices are deployed today.

The restore-capable option is especially revealing. Domain, subordinate hosts and cross-domain associations can remain represented during pendingDelete. Public DNS may already become unavailable, offering a preview of damage, while RFC 3915 provides the redemption vocabulary for reversal before final purge. That makes four clocks visible: the client's request, the server's reversible state, the affected parties' opportunity to respond and the eventual irreversible removal. Treating them as one timestamp erases the safety property.

Notice is also evidence with limits. A server can provide the deleting client with affected-object details, allowing blast-radius review before approval. It can use the RFC 8590 change-poll mechanism to inform other sponsoring clients. A poll item proves neither that a registrar consumed it nor that a registrant was contacted, a delegation repaired or users restored to service.

Scale does not relax authority. A host can have an unbounded number of associations, so a server may need to disable, restore or purge work in batches. Completion of background work answers a capacity question. It does not prove that the requester was authorised to affect every relationship, that all notices arrived or that resolvers have converged.

Heng Lu's reality-layer doctrine gives operators a sharper ledger: declared deletion intent; the stored dependency set; accepted and queued transitions; authoritative zone state; resolver observation; and user outcome. Evidence from one layer must not be promoted into truth at the next. His minimum-initial-specification argument favours a small interoperable contract while leaving approval, timing and restoration local. His running-code test demands replayable traces rather than confidence in a clean status code.

DNSSEC changes parts of the threat, not the need for proof. Multiple name servers and signed delegations can constrain some failures. Yet automation that trusts attacker-controlled CDS or CDNSKEY data from one compromised name server can convert inconsistency into a deeper transfer of control. Operators should test agreement, authority and chronology rather than treating the presence of DNSSEC material as a universal cure.

The surrounding record matters, but it must be stated carefully. SAC125 and the IETF 115 Risky BIZness presentation describe ecosystem risks around registrar name-server management. They do not establish present misconduct or vulnerability at any named operator. RFC 9874 is a design response to a class of risk, not an incident report.

Sources