Summary

  • A delegation's parent and child copies can carry different TTLs. Lowering the child value does not purge a resolver that already cached the parent's longer value.
  • RFC 9199 reports research in which roughly 90% of observed resolvers were child-centric and about 10% parent-centric. Nameserver address caching also differed between in-bailiwick and out-of-bailiwick cases.
  • An old authoritative endpoint should remain operational for at least the greater of the parent and child TTLs. A defensible retirement record also preserves cache-fill times, address TTLs, resolver classes and last observations of the old endpoint.

The migration that had already succeeded

From the child zone, the change looked complete. Its NS record set named the new authoritative service; its shortened TTL had counted down; fresh queries reached the new address. The old endpoint's traffic graph was almost flat. Every visible indicator invited the same conclusion: the migration was over.

But a DNS delegation is published twice. The parent holds the NS records that lead a resolver into the child. The child serves its own NS records once the resolver arrives. Those copies are supposed to agree about names, yet their cache lifetimes need not agree. A child operator can lower the value it controls while the parent's delegation remains valid for much longer.

That creates two legitimate clocks. A recursive implementation may refresh from the child and follow the shorter horizon. Another may retain the parent's copy. RFC 9199, drawing on a measurement study by Giovane Moura, Wes Hardaker, John Heidemann and Marco Davids, reports an approximate 90/10 split in the observed population: most resolvers appeared child-centric, while a material minority appeared parent-centric.

The numbers are not a census for all time. Their operational meaning is more durable: an aggregate graph can look healthy while one resolver class still has a valid route to the old infrastructure. Turning that endpoint off converts a difference in cache policy into partial resolution failure.

Publishing a shorter number cannot recall the old one

TTL is often discussed as if it were a remote timer under the zone owner's hand. It is actually a lifetime attached to data when a cache receives it. Once a resolver has accepted a record with a long TTL, the authoritative operator has no DNS command that reaches into the cache and shortens the remaining interval.

Lowering a TTL before planned maintenance is useful, but chronology decides whether it worked. The lower value must be published before the previous, longer entry could have been filled for the last time. If a 48-hour parent TTL is still in force when the child moves to one hour, waiting one child hour does not clear the parent-side population. The new value governs future fills at the surface where it was published; it does not rewrite the past at another surface.

This is why RFC 9199 uses careful language. An operator planning an infrastructure change should keep the older infrastructure on and operational for at least the maximum of the parent and child TTLs. “At least” is an evidence boundary, not legal padding. The maximum is a planning floor. The actual retirement case still needs the last possible old-value fill, propagation at the parent, and any separately cached nameserver addresses.

Long TTLs are not simply mistakes. They reduce authoritative query load, can cut latency and metered cost, and can carry users through a short outage or attack. Short TTLs buy agility for planned moves, DNS load balancing and some redirection strategies. The unsafe move is not choosing one side of that trade-off; it is pretending that the child can make the parent's choice disappear.

A nameserver name can outlive its address—or the reverse

The NS record is only one part of the path. A resolver also needs an A or AAAA record for the nameserver. Where that address comes from changes the cache boundary.

For an in-bailiwick nameserver, the parent may need to provide glue so the delegation can be followed without a circular lookup. RFC 9199 reports that, when the NS lifetime is shorter than the corresponding address lifetime, most measured resolvers requery an in-bailiwick address when new glue is required. For an out-of-bailiwick nameserver, the address is normally resolved and cached independently; expiry of the NS record does not necessarily erase the still-valid address.

A migration ledger that says only “NS TTL: 3600” has therefore thrown away the question it needs to answer. It should identify every old and new nameserver name and address; parent and child NS TTLs; A and AAAA TTLs; whether each name is in, sibling to or outside the bailiwick; and when each old value could last have entered a cache.

RFC 2181's credibility ordering is relevant but does not create a magic overwrite. The parent is authoritative for its zone and delegation; the child is authoritative for its own zone data. A resolver can learn data through different response sections and retain it for its permitted lifetime. Calling the child answer “more current” does not remotely invalidate a parent-derived entry that the resolver is still entitled to use.

Retirement needs a receipt, not a quiet graph

A defensible change record starts before the cutover. Capture the old and new NS record sets at parent and child, every related address record, their TTLs and the moment the lowered values became authoritative. Establish the last possible fill under each old lifetime. Keep both endpoints healthy through the resulting floor.

Then measure from more than one recursive path. Record resolver implementation and version where possible, vantage, query time, answer source, remaining TTL and which endpoint ultimately received the query. The useful series is not only “first new answer.” It is “last old answer” by resolver class and address path. Missing parent access, unknown cache policy and stale-answer configuration remain uncertainties rather than being silently assigned zero.

Traffic at the old endpoint contributes to the record but cannot establish universal absence. A quiet interval may mean no sampled resolver held the old data; it cannot prove that none does. Public resolvers can be useful probes, but one provider is not a proxy for the recursive ecosystem. Aggregate success is especially dangerous here because the expected failure can be sparse, network-specific and geographically uneven.

After withdrawal, run a separate reachability receipt. Prove that the relevant resolver classes can still obtain the delegation, resolve the nameserver address and reach an authoritative endpoint. Preserve a rollback window and the operator who owns the decision. Publication of the new records was the instruction; observed non-use of the old path is the retirement evidence.

Credit and control stop at different boundaries

RFC 9199 credits Moura, Hardaker, Heidemann and Davids. It is an Independent Stream Informational RFC, not IETF consensus and not an Internet Standard. Hardaker's captured IETF profile places his contribution in a longer record of DNS research, IETF work and B-root operations. That history explains why the cache boundary deserved operational attention; it does not make him the sole author or the controller of resolver implementations.

The control map follows Heng Lu's agency principle. The parent operator controls its delegation and TTL. The child controls the copy it serves. Recursive developers and operators choose cache and bailiwick behavior within protocol constraints. The authoritative operator decides when old capacity disappears. Each can act truthfully and still produce a dangerous gap if another actor's clock is assumed away.

The early DNS specifications provide the shared machinery—delegation, caching, TTLs and record processing—without centralizing every later migration decision. That is the virtue of a minimum initial specification: future choices remain local. Running code then supplies the receipt. A packet trace, an authoritative query log and a resolver observation can establish what occurred in one deployment; a standards paragraph alone cannot.

A ledger coordinates those local decisions but does not acquire authority over them. Its job is narrower and more useful: keep the parent clock, child clock, address clocks and retirement act in the same auditable record. The old server survives not because tradition demands caution, but because some valid caches have not yet received the future.

Sources