A DNS record update does not take effect everywhere at once. For a period of time — often minutes, sometimes up to a day or two — different resolvers around the world can return different answers for the same domain, depending on which one answers a given query. This interval is known as DNS Propagation, and it is a structural consequence of how DNS works, not an error or delay in applying the change.
Why Propagation Happens: Caching at Every Layer
DNS relies on caching at nearly every layer, specifically so the system can handle global query volume without querying authoritative servers for every lookup. An ISP's resolver caches answers. Public resolvers such as Google and Cloudflare cache answers. Operating systems and browsers cache answers as well. Each of these caches retains the previous record until its TTL (time to live) expires, at which point it queries the authoritative server again and retrieves the updated value.
Why TTL Determines Propagation Time
TTL is a value, in seconds, attached to every DNS record and set by whoever manages the domain. A record with a 300-second (5-minute) TTL clears from caches quickly. A record with a 24-hour TTL may still return the previous answer a full day after the change, simply because a cache has not yet reached its expiry. For this reason, administrators typically lower a record's TTL before a planned migration — setting a low TTL a day in advance means the actual change propagates in minutes rather than hours, since every cache is already refreshing frequently by the time it takes effect.
Why 24–48 Hours Is the Commonly Cited Figure
This figure is a conservative upper bound, sized to cover the highest TTLs still in common use, plus additional margin for resolvers that do not strictly honor TTL expiry. Most changes propagate to the large majority of resolvers within a few hours, provided the previous TTL was reasonable (an hour or less). The 24–48 hour window represents the worst case; typical propagation is considerably faster.
Interpreting “Still Propagating”
When a propagation check shows disagreement between resolvers, it means some resolvers have already picked up the new record while others are still serving a cached copy of the previous one — both are correct from each resolver's own point of view; they are simply at different points in their cache lifecycle. A resolver that is unreachable during the check is a separate condition: a timeout or resolver-availability issue, not a disagreement, and should not be interpreted as a mismatch.
The Exception: Geo-Routed Domains Never Fully Agree
Everything above assumes a domain has one correct answer that every resolver eventually converges on. Large services with their own global infrastructure — Google among the most visible — break that assumption on purpose. Their authoritative nameservers don't return a fixed IP; they return whichever of their many frontend clusters is closest to the resolver asking (or to the original client, if the resolver forwards a hint of that client's location via EDNS Client Subnet). Combined with deliberately short TTLs — often under a minute, so traffic can be re-routed quickly around load or outages — a resolver in Virginia and one in Singapore can both query google.com at the same instant and correctly receive two entirely different IP addresses.
That is not propagation lag. Nothing is stale, and there is no single value for the record to converge on — every resolver is simultaneously correct, each for a different part of the world. A propagation check against a domain like this will show permanent, ongoing disagreement no matter how long you wait after a change, which looks identical to genuine unpropagated caching from a single vantage point but has a completely different cause. The practical tell: if disagreement persists well past the domain's TTL and every individual resolver still returns a currently-valid-looking answer (not an old, dead, or unreachable one), you're most likely looking at geo-routing, not a slow rollout.
Practical Guidance
- Before a planned migration, lower the record's TTL a day or more in advance — this is the most effective control over propagation speed.
- After a change, check propagation across multiple independent resolvers rather than relying on a single lookup, since a local device or ISP resolver may still have the previous answer cached.
- If resolvers still disagree well after the domain's TTL has elapsed, verify that the change was actually saved and published correctly at the authoritative nameserver — this is a more common cause of stalled propagation than DNS caching itself.
- A single unreachable resolver in a check does not indicate a propagation problem — first confirm whether the reachable resolvers agree with each other.
After confirming the record itself is correct with a DNS Lookup, use propagation checking specifically to determine how far that change has spread.
Frequently Asked Questions
How long does DNS propagation actually take?
It depends almost entirely on the record's TTL. A record with a 5-minute TTL clears from most caches within minutes. One with a 24-hour TTL can still return the old answer a full day later. The commonly cited “24–48 hours” is a conservative worst case, not a typical wait.
Why do resolvers disagree right after I made a change?
That's expected, not a fault — some resolvers have already picked up the new record while others are still serving a cached copy of the old one from before their TTL expired. Both answers are correct from each resolver's own point of view at that moment.
Why does a domain like google.com never fully agree, even long after any change?
Because there's no single answer for resolvers to converge on in the first place. Google (and other large services with their own global infrastructure) route DNS by the resolver's location — sometimes the original client's, via EDNS Client Subnet — combined with TTLs short enough to re-route traffic within seconds. A US resolver and an Asia resolver getting different, both-currently-valid IPs for the same domain at the same moment is the system working as intended, not an unfinished rollout. This is permanent for these domains, unlike ordinary propagation lag which always resolves.
One resolver in the check timed out — is that a propagation problem?
No — that's a separate condition (the resolver being unreachable or slow to respond), not a disagreement about the record's value. Check whether the resolvers that did respond agree with each other before treating a timeout as a sign of anything.
It's been well over 48 hours and resolvers still disagree — what now?
At that point caching probably isn't the cause. Confirm the change was actually saved at the authoritative nameserver with a plain DNS Lookup — a change that didn't save correctly will never propagate, no matter how long you wait.
How can I make a future DNS change propagate faster?
Lower the record's TTL a day or more before the planned change. Once every cache is already refreshing on a short interval, the actual change spreads in minutes instead of hours once you make it.
Check propagation status with the DNS Propagation Checker, which queries 8 major public resolvers directly, in parallel.