Summary

  • The DNS Delegation Extensions draft uses an EDNS(0) DE flag to negotiate awareness and code-point ranges to determine how new Delegation Types alter referrals.
  • Downgrade resistance comes from a different object: an ADT commitment in a validated DNSKEY RRset, enforced through NSEC or NSEC3 proof, and only when the zone is signed and the resolver validates.

Imagine a resolver sends a query with the Delegation Extensions flag set. The recursive service returns an answer with the same flag. An operations dashboard records a successful negotiation. Yet the referral contains only an old-style NS RRset because an on-path attacker stripped the new Delegation Type records—or removed DE from the query before it reached the authoritative server.

The dashboard is not necessarily wrong. It is answering the smaller question: did these endpoints advertise awareness in this exchange? The error begins when that receipt is promoted into a security conclusion.

Revision 11 of DNS Protocol Modifications for Delegation Extensions makes that distinction unusually visible. Dated 17 September 2026 and expiring on 21 March 2027, it is an active DNSOP Working Group Internet-Draft intended for the Standards Track. It is not a final RFC, an implementation result or evidence that operators have deployed it. Its design nevertheless exposes a recurring governance problem: a capability signal is useful only if systems preserve what it does not prove.

The draft defines a class of Resource Record types that are authoritative at a delegation point and are meant to help a resolver process that delegation. These “Delegation Types” occupy a proposed reserved range from 0xF000 to 0xF1FF. The range is divided into four segments. NS-Omitting types can replace the information in the traditional NS RRset. NS-Preserving types supplement it. On-Demand types are normally omitted from referrals and queried explicitly. Private types retain NS-preserving referral behavior.

That division is operational, not decorative. The numeric segment tells an aware server whether to include NS and tells an aware resolver which source of delegation information has precedence. A type number is therefore a compact policy instruction on the wire.

The flag negotiates a language

The proposed EDNS(0) DE flag occupies bit 2. An aware resolver sets it in a query to say that it understands Delegation Types. An aware recursive resolver receiving DE from an aware stub echoes it in the response. If the authoritative server receives a query with DE clear, it behaves for that exchange as the legacy DNS requires: Delegation Types are treated as ordinary data, and a referral remains dependent on NS.

With DE set, the server includes NS-Omitting, NS-Preserving and Private Delegation Type RRsets present at the delegated name. It withholds On-Demand types unless they were explicitly requested. If even one NS-Omitting type is present, the server must omit the NS RRset, irrespective of other types and even when the query asks for NS. Without an NS-Omitting type, it must include NS.

This is a careful compatibility switch. An unaware resolver is not handed delegation semantics it cannot execute. An aware resolver can receive the richer form. But DE travels in the request. An attacker able to modify traffic can clear it. The authoritative server then has a legitimate reason to produce an old-style response.

An echoed DE flag does not cure that weakness. It may show awareness at a recursive boundary while saying nothing about the query that arrived at the authoritative server. It is a negotiation receipt, not a signature over the referral and not a promise that every intermediary preserved the request.

ADT creates an obligation outside the query

The draft introduces a second signal for the security job: the Authoritative Delegation Types flag, proposed as bit 14 in DNSKEY. A validating resolver determines ADT from the delegating zone's validated DNSKEY RRset. When any key in that RRset carries ADT, the referral must include NSEC or NSEC3 proof showing whether Delegation Types exist at the delegated name.

The resolver compares NS-Omitting, NS-Preserving and Private RRsets in the referral with the authenticated Type Bit Maps. If the proof says a type exists and the referral omits it, the resolver treats the response as tampered with and ignores it. On-Demand types can appear in the bitmap without being carried in an ordinary referral because their absence there is expected.

The important feature is time and location. The obligation comes from a DNSKEY RRset that the validator has already authenticated. It does not depend on the mutable DE bit in this particular query. An attacker can strip DE and induce the server to return only NS, but cannot make the validator forget that the signed zone committed to authoritative Delegation Types. The missing proof becomes evidence of interference.

This protection is conditional. The delegating zone must be DNSSEC-signed. ADT must be set. The resolver must validate DNSSEC and enforce the new check. Remove any one condition and this mechanism offers no cryptographic protection from referral stripping or DE stripping. A report that records “ADT supported” without those predicates overstates the evidence just as much as one that records “DE negotiated” as “downgrade safe.”

ADT being clear has a precise negative meaning too. The consistency check does not apply. A positive DELEG RRset should not be declared DNSSEC-bogus merely because the flag is clear. The resolver follows the normal referral rules. “Not bogus for this reason” is not the same as “protected against downgrade.” Mature observability has room for both statements.

Precedence refuses a silent fallback

When a referral contains an NS-Omitting type, the resolver must use that data and ignore any NS records that appear alongside it. It must neither validate nor cache those NS records. This rule prevents a failed new mechanism from quietly leaking DNS queries onto traditional, potentially unencrypted transport.

The consequence is deliberate brittleness. If the resolver knows that an NS-Omitting RRset exists but the records are unusable, it must not fall back to NS. It treats the available servers as unreachable. Availability is sacrificed rather than silently discarding the security property that justified omitting NS.

That trade is easy to erase in an incident response. An operator sees a reachable NS server and asks why software refused it. The useful answer is not simply “the new type failed.” The resolver had evidence that NS was no longer an authorized recovery path. Restoring reachability by forcing fallback would change policy, not merely fix transport.

Where no NS-Omitting type exists, NS remains the delegation basis and NS-Preserving or Private types supplement it. Across several delegation levels, an aware resolver must handle arbitrary mixtures. This means deployment is not one binary feature flag. Every hop can present a different evidence shape.

A diagnostic code cannot build a path

Compatibility becomes stark when a parent publishes only Delegation Types and no NS. An unaware resolver sends DE clear. From that resolver's perspective, the authoritative server cannot form a usable referral, so it returns a negative response. The draft says the server should include Extended DNS Error code 34, “New Delegation Only,” unless local policy says otherwise.

EDE 34 is valuable evidence. It distinguishes a deliberate compatibility boundary from a random absence. It can tell an operator why a name failed. It cannot teach the unaware resolver how to use the new delegation, reconstruct stripped records or make the name reachable.

The same limit applies to denial proofs. If an attacker strips DE to trigger a negative response, an ADT-aware validator can require authenticated proof and reject a bare negative answer. Compact Denial of Existence needs special care: an NXNAME-based response matching the queried name would conceal the Delegation Type bits at the delegation point, so the draft requires a conventional Name Error proof for this check. The proof makes rejection explainable. It does not manufacture a working server.

The registry executes policy

The proposed type range is split because generic implementations need to know what an unfamiliar Delegation Type means for a referral. 0xF0000xF07F says NS-omitting. 0xF0800xF0FF says NS-preserving. 0xF1000xF1EF says on-demand. 0xF1F00xF1FF is private use with NS-preserving behavior.

Allocation in the public segments is therefore an act of protocol governance. Expert review must test whether a proposal belongs in the requested segment, whether an aware implementation that does not understand the specific type can process it safely, and whether its security properties fit the DNSSEC rules. A type designed to replace NS but allocated in an NS-preserving segment would not merely have an untidy registry entry. Its code point would tell generic software to do the wrong thing.

This is the kind of control surface that disappears when registry work is treated as clerical. The number commits future implementations to default behavior. Review records should preserve the behavioral reason for the segment, the unknown-type outcome and the downgrade assumptions, not only the registrant and mnemonic.

Population is not use

The draft updates the conceptual resolver structure called SLIST so it can contain multiple forms of delegation information and behave as a set. Duplicate values appear only once. It also warns that delegation data can create cycles, dependencies and runaway work, requiring explicit processing limits.

But the draft is equally clear about the evidentiary edge: RFC 1034 and this document define how SLIST is populated, not how a resolver chooses or uses a server from it. An entry proves eligibility under the construction algorithm. It does not prove that the resolver selected the server, established a connection, used encrypted transport, received an answer or delivered a user-visible result.

A useful trace keeps those stages separate. First record the outgoing DE state and the capability observed at the recursive boundary. Then record the authoritative referral, validated DNSKEY and ADT state, NSEC or NSEC3 proof, type-code segment and precedence decision. After that come SLIST construction, actual server choice, transport, validation outcome and application response. Compressing the sequence into “new delegation used” destroys the very evidence needed to diagnose partial deployment.

End-to-end is a chain, not an adjective

The draft requires an aware, security-aware stub to use an aware, security-aware resolver. An aware validating resolver that forwards must use aware, security-aware forwarders. Otherwise DNSSEC-secure zones may fail validation while insecure zones produce inconsistent results.

This is an uncomfortable transition property. A capable endpoint on each side does not prove the middle preserved the mechanism. A signed zone publishing Delegation Types is required to set ADT, and a zone relying on a security property such as encrypted transport must be signed. Those are normative requirements in a draft, not observations that deployments comply.

Leadership should therefore resist a single “enabled” metric. The defensible unit is a chain of receipts: awareness negotiated, durable zone commitment authenticated, denial proof checked, precedence applied, resource limits respected, server selected, and transport observed. A gap remains a gap. It should not be filled by confidence borrowed from the nearest successful stage.

The bit that came back did its job. It showed that one part of the exchange spoke the new language. The protection begins only when a separate authenticated commitment makes missing delegation evidence impossible to ignore.

Sources