Skip to content
Webmaster Tools
DNS & domainsDNS LookupDNS propagation

DNS propagation

What DNS propagation really is (resolver caching bounded by TTL), why name server changes can take up to 48 hours, how to speed up a change, and how to check it.

What it is

"DNS propagation" is the time between changing a record and everyone seeing the new value. Nothing is actually pushed around the internet: your authoritative name servers have the new data within seconds. The delay comes from caches. Every recursive resolver (your ISP's, 8.8.8.8, 1.1.1.1, a company's internal one) that looked up the old record keeps it until its TTL runs out, then asks again.

; before the change, TTL one day
example.com.  86400  IN  A  203.0.113.10
; after: resolvers that cached the old answer keep it for up to 86400 s
example.com.  86400  IN  A  198.51.100.20

So the worst case for an ordinary record change is the old TTL, counted from the moment you changed it.

What decides how long it takes

Change What bounds the delay
Edit an existing record (A, MX, TXT…) The old record's TTL in each resolver's cache
Create a record someone already queried Negative caching: the SOA minimum / SOA TTL, whichever is lower (RFC 2308)
Create a brand-new record nobody asked for Nothing: visible right away
Change name servers at the registrar The registry's NS and glue TTLs for the delegation (often 1-2 days, e.g. 172800 s for .com) plus the resolver caching the old NS set
New domain registration The registry publishing the zone, usually minutes

Name server moves are where the folk wisdom "up to 48 hours" comes from: the delegation records in the parent zone (.com, .org) carry long TTLs you don't control. During that window, some resolvers ask the old provider and some the new one, so keep both serving the same records until it's over.

On top of resolvers, browsers, operating systems, routers and some runtimes keep their own short caches. Flushing your own (ipconfig /flushdns, sudo resolvectl flush-caches, sudo killall -HUP mDNSResponder on macOS) only fixes your own machine.

How to speed it up

  1. At least one old TTL before the change, lower the record's TTL to 300 seconds.
  2. Wait for the old TTL to expire, then make the change. Resolvers now re-ask every 5 minutes.
  3. Once it's verified, raise the TTL back (3600 or more).
  4. For a name server move, copy every record to the new provider first and keep the old one running for at least two days.
  5. Don't look up a new name before creating it, or you'll cache "doesn't exist" for the negative TTL.

Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8) both offer cache-purge pages for a single name.

How to check it

Compare the answer from many public resolvers at once in our DNS Propagation Checker, and ask the authoritative servers directly to see the truth:

dig example.com NS +short
dig @ns1.example.com example.com A +short
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
nslookup example.com 8.8.8.8

If the authoritative server shows the new value and a public resolver shows the old one with a TTL counting down, it's caching, not an error. To see which name servers the registry has on file, use our WHOIS lookup.

Common mistakes

  • Changing a record with a long TTL and then lowering the TTL: resolvers already hold the old TTL.
  • Editing records at the old DNS provider after switching name servers (or at the new one before).
  • Testing only from your own machine and its cached answer.
  • Turning off the old host the moment the record changes.