Summary

  • Revision 14 of the active DNSOP delegation-revalidation draft lets a resolver treat a parent referral as continuous when it still points to the same delegation and shares at least one nameserver with the cached referral; if DS data was seen in both states, at least one delegated signer must overlap as well.
  • A wholly novel NS set, a wholly novel DS set or a transition between empty and non-empty DS state is an authority change under the algorithm. Cached data at or below that point must then stop being used, while strict and opportunistic modes distribute failure and fallback differently.
  • The intersection is a resolver continuity predicate, not proof of the operational mandate behind a migration. A delegation-transition receipt should record the intended overlap, provisioning authority, TTLs, observation window, retirement condition and rollback owner. That receipt is Daniel Kade's proposal, not IETF text.

DNS delegation has two visible faces. The parent zone publishes a referral: nameserver names, any necessary glue and, for a secured delegation, a DS set. The child zone publishes an authoritative NS set at its own apex and address data for its servers. Operators are expected to keep the two sides consistent. The protocol does not make that consistency automatic.

The difference can persist without an obvious outage. A parent may carry a long, fixed delegation TTL while a child uses a shorter apex NS TTL. A migration may update one side before the other. A server may omit an apex NS set from ordinary answers because minimal responses have become normal. Some recursive implementations prefer the referral; others learn and prefer the child set; still others behave according to whichever sequence of answers reached their cache.

Revision 14 of Delegation Revalidation by DNS Resolvers tries to make that behavior more predictable. The text was posted on 2 September 2026, is active DNSOP Working Group work intended for the Standards Track and expires on 6 March 2027. Its Datatracker state is “Waiting for WG Chair Go-Ahead”. It is an Internet-Draft, not an RFC or an instruction that every resolver must deploy the algorithm.

The draft combines three related operations. After following a parent referral, a resolver should explicitly ask a delegated server for the child zone's authoritative apex NS set and give that answer the higher cache credibility described by RFC 2181. It should obtain authoritative A and AAAA data for the nameservers where possible instead of indefinitely trusting lower-ranked additional data. It should later return to the parent to confirm that the delegation still exists and still represents sufficiently continuous authority.

That last operation contains a deceptively small governance boundary. The resolver is not reconstructing the registrar ticket, registry approval or operator handoff. It is comparing sets.

What the overlap test actually says

A cached delegation becomes a revalidation point. The resolver asks the parent an in-zone question and examines the resulting referral. Continuity requires the referral still to be for the same point in the hierarchy. The current parent NS set must overlap the cached parent referral by at least one nameserver name. If the cache saw a DS set before and the new referral also contains DS data, at least one delegated signer must overlap too.

The qualification about DS is essential. “One shared nameserver keeps the delegation valid” is incomplete when the resolver is also carrying evidence about the signing chain. The algorithm treats a wholly novel DS set as a change of authority. It also treats a move from no DS to DS, or from DS to no DS, as a change rather than continuity.

The comparison is about membership, not majority. Four old nameservers can become one old plus three new nameservers and still intersect. One old signer can coexist with a new signer during a rollover. This is exactly why the rule can accommodate staged transitions: an operator need not replace the whole delegation in one indivisible step and force every cache to discard everything below it.

If there is no referral, if the referral is for a different zone cut, or if the NS or applicable DS set is wholly novel, the outcome reverses. The draft says cached data whose owner names lie at or below that revalidation point must not be used. An implementation can remove it directly or let a cache generation become unreachable, but subsequent behavior must be as if the data disappeared.

That consequence reaches beyond the delegation record itself. Addresses, answers and negative data below the changed cut may all have been obtained through an authority chain the resolver no longer accepts. The invalidation boundary follows the control change down the cached namespace.

The algorithm therefore needs only a defensible continuity rule. It does not need to decide whether the surviving nameserver is the old operator's last machine, a deliberately shared anycast name, a registrar-managed service, an overlooked dependency or a compromised endpoint. Those are operational facts outside the DNS response.

Parent truth, child truth and service continuity

The draft first gives the child-apex NS set higher credibility. That follows the DNS ranking rules: the child is authoritative for its own apex NS RRset, whereas the parent's copy is referral data. A resolver may never learn that child set through normal application traffic, so revision 14 recommends a dedicated NS query in parallel with the triggering resolution.

If the direct child query succeeds, later queries should prefer the child-apex nameservers. If it fails or returns no data, the parent set remains preferred for service. The response to a normal user query need not wait for this work in opportunistic mode.

This creates two different meanings of “current”. The child answer can be the most credible account of which servers the child operates now. The parent answer remains the decisive account of whether the parent still delegates the name and whether it has re-delegated or removed it. A resolver that refreshes child data forever without returning to the parent can cling to an old operator after the parent has moved the delegation elsewhere. That is the ghost-domain failure the periodic check is meant to constrain.

The nameserver addresses add another layer. Glue and other additional data can be necessary to reach the child, yet those records may be non-authoritative. The draft recommends querying the authoritative address RRsets and upgrading them. If addresses in an authoritative answer are complete, signed and DNSSEC-secure, verification can be enough. Otherwise, separate address queries are needed. A resolver may retain lower-ranked glue as a last resort when the supposedly better addresses are unreachable.

That last resort protects availability. It also means an audit cannot infer resolver behavior from a single NS snapshot. Which addresses were reachable, which data ranked higher, which fallback survived and whether the validating query finished before the user answer all matter.

Strict and opportunistic modes spend different budgets

Strict revalidation can hold the triggering query until the resolver has confirmed that the answer came from a server at an authoritatively acquired address for an authoritatively acquired name. That reduces forgery and eavesdropping exposure. If the child NS data is broken and lower-ranked referral data is not allowed as fallback, the same strictness turns a validation fault into hard resolution failure.

Revision 14 therefore recommends limiting strict upgrades to the root and zones delegated directly from it. Those zones are expected to have high-quality child NS sets. Further down the hierarchy, experience with mismanaged zones makes universal strictness harder to justify.

Opportunistic mode usually lets the ordinary resolution finish before the validation query. It can learn better infrastructure data for later use without adding the same latency to the current user. When a delegated server mishandles an explicit apex NS query, the resolver abandons the upgrade for that zone and returns to the parent's referral data.

The two modes do not merely tune performance. Strict mode accepts a larger availability consequence in exchange for a stronger authority chain. Opportunistic mode preserves service through lower-ranked fallback but cannot claim the same protection. A product label that says only “delegation revalidation enabled” hides the policy choice that matters most during a broken transition.

The clock is the shortest of three clocks—subject to a floor

The cache must revisit the parent no later than the shortest relevant TTL: the parent NS TTL, the parent DS TTL when DS exists and the child-apex NS TTL. Parent and child clocks impose complementary limits. The parent clock constrains how long a resolver can honor a delegation after parent-side removal or re-delegation. The child clock lets a child request quicker reconsideration of its operating set.

But the draft also tells a resolver to impose a sensible minimum TTL floor against computational denial of service. A zone able to force arbitrarily frequent revalidation could turn short TTLs into resolver and authoritative workload.

The floor is necessary discretion, not a universal number supplied by the draft. It means an operator cannot treat its shortest advertised TTL as a promise that every recursive cache will recognize revocation at exactly that instant. Resolver policy can lengthen the practical observation interval; outages, negative caching and prefetch behavior can add other timing differences.

Validation failures must be cached under RFC 9520 so a failing zone does not provoke aggressive repeated queries. The draft also warns that revalidating names and addresses may substantially increase traffic toward authoritative servers. Work ceilings and failure caching are part of the security model because an algorithm that proves authority by doing unbounded work can become its own attack surface.

A mismatch is evidence, not a verdict

When the authoritative child-apex NS set differs from the parent referral, revision 14 permits the resolver to report the mismatch to RFC 9567 report channels for both sides. It proposes an Extended DNS Error code for referral NS mismatch, but the code remains TBD in the draft.

The text correctly says a mismatch is not necessarily a resolution failure. Migration order, fixed parent TTLs and routine operational lag can create a difference that still serves traffic. Conversely, a successful answer does not show that the lingering difference was authorized or harmless.

An error report is a witness statement from one resolver path. It can show which sets were observed and when. It cannot authenticate a provisioning request, decide which side should change or prove that an overlap was intentional. Report timing is also shaped by cache state, query demand and RFC 9567 behavior. Operators should use the reports as evidence to reconcile, not as an automated judgment against the parent or child.

The missing transition record

Suppose a zone moves from operator A to operator B. The new parent referral deliberately retains one A nameserver while B's servers are introduced. The DS set likewise retains one signer during a controlled rollover. To the resolver's set comparison, this is continuity. To the migration team, it should be a temporary state with a named purpose and closing condition.

Without a separate record, later observers cannot distinguish a planned bridge from residue. The old provider may believe service ended. The registry may have processed only part of a change. The child apex may already advertise the new set while the parent still carries the old. An incident responder may see the overlap and assume that somebody else owns it.

A delegation-transition receipt makes that temporary authority legible. It begins with snapshots: the old and intended new parent NS and glue, the old and intended child-apex NS, and both DS states. It names the exact server names and signer identities expected to overlap. It records why they overlap and the time or condition that retires them.

The receipt then points to the control-plane authorization: a registry or registrar change reference, the responsible old and new DNS operators, the person permitted to approve the final removal and the person able to roll back. It is not itself authentication and should not contain reusable credentials. Its purpose is to connect wire observations to an accountable change process.

The timing section records the three TTLs, the shortest protocol trigger and any declared assumptions about resolver floors. It distinguishes “old service stops accepting changes”, “parent no longer publishes the old server”, “old server stops answering authoritatively” and “monitoring no longer sees old paths”. Those are separate events, and collapsing them into one completion date is how residual authority becomes invisible.

Monitoring should cover parent referrals from diverse vantage points, child-apex NS answers, DS continuity, authoritative addresses, reachability, mismatch reports and whether old servers continue to answer. It should also specify whether testing models strict or opportunistic resolvers. Passing in opportunistic mode does not show that a strict resolver would avoid failure.

Closure requires evidence that the intended new state is present on both sides, the planned overlap has ended, the old operator no longer serves unintended authority and rollback is no longer needed. If a wholly novel set is intentional, the receipt should anticipate descendant-cache invalidation rather than describing the resulting misses as an unexplained resolver incident.

The receipt does not alter revision 14 and no resolver consumes it. It sits beside registry, registrar and DNS-operator procedures as an operational governance artifact. The draft answers when a cache may regard authority as continuous. The receipt answers whether humans meant that continuity to exist.

Sources

  1. Delegation Revalidation by DNS Resolvers — revision 14
  2. Datatracker record for delegation revalidation
  3. Delegation-revalidation document history
  4. DNSOP active documents
  5. DNSOP charter
  6. RFC 1034 — Domain Names: Concepts and Facilities
  7. RFC 2181 — Clarifications to the DNS Specification
  8. RFC 9520 — Negative Caching of DNS Resolution Failures
  9. RFC 9567 — DNS Error Reporting
  10. Extensible Delegation for DNS — revision 11