Why DNS Changes Don’t Happen Instantly: TTL and Propagation Explained
"DNS changes take 24 to 48 hours to propagate" is one of the most repeated pieces of hosting folk wisdom, and while it's not wrong exactly, it's also not a precise, technically accurate description of what's actually happening — understanding the real mechanism (caching governed by TTL values) explains why some changes are visible within minutes while others genuinely do take the better part of two days.
There's No Central "Propagation" Process at All
The word "propagation" suggests something is actively being pushed or broadcast outward across the internet after a DNS change, but this isn't really how it works. The authoritative nameserver for your domain updates its own record immediately, the moment you make a change — there's no delay on that end at all. What actually takes time is every other DNS resolver around the world, that had previously looked up and cached your domain's old record, eventually noticing the change by asking again, rather than the change itself spreading outward like a broadcast.
What TTL Actually Controls
Every DNS record carries a Time To Live (TTL) value, specified in seconds, which tells any resolver that looks it up exactly how long it's allowed to keep using that cached answer before it's required to check again with the authoritative nameserver. A record with a TTL of 3600 (one hour) means a resolver that already has that record cached will keep serving the old value for up to a full hour after you've actually changed it, simply because it hasn't been told to check again yet — it has no way of knowing the record changed until its own cache expires and it goes back to ask.
Why Different Visitors See the Change at Wildly Different Times
Because every DNS resolver — your ISP's resolver, a corporate network's internal resolver, a public resolver like Google's 8.8.8.8, and countless others — caches independently based on when it last happened to look up your specific domain, different visitors genuinely can see completely different answers to "where does this domain point" simultaneously, depending purely on the timing of when their particular resolver's cache happens to expire relative to when you made the change. Someone whose resolver checked five minutes before your change sees the old value for nearly the full TTL duration; someone whose resolver happened to check five minutes after your change sees the new value almost immediately.
Where the 24-48 Hour Estimate Actually Comes From
The commonly cited 24-48 hour figure is really just a conservative, worst-case buffer accounting for a few compounding factors: some older or more conservatively configured resolvers cache records for longer than their nominal TTL as an extra safety margin, some ISPs run resolvers with unusually long default cache retention regardless of what TTL a record specifies, and registrar-level changes (like updating nameservers themselves, discussed in the piece on nameservers elsewhere on this blog) involve an additional layer of caching at the registry level beyond the record-level TTL alone. In practice, for a record with a genuinely short TTL and no unusually aggressive resolver caching involved, changes are very often visible to the large majority of resolvers within minutes to a few hours, not the full worst-case window.
Why Planning Ahead Matters More Than Waiting Afterward
The single most effective way to minimize disruption from a planned DNS change — a hosting migration, a mail provider switch — isn't waiting patiently after the change; it's proactively lowering the record's TTL well in advance, ideally a day or more before the actual change, so that by the time the change happens, every resolver's cached copy has already expired on its own and will pick up the new value almost immediately upon the very next lookup, rather than needing to wait out whatever the previous, potentially much longer TTL had been set to.
Why You Shouldn't Run Permanently Ultra-Low TTLs
It might seem like keeping every TTL set to the minimum possible value at all times would eliminate this problem entirely — but as discussed in more depth in the piece on DNS zone files elsewhere on this blog, an unnecessarily low TTL means resolvers worldwide are re-querying your nameservers far more frequently than necessary during normal, stable operation, adding real, avoidable load and marginally increasing average lookup latency for visitors. The generally recommended practice is a moderate, sensible default TTL for day-to-day operation, temporarily lowered only in the specific window surrounding a planned, anticipated change.
How to Actually Verify Where Things Stand
Free tools like whatsmydns.net query a domain's current DNS answer from dozens of resolver locations distributed around the world simultaneously, providing a genuinely useful, concrete snapshot of how far a given change has actually propagated at a specific moment, rather than relying purely on the generic 24-48 hour guideline or on checking only from your own single location and internet connection.
The Takeaway
DNS "propagation" delay is really just distributed caching working exactly as designed — every resolver honoring the TTL value it was given, checked independently and asynchronously rather than through any centralized broadcast mechanism. Understanding this explains both why the same change can appear at wildly different times for different visitors, and why proactively lowering TTL in advance of a planned change is a genuinely effective mitigation, while passively waiting out a long-cached TTL after the fact is not.
Tags: DNS caching, DNS propagation, TTL