Summary

  • draft-ietf-dnsop-ns-revalidation-14 lets a resolver prefer the authoritative child-apex NS set, but requires a later return to the parent so a still-answering former child cannot perpetuate authority after re-delegation or removal.
  • The operational receipt is a current chain: parent referral shape, NS and DS overlap, the shortest supporting TTL, usable name-server addresses, cache invalidation and a fresh answer. None of those records alone proves the others.

The old servers did not stop answering

Imagine a zone moving from one DNS operator to another. The parent publishes a new delegation. The new servers are ready. Yet a resolver keeps an old child-apex NS set in cache, refreshes that set by asking the old servers, and continues sending queries there. The old servers still hold a copy of the zone and still answer with the authoritative bit set.

At the packet level, nothing looks silent. At the message level, the reply can be well formed. At the child-zone level, the server can be authoritative for the data it serves. At the delegation level, however, the parent has already withdrawn the authority that made that child reachable through the hierarchy.

This is the central problem in revision 14 of draft-ietf-dnsop-ns-revalidation, dated 2 September 2026. The draft is active DNSOP working-group work intended for Proposed Standard status. The Datatracker says Waiting for WG Chair Go-Ahead and I-D Exists. It is not an RFC, and its optional algorithm is not proof that the resolver in front of any reader implements it.

What the draft supplies is more valuable than a claim of universal deployment. It exposes an authority boundary that ordinary “DNS is answering” monitoring can miss.

Parent and child publish different records

Traditional DNS delegation has two NS sets around the zone cut. The parent publishes a delegation NS RRset. The child publishes an apex NS RRset inside the zone. RFC 1034 asked the two zone administrators to keep the records consistent, but the protocol does not synchronize them.

RFC 2181 gives the child-side set the stronger data ranking. The child is authoritative for its apex NS RRset; the parent’s delegation set is non-authoritative referral data. A caching resolver that learns both should therefore prefer the child set for ordinary resolution.

That ranking is sensible. A child operator may need a shorter TTL than a registry permits on the parent side, allowing name-server changes to become visible faster. The child answer is also the authoritative statement about the zone’s own servers.

But credibility is not the same as delegated authority. The child cannot use the authority of its own answer to prove that the parent still delegates the zone to it. Otherwise the old operator could keep renewing the very cache record whose legitimacy is in dispute.

Revision 14 resolves the tension by treating two actions separately. First, upgrade the credibility of the child NS set. Second, periodically revalidate the delegation at the parent. A resolver needs both.

Minimal responses make the gap durable

A resolver does not necessarily learn the child-apex NS set by accident. The child is not required to include it in every answer’s Authority section. Many implementations minimize response data. Ordinary applications rarely issue explicit apex NS queries.

The draft therefore recommends an additional validation query when a resolver crosses a newly discovered zone cut. The resolver asks one of the delegated servers for the child’s apex NS set and may do so alongside the DNSKEY query already needed for a secure delegation.

Address records receive similar treatment. Glue and other additional-section A and AAAA records can be necessary to reach a server, but their credibility is lower. Where possible, the resolver explicitly re-queries those names and replaces non-authoritative cached addresses with authoritative answers.

This creates a stronger route to the child. It also creates state that can outlive the referral that introduced it. Without a timer back to the parent, better child data can become a better preserved mistake.

Three clocks constrain one delegation

Revision 14 does not let one TTL stand for the whole authority chain. It requires revalidation no later than the shortest cached TTL among three records:

  1. the parent’s delegating NS RRset;
  2. the parent’s DS RRset, when one exists; and
  3. the child’s apex NS RRset.

These clocks express different powers. The parent NS TTL limits how long the resolver may rely on the current delegation. The DS TTL limits how long it may rely on the current delegated signer relationship. The child NS TTL limits how long the child’s preferred server set remains current.

Using the shortest interval prevents one participant from extending another participant’s authority. A long-lived child set cannot erase a shorter parent redelegation horizon. A long parent TTL cannot force the resolver to ignore a child’s deliberately quicker server transition.

The draft also permits a sensible minimum TTL floor. A malicious or broken zone could otherwise demand continuous revalidation with extremely short TTLs and impose computational cost. That floor is an operational defence, not evidence that the delegation remained unchanged during the extra time. The receipt should record both the protocol TTLs and the resolver’s applied floor.

Continuity is an overlap test, not a familiar name

At the revalidation point, the resolver returns to the parent and asks whether the supporting delegation still exists. Revision 14 defines continuity with concrete comparisons.

The response must still be a referral to the same revalidation point. The new parent-side NS set must overlap the cached parent referral by at least one name-server name. If DS information was present before and after, the sets must overlap by at least one delegated signer.

If the response is no longer a referral, refers to a different zone cut, contains a wholly novel NS set or contains a wholly novel DS set, the hierarchy or authority has changed. Moving between an empty and a non-empty DS set also counts as an authority change.

The rule deliberately avoids assuming that every legitimate transition changes all records at once. Some overlap permits staged migration. It also avoids treating one familiar server as proof of total equivalence. The outcome is only “this supporting authority chain remains continuous enough to retain the cache”, not “every server, key, address and answer is identical”.

This distinction matters during outsourcing, emergency transfer and DNSSEC rollover. An organisation may preserve one server while replacing the rest. It may change signer sets independently of hostnames. The resolver’s continuity rule is a cache-safety decision, not a corporate or contractual judgment about who owns the domain.

Changed authority invalidates descendants

When the parent comparison shows a changed hierarchy or authority, the draft says cached data at or below that revalidation point must not be used. The cache may garbage-collect it immediately, mark a generation obsolete or use another internal design. Externally, it has to behave as though the data was removed.

That requirement makes the impact broader than the NS RRset itself. A stale delegation can support cached host addresses, mail routing, service discovery, negative answers and deeper delegations. Keeping descendants while discarding only the parent pointer would leave conclusions whose supporting authority has disappeared.

Top-down revalidation follows from the same logic. If a higher zone cut changes, spending work to revalidate every lower cut first is wasteful. The resolver needs a demonstrably current chain from the root to the owner name.

RFC 8020 shows how one cached conclusion about non-existence can cover names below a point. Delegation revalidation has the inverse evidentiary concern: when an upper authority relation changes, downstream cached conclusions lose their old support even if their bytes have not expired independently.

Strict verification can become a hard failure

Revision 14 distinguishes strict from opportunistic credibility upgrading. In strict mode, the resolver can delay the triggering answer until it verifies that the answer came from a server with an authoritatively acquired name and address. Where the infrastructure data is signed and validation succeeds, that closes an important redirection path.

Strictness has an availability price. A broken child NS set or an authoritative server that mishandles explicit apex NS queries can make validation fail. Without fallback to lower-ranked referral data, the resolver can no longer reach the child. The draft therefore recommends strict upgrading only for the root and zones delegated directly from it.

Opportunistic mode makes a different trade. The resolver may answer the triggering query before the validation query completes. It may fall back to parent referral information. If a child incorrectly fails the explicit NS query, the resolver should abandon the algorithm for that zone and rely on the parent referral.

An operator must not report these modes under one green label. “Revalidation enabled” could mean the answer was held until infrastructure proof completed, or merely that a background query may improve later cache state. The latency, forgery resistance and failure behavior differ.

DNSSEC does not sign the whole route to authority

DNSSEC authenticates important records, but it does not automatically sign every infrastructure input used during delegation traversal. Referral NS sets and glue are not generally signed. Additional-section A and AAAA records can also arrive without signatures.

An attacker who changes one of those addresses may steer a resolver toward a rogue name server. That server can observe queries and manipulate unsigned referral material lower in the tree. RFC 5452 reduces forged-answer success with stronger transaction matching and entropy. Revision 14 addresses a different layer: whether the resolver establishes the credibility and continuing parent support of the infrastructure it follows.

Strict revalidation with signed infrastructure data can resist on-path manipulation that transaction entropy alone does not defeat. But a valid DNSSEC signature still answers a bounded question. It can authenticate a record under a chain of trust. It does not prove that the cached delegation comparison ran at the required time, that the resolver used the result, that all descendants were invalidated, or that the application reached the intended service.

An error code is evidence, not recovery

The draft asks IANA for an Extended DNS Error code for a referral NS RRset mismatch. RFC 8914 lets a resolver attach richer diagnostic information to a response. Such a signal can tell an operator why the resolver rejected or distrusted a path.

The code does not repair the delegation. It does not decide whether the parent or child is operationally correct. It does not prove that caches elsewhere observed the same transition. It does not show that the new servers contain the intended zone or that applications recovered.

A useful incident record links the EDE to the exact parent answer, cached comparison set, resolver version, mode, timer, invalidation action and subsequent resolution path. Without those attachments, the code is a symptom label detached from the authority decision that produced it.

The implementation appendix is not a deployment census

Revision 14 records running-code evidence. It says Unbound has long supported opportunistic referral-path revalidation under harden-referral-path, disabled by default, and that Section 7 revalidation has existed since Unbound 1.4.17. It says Knot Resolver revalidates its priming response. It also says strict mode is not known to be implemented beyond author prototypes and tools.

Those statements show that parts of the design have implementation history. They do not establish current defaults across distributions, configured behavior on a particular resolver, successful validation rates, the prevalence of broken child NS responses or the operational cost of cache invalidation.

Running code is primary evidence only when the running instance is observed. A release note or implementation appendix is evidence about capability. Configuration, live counters, traces and cache transitions are evidence about operation.

The receipt a resolver operator should keep

A defensible delegation-revalidation record contains at least these layers:

  1. the resolver build, active configuration and strict or opportunistic mode;
  2. the original parent referral, including NS, DS, glue and receipt time;
  3. the child-apex NS answer and authoritatively acquired server addresses;
  4. the individual TTLs and any local minimum floor;
  5. the revalidation point and full supporting chain from the root;
  6. the fresh parent response and the exact NS and DS overlap result;
  7. any hierarchy, empty/non-empty DS or wholly novel-set transition;
  8. the cache generation invalidated at and below the changed point;
  9. fallback, hard failure or EDE emitted to the client;
  10. the new server selected and the answer obtained; and
  11. an independent application or service observation after the change.

That sequence does not make DNS perfectly synchronous. It makes the uncertainty attributable. An old child may still answer. A resolver may still hold its packets. The organisation can nevertheless show why those bytes no longer count as current delegated authority.

Sources