The phrase “DNS propagation” describes the delay between changing a DNS record and every resolver on the internet returning the new value. The 24- to 48-hour figure everyone quotes is a myth — or more accurately, a self-inflicted wound caused by unnecessarily high TTLs.
Understand the moving parts and you can make DNS changes with millisecond confidence.
What “Propagation” Actually Is
DNS doesn’t push. Every DNS answer originates at your authoritative nameserver and travels to a resolver only when the resolver asks for it. Resolvers cache answers for the TTL advertised in the record.
The apparent “propagation delay” = the time a resolver holds a stale cached copy of the old record before its TTL expires and it fetches the new one.
- Old record TTL was
86400(24 hours) → some resolvers hold the old record for up to 24 hours - Old record TTL was
300(5 min) → max delay is 5 min - Old record TTL was
60(1 min) → max delay is 1 min
The record itself doesn’t propagate. Each resolver individually decides when to refresh.
The TTL Pre-Change Ritual
The pattern for zero-downtime DNS changes:
24-48 hours before the change:
- Lower the TTL on the record you’re going to change to 60 or 300 seconds
- Wait 24 hours (letting the OLD high TTL expire globally)
At the change:
- Update the record to its new value
- Because TTL is now 60/300, the world sees the new value within 1-5 minutes
After the change is stable:
- Raise the TTL back to 3600 or higher to reduce query load on your nameservers
Skip step 1 and you’re at the mercy of whatever TTL was originally set.
Why 24 Hours Is Still a Common Number
Because a lot of registrar UIs default new records to TTL=86400. And a lot of documentation says “wait 24 hours” — because that’s the safe conservative answer for any TTL up to 86400.
If you set TTLs to 300 by default, “propagation” takes 5 minutes. That’s the same DNS, same protocol, same infrastructure. Just a better TTL.
Additional Sources of Delay
Beyond TTL, three other caches can hold stale data:
Your OS’s DNS cache
- macOS —
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Windows —
ipconfig /flushdns - Linux (systemd-resolved) —
sudo systemd-resolve --flush-caches - Linux (nscd) —
sudo systemctl restart nscd
Your browser’s DNS cache
- Chrome —
chrome://net-internals/#dns→ Clear host cache - Firefox — restarts clear it
CDN and reverse-proxy edge caches
If you’re behind Cloudflare / Fastly / Akamai, they cache DNS resolutions from your origin — a purge may be needed to accelerate origin-directed changes.
Testing Propagation
Query resolvers on different continents and compare answers. Discrepancy = propagation still in progress.
Common public resolvers to test:
| Resolver | Location |
|---|---|
8.8.8.8 | Google, US |
1.1.1.1 | Cloudflare, global anycast |
9.9.9.9 | Quad9, US |
208.67.222.222 | OpenDNS, US |
77.88.8.8 | Yandex, Russia |
114.114.114.114 | 114 DNS, China |
208.67.220.220 | OpenDNS backup |
DomainScan’s DNS propagation checker queries 40+ resolvers across every continent in a single request and shows the answer per resolver. Any disagreement means propagation is still landing.
Cloudflare Proxy and Propagation
If you’re using Cloudflare with proxy (orange cloud) enabled, resolvers see Cloudflare’s edge IPs — not your origin.
- Changing the origin IP (behind the proxy) — no DNS propagation required. Cloudflare updates internally within seconds.
- Toggling the proxy (orange ↔ grey) — full DNS propagation applies.
- Adding a new subdomain via proxy — DNS propagation applies for the new record.
Read the dangling CNAME glossary entry if you’re also thinking about subdomain safety.
The Zone-Transfer Case (Secondaries)
If you run your own authoritative DNS with primary + secondary nameservers, the secondaries pull the zone from the primary based on the SOA record’s refresh timer. Set that timer low (300-3600) so secondaries pick up zone changes quickly.
What About Google’s DNS Cache?
Google (8.8.8.8, 8.8.4.4) publishes a Cache Flush tool — enter a name, they flush their cached entry. Cloudflare’s 1.1.1.1 has a similar interface. Use these if you must accelerate propagation on the world’s two most-used resolvers.
Tools
- DNS propagation checker — global multi-resolver comparison
- DNS query tool — full record type inspection
- TTL glossary entry — the underlying knob
Related
Check the TTL glossary entry, the nameserver entry, and read about every major DNS record type.
Common Questions
Why does DNS propagation take 24 hours?
It doesn't — that's a myth born from lazy TTL choices. DNS 'propagation delay' equals the highest TTL set on the old record, unless a resolver flushes early. If your old A record's TTL was 86400 (24 hours), some resolvers may cache it for up to 24 hours. If TTL was 300, the maximum delay is 5 minutes. Change your TTL to 60-300 seconds a day before making a change, and 'propagation' happens in a minute.
How do I check DNS propagation globally?
Query multiple resolvers on different continents (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, OpenDNS 208.67.222.222) plus geographically distributed ones (in Europe, Asia, South America). Tools automate this — our DNS propagation checker queries 40+ resolvers worldwide in one click. Compare the returned values; any discrepancy means propagation hasn't completed.
Can I force DNS propagation to be faster?
You can't force resolvers you don't control to flush their cache. What you CAN do: (1) lower the TTL 24 hours before the change so caches expire quickly, (2) flush the cache on YOUR resolver (dscacheutil on macOS, ipconfig /flushdns on Windows), (3) test using resolvers whose TTLs you know are respected. There's no 'flush the world' button.
Why does dig show a different answer than my browser?
Almost always: your operating system or browser has its own DNS cache separate from the resolver you told dig to query. dig queries the resolver directly, bypassing local caches. To match: flush your OS DNS cache (macOS: sudo dscacheutil -flushcache, Windows: ipconfig /flushdns, Linux: systemd-resolve --flush-caches or restart nscd), then check again in the browser.
Does Cloudflare's proxy affect DNS propagation?
Slightly. When you enable proxy on a Cloudflare-managed record, the A/AAAA records that resolvers see point to Cloudflare's edge — not your origin. Changes to the underlying origin don't require DNS propagation because the resolver-facing A record hasn't changed. Changes that affect what Cloudflare's edge does (enabling/disabling proxy, changing hostname) do require propagation of the modified DNS record.