Summary

  • RFC 9874 addresses an EPP dependency that crosses client authority: one client may control a domain and its subordinate host while another client's domain relies on that host for DNS resolution.
  • Several convenient renaming practices can create failure or hijack risk. A restore-capable delete is safer, but command acceptance still does not prove that notices, DNS updates, rollback state and asynchronous purge all completed.
  • A cross-client deletion receipt should bind authority, affected-object scope, before-and-after DNS state, warning and approval, notification, redemption deadline, rollback and final purge without exposing unnecessary registrant data.

Client X sponsors domain1.example. It also controls ns1.domain1.example, a subordinate host object. Client Y sponsors domain2.example, which uses that host as a name server. Now Client X wants to delete domain1.example.

On a diagram, the dependency is obvious. In an EPP session, authority is divided. Client X can remove the host from its own domain, but it cannot edit Client Y’s domain. It may not even be able to see the other association. Client Y alone controls that domain’s provisioning state. Yet a server that accepts the deletion can still alter the DNS conditions under which Client Y’s registrant is reached.

This is the asymmetry at the centre of RFC 9874. The command belongs to one client. The operational consequence can belong to many.

Why the old cautions exist

RFC 5731 says a domain object should not be deleted while subordinate host objects remain associated with it. RFC 5732 says a host object should not be deleted while it is associated with other objects, because those domains can stop resolving. These are not arbitrary obstacles placed in front of cleanup. They preserve three kinds of consistency.

The first is DNS consistency. Deleting the superordinate domain can make subordinate name servers unresolvable. Deleting the host can strand every delegation that points to it. The second is client-server consistency. If the server silently deletes or detaches objects, the client may retain a different picture of what remains registered. The third is relational consistency inside the registry, where domain and host records may be joined by database dependencies.

RFC 9874 notes that observed client-server inconsistency has posed little operational risk. That does not erase the DNS or cross-client problem. It sharpens it: the costly consequence may appear outside the client that issued the command.

Renaming can transfer rather than remove risk

One way to satisfy a server’s deletion constraint is to rename the subordinate host so that it becomes external to the domain being removed. The new name is often called a sacrificial host. That manoeuvre preserves the relationship structurally, but the choice of new name determines who will control resolution.

Renaming to an external name presumed not to exist is convenient because the deleting client need not operate DNS. RFC 9874 says this practice MUST NOT be used. The presumed-empty parent can later be registered. An attacker can then create the corresponding host and receive queries for domains that still depend on it. What looked like administrative disposal becomes a path to resolution control.

Pointing glue at a prominent recursive DNS service is no cure. A recursive resolver is not authoritative for the affected domains. Queries can return SERVFAIL or other errors, and repeated failures can provoke aggressive retries. RFC 9874 also says this observed practice MUST NOT be used.

The allowed client-maintained option is more demanding. The deleting client keeps the sacrificial host’s parent domain registered, protects it and operates an authoritative service on the configured addresses. That avoids handing the dependency to an unknown registrant. It also creates a durable custody obligation. If the client later lets the parent expire or stops operating the service, the old risk returns after the original deletion has disappeared from ordinary attention.

A green command result therefore says nothing about future custody unless the new authority, protection and service obligation are recorded beside it.

Deletion with restore creates a useful middle state

The alternative path is explicit deletion with server support for cross-object effects. A server may detach a host from domains sponsored by other clients. This avoids sacrificing names, but it can leave a domain with one name server or none. RFC 9874 warns that the number of affected associations is unbounded and that a single operation can place strain on a registry.

The document joins four protections around that power. The request should be explicit. The deleting client can receive enough detail to assess the effect. Affected clients can be informed, including through EPP Change Poll. And the delete can preserve restoration through the RFC 3915 redemption period.

In that restore-capable model, the domain, subordinate hosts and their associations can remain in pendingDelete. They may be removed from DNS, making the impact visible, while still being recoverable. If the action proves accidental, malicious or more damaging than expected, restore can reconstitute the graph during the redemption window. Only at the end are the domain, hosts and associations purged.

That is a meaningful safety boundary, but not instantaneous completion. Disabling, re-enabling and purging a large association graph can be split into asynchronous tasks. A 1000-class EPP success response cannot, by itself, show that every zone update, client notice, restore record and final purge reached its intended state.

The receipt must cross the same authority boundary

The operational record should be designed around the dependency graph, not around the one client’s command log. A useful cross-client deletion receipt has at least six parts.

First, it identifies the request: transaction identity, authenticated client, target object, command time, server policy and the authority under which cross-client effects were permitted. Second, it freezes the dependency view: enumeration time and method, subordinate hosts, affected-domain count, other sponsoring clients where disclosure is lawful, and an explicit statement of what the requester was not allowed to see.

Third, it captures DNS state. That means the authoritative host names and addresses before the command, expected and observed zone state after it, DNSSEC and DS-relevant conditions, and whether the selected practice was maintained sacrificial service, special-use naming or restore-capable deletion. Fourth, it preserves decision evidence: warnings shown, affected-object details returned, manual approval when required, and the exact choice made.

Fifth, it records notice and reversibility. Each affected client needs a delivery or poll-queue record, without publishing registrant secrets. The receipt should name the redemption deadline, restore authority, retained associations and test that rollback can rebuild them. Sixth, it closes the asynchronous tail: task identities, partial failures, retry history, final purge, final DNS observation and the person or system that accepted completion.

This receipt is not a new EPP extension and it is not a requirement in RFC 9874. It is an operating record derived from the governance problem the BCP exposes. The record can store counts or privacy-preserving references where commercial or personal data cannot be shared. Secrecy about identities does not require ambiguity about whether dependencies were counted, notified and resolved.

DNSSEC does not erase bad custody

It is tempting to treat DNSSEC as a blanket answer. RFC 9874 is more careful. Signed delegations and multiple hosts can reduce some risks. But if an attacker gains one name server and automated DS maintenance consults inconsistent CDS or CDNSKEY data without checking all authoritative servers, the attacker may influence the DS state. With CSYNC, the legitimate name servers could eventually be removed.

That scenario does not mean DNSSEC is harmful. It means security automation inherits the custody and consistency of its evidence. The deletion receipt should therefore show whether automated DS maintenance was active, which servers were queried, whether their answers agreed and what change authority was exercised. “DNSSEC enabled” is a capability label, not proof that the cross-client transition was safe.

Success belongs to a bounded claim

RFC 9874 recommends three broad paths: a client-maintained authoritative sacrificial host; explicit deletion with detail, notice and restore; or an appropriate special-use-domain design such as the proposed sacrificial.invalid pattern. It rejects or discourages the convenient practices whose risk is displaced onto resolvers, unrelated infrastructure or later registrants.

The practical lesson is narrower than “never delete.” Deletion can be legitimate and necessary. The lesson is that success must be stated at the right layer. “The registry accepted Client X’s command” is one claim. “Client Y was notified” is another. “Every affected delegation remained safely controlled” is another. “The association graph can still be restored” has a deadline. “Purge is complete” may arrive much later.

A good system lets each claim become true on its own evidence. A bad system compresses them into one green line.

Sources