What is DNS propagation and how long does it really take?
You changed a DNS record, saved it, and now you’re staring at the dashboard wondering why some people see the new IP and others see the old one. This article explains what is actually happening in the global DNS resolver fleet, why the wait exists, and how to check whether the change has reached you yet.
TL;DR
DNS propagation is the gradual, worldwide refresh of cached DNS answers after you change a record. With a short TTL (5–60 min), most resolvers see the change within an hour. With a long TTL (12–48 h), it can take up to 48 hours. You can speed it up by lowering the TTL 24–48 hours before the change.
What DNS actually does
DNS (Domain Name System) is the internet’s address book. When you type example.com into a browser, your computer asks a DNS resolver for the IP address behind that name. The resolver returns an answer, your browser connects to the IP, and the page loads. The whole thing takes milliseconds.
The catch is that DNS resolvers don’t ask the authoritative server every time. They cache the answer they got last time, and they keep using that cached answer until the record’s TTL (time to live) expires. Only then do they go back to the authoritative server for a fresh answer.
What changes when you edit a DNS record
You log in to your DNS provider, change the A record for example.com from 203.0.113.10 to 203.0.113.42, and save. The authoritative server immediately starts returning the new IP. But every resolver around the world has a cached copy of the old answer, and they won’t ask again until their cached copy expires.
So your local resolver, sitting in the corner of your office or run by your ISP, will keep handing out the old IP for up to TTL seconds. Other resolvers around the world will keep doing the same thing. As each resolver’s cache expires and they re-query, they pick up the new answer.
How long this actually takes
It depends entirely on the TTL of the record you just changed:
- TTL 300 s (5 min) — most resolvers refresh within an hour, propagation usually complete.
- TTL 3600 s (1 h) — most resolvers refresh within a few hours.
- TTL 86400 s (24 h) — full propagation can take up to 24 hours.
- TTL 172800 s (48 h) — the worst case, often seen on older or stable records.
These are worst-case numbers based on the TTL. In practice, most resolvers refresh earlier because they round down to common intervals, or because they hit a global cache like Google Public DNS or Cloudflare 1.1.1.1 that pulls from a smaller set of upstream sources.
How to check whether your change has propagated
The fastest way is to query the same record from two independent DNS-over-HTTPS resolvers and compare their answers. If both return the new IP, propagation is complete. If one returns the old IP, the other’s cache is more up to date — propagation is in progress. SiteTrace’s DNS tool does exactly this against Google DoH and Cloudflare DoH, so you can see both answers in one shot.
You can also do it manually with dig +short example.com @1.1.1.1 and dig +short example.com @8.8.8.8 if you have shell access.
How to speed it up next time
Lower the TTL 24–48 hours before your next change. If you know you’ll be moving example.com to a new server on Friday, set the TTL to 300 on Wednesday. By Friday, every resolver’s cached copy of the old TTL has expired, and they’re all asking the authoritative server directly. Make the change. The new IP becomes visible globally within an hour. Then raise the TTL back to a longer value (3600 or 86400) to reduce resolver load for everyone.
You can’t actually force propagation to happen faster than the TTL allows — that would defeat the caching system. The best you can do is plan ahead with a low TTL.
Why different DNS tools sometimes disagree
Each DNS lookup tool uses one or more upstream resolvers. If a tool uses Cloudflare, you see what Cloudflare’s cache returns. If it uses Google, you see what Google’s cache returns. If you’re running on your home network, your computer is also using your ISP’s resolver, which has its own cache. The fact that they disagree is direct evidence that propagation is still in progress: some caches have refreshed, others haven’t.
Edge cases worth knowing
Some large ISPs and corporate networks deliberately ignore the TTL and use their own longer cache lifetime. This is rare but it does happen, and it can extend propagation beyond what the TTL would suggest. The opposite also happens: some resolvers refresh before the TTL expires, so propagation can sometimes complete faster than the record’s TTL implies.
DNSSEC-signed zones have stricter caching rules, but the propagation mechanics are the same. NS record changes (moving the whole zone to a new set of authoritative servers) are usually the slowest because they often come with a long NS TTL set by the parent zone.