Why your old DNS provider has to keep answering for two days

Your registrar can show the new nameservers while a resolver across the street still sends production queries to the old provider. Both can be correct. The registrar changes the parent delegation; it cannot invalidate NS RRsets cached elsewhere.

Why the old DNS provider must keep answering#

A resolver follows the delegation it currently knows. If that resolver cached the old nameservers just before the registry published your replacement, it can continue asking the old authority until the cached NS RRset expires. Deleting the old zone does not direct that resolver to the new provider; it leaves the resolver with unusable servers.

The complete DNS propagation timing guide owns the wider question of record, negative, local, and delegation cache duration. This post focuses on the operational consequence: both DNS providers are production during nameserver overlap.

The parent NS TTL sets the minimum overlap#

Ask a parent authoritative server, not your laptop’s recursive resolver. On September 27, 2026, this query went directly to a .com gTLD server with recursion disabled:

dig +norecurse @a.gtld-servers.net example.com NS

The relevant response was a referral in the authority section:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2

;; AUTHORITY SECTION:
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.

172800 / 60 / 60 is 48 hours. A recursive resolver that fetched the old referral one second before the registry published your change may continue using the old NS set for almost that entire TTL.

This was a live observation for example.com, not a promise for every TLD or domain. Query the actual parent for your domain. To find the parent servers first:

dig +short com NS
dig +norecurse @a.gtld-servers.net your-domain.example NS

Use one of the returned parent authorities appropriate to the real TLD. During a change, query several parent servers because registry publication itself may not appear everywhere at exactly the same instant.

NS TTL, record TTL, and publication are separate clocks#

“DNS propagation” compresses several independent events into one vague phrase. Separate them:

1. Parent delegation publication. The registrar sends an update through the registry path. The parent zone begins returning the new NS RRset.
2. Recursive delegation cache. A recursive resolver retains whichever parent NS RRset it previously fetched until that RRset’s remaining TTL reaches zero.
3. Application-answer cache. The resolver, operating system, browser, or application may also cache A, AAAA, MX, TXT, or negative answers from the authority it selected.

The timer for retiring the old provider starts only after the parent authorities publish the new delegation. Starting it when the registrar form is submitted spends part of the safety window before the change exists in DNS.

RFC 1034 defines TTL as the time an RR can remain cached before it should be discarded. It also explains that referrals carry NS records for the delegated child. A resolver normally follows its cached referral rather than asking the parent again on every application query; that is the point of DNS caching.

Lower record TTLs do not lower the parent zone TTL#

Suppose you change this application record from 3600 seconds to 300 seconds a day before cutover:

www.example.com. 300 IN A 192.0.2.44

After old 3600-second copies expire, a resolver will retain a newly fetched www answer for at most 300 seconds. That helps if you need to change the address during the move.

It does not alter this parent data:

example.com. 172800 IN NS ns1.old-provider.example.
example.com. 172800 IN NS ns2.old-provider.example.

The parent zone operator controls the delegation TTL. Editing apex NS records inside the child zone does not rewrite the parent referral. In many registry-backed TLDs you cannot choose that parent TTL at all.

DNSMigrator’s optional cutover TTL step reflects this distinction. It lowers eligible source-zone records, excluding SOA, apex NS, and records represented as provider aliases, then waits for the largest previous TTL among changed records. That prepares application answers. The later NS propagation stage is separate and governed by the delegation. The interactive DNS migration checklist keeps those gates separate.

During overlap, resolvers use different providers#

After the switch, resolver A may have no cached delegation and ask the new provider. Resolver B may hold the old NS set for another 90,000 seconds. Both can then cache different application answers.

That means the migration is not a moment when all traffic moves. It is an overlap in which both authorities are production.

Query each side directly:

dig +norecurse +noall +answer @ns1.old-provider.example example.com A
dig +norecurse +noall +answer @ns1.new-provider.example example.com A

dig +norecurse +noall +answer @ns1.old-provider.example example.com MX
dig +norecurse +noall +answer @ns1.new-provider.example example.com MX

Equivalent output might be:

example.com. 300 IN A  192.0.2.44
example.com. 300 IN MX 10 mail.example.net.

Check all authoritative servers in each set, not one convenient server. A provider can accept an update at its control plane while one edge or secondary still serves an earlier zone version.

If the old zone is deleted during this interval, resolvers with the old delegation do not magically fall through to the new provider. They have a cached list of old nameservers and will try those servers. Dead servers time out; servers that now answer non-authoritatively or REFUSED still do not teach the resolver the new delegation. The result can be slow failures or SERVFAIL for only the users behind old caches.

Freeze DNS changes or write both providers#

A long overlap creates an operational choice.

The simplest policy is a DNS change freeze: apply the destination, verify both authorities are equivalent, switch the delegation, and make no unrelated record changes until the old NS TTL has elapsed. If an emergency record change is required, write it to both providers and verify every authority.

Do not rely on serial numbers across unrelated providers. Each may manage SOA data differently. Compare the client-visible RRsets instead:

for ns in ns1.old-provider.example ns1.new-provider.example; do
  for type in A AAAA MX TXT CAA; do
    dig +norecurse +noall +answer "@$ns" example.com "$type"
  done
done

Also test representative subdomains, wildcards, service records, and negative answers. A matching apex A record is not a matching zone. Run the DNS migration checker for an external preflight view.

What a DNS propagation sample can and cannot prove#

DNSMigrator stores the old and new NS sets during cutover. After the registry switch, its propagation step samples public resolvers and records how many report the destination nameservers. The current worker advances when at least 80% of that sample matches.

That threshold answers “is the change broadly visible enough to continue the workflow?” It does not answer “has every resolver forgotten the old provider?” No finite public sample can prove the absence of a private enterprise cache that fetched the old referral just before cutover.

Use the propagation checker for observations and the nameserver cutover guide for the state machine. Use the measured parent TTL for retirement. For the live .com example above, keep the old authority correct for at least 48 hours after the new NS set is confirmed at the parent, then add whatever operational margin your rollback policy requires.

A revert has the same cache property. DNSMigrator can request the recorded old NS set again after an automatic cutover, but some resolvers may already have the new set cached. Reverting restores the parent state; it does not make the Internet switch back at once. Keeping both zones valid is what makes either direction survivable.

Safe old-provider retirement checklist#

• Record the old NS set and query it directly before the move.
• Query the parent authority and record the delegation TTL.
• Lower application-record TTLs early if the application addresses may change.
• Apply and authoritatively verify the new zone before changing delegation.
• Confirm several parent servers publish the new NS set; note that time.
• Freeze DNS changes, or apply every necessary change to both authorities.
• Monitor recursive resolvers for visibility, but do not treat a sample as cache exhaustion.
• Keep every old authoritative server online and correct for the full parent NS TTL.
• After that interval, recheck parent, old, new, web, mail, and DNSSEC behavior before cancellation.

The old provider is not a backup sitting idle during those two days. For any resolver holding the old referral, it is still the active production authority.