How long does DNS propagation take? Work it out from your TTLs

DNS does not broadcast a change to every resolver. An authoritative server publishes an answer; recursive resolvers reuse earlier answers until their cache entries expire. What people call propagation is therefore several independent publication and cache-expiry clocks.

How long does DNS propagation take?#

For a record whose old TTL was 3600 seconds, allow up to one hour after the authoritative change is visible for compliant caches of that RRset to stop using the old value. The new TTL does not retroactively shorten a copy already cached with the old TTL.

For a nameserver change, query the parent zone. On September 27, 2026, this direct nonrecursive query returned a 172800-second delegation TTL for example.com:

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

example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.

That is 48 hours for this observed .com delegation, not a universal DNS propagation time. A different TLD can publish a different NS TTL, and the registrar-to-registry update must be published before that cache countdown is meaningful.

DNS propagation time is cache expiry, not a push#

RFC 1034 section 3.6 defines a resource record’s TTL as the number of seconds it can remain cached before it should be discarded. A resolver that has no cached answer can see new data immediately after the authoritative system publishes it. Another resolver that cached the old RRset just before that moment can legitimately return the old data for almost the full old TTL.

This explains why two users can get different answers without either resolver being broken. They asked caches with different histories. It also explains why repeatedly saving the same record does not make the change move faster: there is no recall message for the old cache entry.

A returned TTL from a recursive resolver is often the remaining lifetime of its cached copy. Querying it twice may show the number count down:

dig +noall +answer @1.1.1.1 www.example.com A
sleep 10
dig +noall +answer @1.1.1.1 www.example.com A

Do not infer a global completion percentage from one resolver. Private enterprise and ISP resolvers have their own cache histories. Use the DNS propagation checker to sample several public views, then use direct authoritative queries as the source of truth.

How long does a DNS record change take to propagate?#

The upper bound for a normal A, AAAA, CNAME, MX, TXT, CAA, or other RRset change is usually the old TTL measured from when the new RRset is available on all authoritative servers. If the old A RRset had TTL 86400 and you replace it with a new value carrying TTL 300, a resolver may still use its cached old answer for nearly 24 hours. It has not seen the new 300-second instruction yet.

There are two publication details to check before starting the clock:

1. The provider’s control plane may accept an edit before every authoritative edge or secondary serves it.
2. A multi-value RRset must be updated as a set. Compare all values, not just the first answer shown by a dashboard.

Query each authority directly with recursion disabled:

dig +short NS example.com
dig +norecurse +noall +answer @ns1.provider.example www.example.com A
dig +norecurse +noall +answer @ns2.provider.example www.example.com A

Require the intended values from every server. With full dig output, check for the aa flag; it shows that the server answered authoritatively. Once all authorities agree, the worst compliant preexisting cache has at most the old TTL remaining.

CNAME chains add clocks. A resolver can cache the CNAME RRset and the target’s A or AAAA RRset with different TTLs. If you change the target address but not the CNAME, the target RRset’s old TTL governs that address change. If you repoint the CNAME, both the old CNAME and any already learned target data can affect observations.

How long does a nameserver change take to propagate?#

A nameserver change replaces the child’s delegation in its parent zone. It does not invalidate NS RRsets already held by recursive resolvers. The useful sequence is:

1. The registrar accepts the requested NS set.
2. The registrar or registry publishes it in the parent zone.
3. Resolvers with no cached delegation learn the new set.
4. Resolvers with the old delegation continue using it until that NS RRset expires.
5. Answers learned from either authority can then remain for their own record TTLs.

The parent controls the delegation TTL. Lowering an apex NS record inside the child zone or lowering the website’s A TTL does not shorten the parent’s cached referral. That is why the old DNS provider must keep answering throughout the measured parent NS TTL.

Check the parent rather than the child:

# Find authoritative servers for the real TLD.
dig +short com NS

# Ask a parent server directly; use the real domain and parent.
dig +norecurse +noall +authority @a.gtld-servers.net example.com NS

During registry publication, query more than one parent authority and note when they agree. The retirement clock begins then, not when the registrar form was submitted. The DNS cutover checklist puts that timestamp in the wider migration sequence.

How long does DNS cache last for missing records?#

Resolvers also cache absence. An NXDOMAIN response says the queried name does not exist; a NODATA response says the name exists but not with the requested type. This matters when you create a hostname or add a record type that was queried before it existed.

RFC 2308 sections 3 and 5 sets the negative-cache TTL from the smaller of the zone SOA record’s own TTL and its MINIMUM field. The authoritative server returns the SOA in the authority section of the negative response, with that effective TTL.

Inspect it directly:

dig +norecurse +noall +authority \
  @ns1.provider.example never-existed.example.com A

Suppose the SOA itself has TTL 3600 and the final SOA field is 300. The negative response can be cached for 300 seconds. If those numbers are reversed, the smaller SOA TTL still wins. $TTL in a BIND file is not the negative-cache value; RFC 2308 gave the SOA minimum field this specific meaning.

Negative caching is why “I just added the missing record” may still produce NXDOMAIN for some users. The fix is to wait out the prior negative TTL from the failed lookup, while confirming the new record directly at every authority.

Why DNS propagation can look slow after the TTL#

If one client still sees an old answer after the expected TTL, identify which layer supplied it before blaming “the Internet.” Source-backed reasons include:

• Browser cache. Chromium’s host-resolution documentation describes an owned HostCache in each network context. A browser request can therefore reuse host-resolution state without repeating the command-line lookup you just ran.
• Operating-system or network cache. The same Chromium documentation explains that its system path uses the OS getaddrinfo() API, whose result can come from the system’s cache, hosts file, DNS, or mDNS. A browser and dig need not use the same path.
• Configured resolver bounds. Unbound’s official cache-min-ttl and cache-max-ttl settings let a recursive operator floor or cap cache lifetimes. Its documentation explicitly warns that a nonzero minimum can retain data longer than the domain owner intended. An ISP or enterprise running configurable resolver software may therefore not mirror your TTL exactly; do not assume a particular floor without evidence from that operator.
• Serve-stale during authority failure. RFC 8767 permits a recursive resolver to use expired data when it cannot refresh from authoritative servers. This is an exceptional resilience behavior, not normal propagation. If the new authorities are unreachable or misdelegated, an old answer can mask the failure.
• A different RRset. The apex A record, www CNAME, target A/AAAA, parent NS, DS, and a negative response each have independent TTLs. Measuring one does not clear the others.

Local cache flushing can help one test client, but it cannot flush a recursive resolver you do not operate. Compare that client with a direct authority query and an explicitly selected recursive resolver to locate the stale layer.

How to speed up DNS propagation safely#

You can shorten a planned record change, but only before old copies are cached:

1. Lower the record TTL at every current authority.
2. Wait at least the largest old TTL. If it was 14400, wait four hours after all authorities publish the lower value.
3. Make the value change.
4. Keep the low TTL while you verify.
5. Raise it after the change is stable.

The lower-TTL migration guide covers this preparation. Very low TTLs increase authoritative query load and providers may enforce minimums, so choose a supported value rather than assuming zero is useful.

You cannot shorten a parent zone’s NS TTL from the child zone. For a nameserver move, speed comes from preparation instead: copy and verify the complete zone first, keep both providers equivalent for the parent TTL, and avoid record changes during overlap. Work through the interactive DNS migration checklist and run the DNS migration checker before delegation.

Direct authoritative checks versus recursive checks#

Use each query for a different question:

# What does the new provider serve now?
dig +norecurse +noall +answer @ns1.new-provider.example www.example.com A

# What delegation does the parent publish now?
dig +norecurse +noall +authority @a.gtld-servers.net example.com NS

# What does a particular recursive resolver currently believe?
dig +noall +answer @1.1.1.1 www.example.com A
dig +noall +answer @8.8.8.8 www.example.com A

The first two bypass recursive cache state. The third and fourth intentionally observe it. If the new authority is wrong, waiting cannot make the correct record appear; fix publication. If authorities are right and recursive answers are old, use the relevant old TTL as the normal bound and continue monitoring.