Why DNS Propagation Can Take Up to 48 Hours — How TTL Works
If you've ever moved a server or changed a domain's IP, you've probably run into the question "why is this still resolving to the old server?" The DNS settings panel clearly shows the new value, yet in practice the old value can keep showing up for days. This isn't because the change is slowly "propagating" between servers — it's because countless DNS caches scattered around the world each expire at a different time. TTL is the value that decides when each of those caches expires.
1. What TTL actually does
TTL (Time To Live) is a value, in seconds, that a domain's authoritative nameserver attaches to each DNS record. It's an instruction to resolvers — your ISP's DNS server, your company network's DNS server, your OS, your browser, and every other intermediary that actually handles lookups on your behalf — telling them how long they're allowed to cache this answer. Until the TTL expires, a resolver won't ask the authoritative nameserver again; it just keeps reusing the answer it already cached.
2. "Propagation" isn't really a broadcast — it's thousands of separate expirations
People commonly say "DNS propagates worldwide," but that's not actually a process where new values get actively pushed out from somewhere. The moment you change a record, the authoritative nameserver already has the new value. The real issue is that countless resolvers scattered across the world each cached the old value at a different moment. Some resolver just cached it and has almost its full TTL left; another might be seconds away from expiring. So what we call "propagation time" is really just the time it takes for all these scattered caches to individually expire on their own timers and re-fetch the new value.
3. So where does the "up to 48 hours" figure come from?
A record with a low TTL (say, 300 seconds) should theoretically spread worldwide within minutes to a few hours. So why is "up to 48 hours" still the widely used rule-of-thumb safety margin? Because some registrars and resolvers have historically defaulted to or recommended very long TTLs (24+ hours), and some ISP or corporate-network resolvers don't always re-query exactly when a TTL expires — some follow their own periodic refresh schedule instead. In other words, 48 hours doesn't mean "this is how long it usually takes" — it's a conservative safety buffer that accounts for the small minority of slow-to-react caches.
4. The practical strategy: lower the TTL before you make the change
If you have a planned DNS change coming up — like a server migration — the standard approach is to lower the TTL days or hours ahead of time, before you actually change the value. Here's why that works:
- The moment you lower the TTL, the old (long) TTL is still in effect, so the lowered TTL value itself takes just as long to propagate as the original TTL would have.
- But once most resolvers have picked up the shorter TTL, the actual cutover — the real IP change — propagates worldwide much faster, in roughly the time of the new, shorter TTL.
Conversely, if you change the IP with no preparation while the TTL is still long, traffic can keep flowing to the old server until that original long TTL finally expires.
Frequently Asked Questions
Q. Is it always better to set TTL extremely short (like 60 seconds)?
A. It makes you more responsive to changes, but an overly short TTL means resolvers re-query the authoritative nameserver much more often, which can increase load and response latency on that nameserver. The common approach is to keep a moderately long TTL (tens of minutes to a few hours) during normal operation, and only lower it in advance when a change is planned.
Q. Why does the new value not show up in certain regions right after I change a domain?
A. Because resolvers in different regions cached the record at different times. A resolver at an ISP in one region might have just refreshed its cache, while another region's resolver might still be running on an unexpired TTL. You can see this difference directly by using a DNS lookup tool that queries from multiple locations worldwide at once.
Q. Do browsers or operating systems cache DNS on their own too?
A. Yes. There's a separate OS-level DNS cache and a separate browser-level cache, so even after a resolver's cache has already updated, your own machine can still show the old value because of these local caches. You can check by clearing your browser cache or flushing the OS DNS cache (e.g., ipconfig /flushdns).
Q. Is there a way to see what value is actually cached right now?
A. When you look up a record with a DNS lookup tool, the result includes the TTL value. Looking at the remaining TTL lets you roughly back-calculate when that resolver cached this value.