Summary

  • IANA's DNS Parameters registry, last updated 24 August 2026, now lists a presence-only Resolver Information key named deleg. Its registration is temporary, expires on 24 August 2027 and references draft-ietf-deleg-11.
  • The entry creates a stable vocabulary for a resolver to claim DELEG support. It does not prove that the resolver sets the query-time DE bit, receives or validates a DELEG referral, understands every mandatory parameter, successfully reaches an authoritative server, or uses the protocol in production.

One new row, four different claims

A monitoring system queries a recursive resolver's published Resolver Information and finds deleg. The inventory immediately changes the resolver's state from “experimental” to “DELEG deployed.” No packet has been captured. No authoritative server has returned a DELEG RRset. No resolution has completed using the new path.

The first fact is real: on 24 August, IANA registered the key. The last conclusion is not.

The DNS Resolver Information Keys table now says that the presence of deleg indicates support for the DELEG protocol. IANA marks the entry temporary, records its registration and expiry dates, and points to revision 11 of the IETF working-group draft. That is a concrete coordination event. It gives resolver operators, monitoring tools and interoperability tests one shared name instead of private labels.

It is not a deployment certificate. The news matters precisely because it makes a previously fuzzy claim observable while leaving the later evidence layers intact.

What IANA registered

RFC 9606 defines DNS Resolver Information as structured key/value data and established the IANA registry for those keys. Existing entries can disclose QNAME minimisation, enabled Extended DNS Error codes or an information URL. The new deleg entry is presence-only: the key itself carries the claim.

The registration is explicitly time-bounded. IANA records 24 August 2026 as the registration date and 24 August 2027 as expiry. Temporary registration allows implementation and coordination around work that has not completed the standards process; it also creates a date on which the claim must be renewed, replaced by a durable assignment or removed.

The reference is draft-ietf-deleg-11, dated 23 July 2026. The Datatracker lists it as an active Internet-Draft in Working Group Last Call. It also states the normal Internet-Draft boundary: the text is work in progress and may be updated, replaced or made obsolete. Revision 11 still contains placeholder type values for DELEG and DELEGPARAM. IANA's Resolver Information key therefore does not allocate those final RR types and does not convert the draft into an RFC.

Disclosure is not query-time signaling

The draft describes a DELEG-aware resolver setting the Delegation Extensions bit in EDNS queries. That bit tells an aware authoritative server that the resolver can process the newer delegation response. IANA separately lists the DE bit as a temporary EDNS flag registration, dated 20 July 2026 and expiring one year later, with a reference to the companion delegation-extensions draft.

These are related but different observations. deleg in Resolver Information is a published capability statement. The DE bit is behavior in a particular DNS request. A resolver might advertise the key but disable the feature on some interfaces, views or policy domains. A packet may carry the bit even when the next authority is unaware. Neither fact substitutes for the other.

For operators, the useful evidence sequence is now explicit:

  1. the IANA registry defines the vocabulary;
  2. a particular resolver exposes deleg in its Resolver Information;
  3. the resolver sets the DE bit on an applicable query;
  4. an authoritative server returns a DELEG-aware response;
  5. DNSSEC and protocol checks accept the delegation data;
  6. the resolver constructs a usable server set and obtains the intended answer.

Stopping at step two turns observability into marketing.

A DELEG answer still has eligibility rules

Revision 11 describes DELEG and DELEGPARAM records carrying extensible key/value information. Initial keys can identify server IPv4 or IPv6 addresses, server names and indirection through include-delegparam. A mandatory key follows the same broad extensibility principle familiar from SVCB: a record is unusable if it depends on a key the resolver does not understand.

That makes “supports DELEG” a capability family, not one Boolean execution guarantee. Implementations can differ in recognized keys, DNSSEC state, indirection policy, loop and work limits, forwarding behavior and rollout configuration. A self-declared capability says where testing may begin; it does not report which candidate record survived.

The draft also expects legacy NS and DELEG mechanisms to coexist during incremental deployment. A delegation using only DELEG would be invisible to unaware resolvers. Operators therefore need to distinguish readiness for experiments from a decision to remove compatibility data. The temporary registry entry is evidence for the former, not authority for the latter.

Why this small registry change matters

Internet protocols become operational through shared syntax, implementations and measured behavior. The new key advances the first two coordination problems. Tools can ask resolvers a common question; operators can declare intent without inventing vendor-specific fields; testbeds can compare the statement against packets and outcomes.

It also creates a governance obligation. If a resolver publishes deleg, the operator should be able to show what that means: software version, enabled scope, recognized draft revision, DE-bit traces, authoritative test zones, DNSSEC results, fallback behavior and failure metrics. Otherwise the new public signal will accumulate inconsistent meanings before the protocol has stabilized.

Sources