Summary

  • draft-brown-epp-deleg-03 proposes EPP operations to inspect, create, add, remove or remove all DELEG records associated with a domain.
  • The draft expects DELEG and traditional NS provisioning to coexist for years, so one accepted repository state can still produce two public delegation views that must be reconciled.
  • A safe change record continues beyond EPP success through zone generation, parent publication, DNSSEC, authoritative serving, resolver capability, cache convergence and an application canary.

The cleanest failure begins with a green response.

A sponsoring registrar sends an EPP update containing an empty deleg:all instruction. The server authenticates the client, accepts the command and returns its transaction identifier. The registry repository now contains no proposed DELEG records for the domain. A conventional monitor asks for NS records and sees the old delegation still working. Nothing looks broken.

A DELEG-aware resolver is asking a different question. Its path depends on what the parent published, whether the authority loaded the new zone, which delegation-extension capability was negotiated and what its cache still holds. The green EPP transaction does not answer any of those questions.

That is the control boundary exposed by revision 03 of the proposed EPP DELEG mapping. The revision replaces the earlier parameter syntax with repeated named deleg:param elements, advances the XML namespace, adds deleg:all for complete removal and introduces explicit operational requirements. Its Datatracker record and revision history also set the status boundary: this is an active individual Internet-Draft with no RFC stream, not an IETF standard or evidence of deployment.

One command, three different truths

The draft defines three EPP views of the proposed data. An info response may reveal the stored DELEG representation. A domain create may carry one or more DELEG records. An update may add records, remove identified records or remove them all.

Those operations are deliberately repository operations. RFC 5730 gives EPP its client-server command, response and transaction-identifier framework. RFC 5731 maps domain objects; RFC 5732 maps host objects. A successful response is valuable evidence: it can identify the request, the server's decision and the transaction that committed it. It is not a receipt from the zone generator, signer, authoritative servers or recursive resolvers.

The distinction matters because the EPP draft anticipates a long overlap. It says most domains will need both DELEG and traditional NS records in their parent zone for the foreseeable future, and that servers should allow DELEG to coexist with EPP host objects or host attributes. The migration is therefore not a database column swap. It is a period in which one domain may have two delegation representations, consumed by different software.

A new source of truth still has a projection problem

The underlying Working Group proposal, Extensible Delegation for DNS, is designed to improve the old model in which parent and child NS sets can disagree. It makes DELEG authoritative at the parent and capable of carrying extensible, DNSSEC-protected parameters. But it also allows a DELEG RRset to appear with or without NS. Without NS, software that does not understand DELEG cannot resolve the child.

That compatibility fact changes the meaning of deleg:all. Removing all proposed DELEG data might be an intentional return to NS-only service. It might be a rollback after a failed trial. It might also be an incomplete or unauthorised change that stays invisible to an NS-only monitor. The XML element has exact syntax; its operational meaning depends on the surrounding state.

The companion DNSOP draft on delegation-extension protocol changes supplies the capability negotiation and downgrade-resistance context. Again, it is work in progress. An EPP server cannot attest that parent authorities or resolvers implemented its signal correctly merely because the repository accepted DELEG-shaped data.

The parent-side projection adds more failure states. The DELEG draft forbids DELEG at the child apex because the wrong placement can cause DNSSEC validation failure. RFC 4035 explains the validation machinery around authenticated DNS data. Correct validation can establish that a received RRset belongs to an authenticated chain under the applicable rules. It cannot establish that the RRset is the newest intended projection of a registrar request, or that an NS-only client received an equivalent delegation.

Vocabulary is a moving dependency

Revision 03 makes parameter handling strict. A server must reject an unknown parameter name or syntactically invalid value. Within one DELEG record, names are unique. The draft also requires clients and servers to update periodically the list of DelegInfoKeys registered for DELEG.

That requirement creates a versioned dependency outside the transaction. Two otherwise healthy EPP implementations can disagree because their key vocabularies were refreshed at different times. A client may construct a parameter that the current proposal recognizes while the server still rejects it. Later, both may accept it while the zone generator cannot serialize it. “Schema valid” and “publishable by this estate” are not the same claim.

The base DELEG draft asks IANA to create a DELEG Delegation Information registry. The EPP draft asks for XML namespace and extension registration. RFC 7451 defines the EPP extension registry framework, while the live IANA EPP Extensions registry is the authoritative place to check actual assignments. The frozen registry does not list this proposed extension. A request in a draft is not an assignment.

The receipt must follow the change into DNS

A defensible migration record starts before the XML. It names the registrant intent, the human or system allowed to express it, the registrar credential and the sponsoring-client relationship. It retains the exact request bytes, namespace, DelegInfoKey snapshot, client transaction identifier, server result and server transaction identifier.

The next ledger is the registry's committed object version. From there, record the reconciliation rule between DELEG and legacy host/NS data. Capture the zone-generation input and output. If deleg:all was used, state whether an empty DELEG projection was the intended result and which NS safety path remained.

Then leave the repository. Record the parent-zone serial, signed RRsets and loading result from every relevant authority. Query both DELEG-aware and unaware paths. Preserve resolver software and capability, negotiation result, validation status, cache epoch and fallback. Finish with an application canary and an explicit rollback decision.

The three disclosed Heng Lu essays are editorial lenses, not protocol authority. Running-code primacy argues for testing the state that actually operates. Minimum initial specification and local decision favours a narrow interoperable contract without erasing local responsibility. Reality layers warns against treating a symbol at one layer as truth at the next. Applied here, the lesson is modest: registry acceptance, parent publication, resolver belief and user reachability need separate receipts.

Official record

The source packet also preserves the current EPP DELEG Datatracker record, its history, the exact revision 03 text, the DELEG base proposal, the delegation-extension proposal, the EPP specifications for core, domains and hosts, the EPP extension framework, DNSSEC validation and the live IANA registry. None proves a named implementation, assignment, transaction or service result.