Why DNS Propagation Is Slow and How to Check It

You change an A record or switch name servers, then refresh and groan: "Why is it still hitting the old server?" Here is the short answer: DNS changes are never instant. Some visitors see the new IP within a minute; others keep seeing the old one for 24 to 48 hours. This guide explains where that gap comes from and what to do before and after a change so the transition finishes fast.

First, clear up the biggest misconception. We call it "DNS propagation," but nothing is actually traveling across the world. What really happens is that resolvers everywhere gradually let their old cached answers expire. Once you see it that way, it becomes obvious why the wait is governed entirely by TTL.

What TTL is and how it controls caching

TTL (Time To Live) is the "shelf life" attached to every DNS record, measured in seconds. It tells a resolver how long it may keep an answer in its cache. If an A record has a TTL of 3600, then after a resolver looks it up once it will keep serving the cached value for up to one hour (3600 seconds) without asking the authoritative name server again.

• A longer TTL (e.g. 86400 = 24h) reduces lookup load and latency but slows down any change.
• A shorter TTL (e.g. 300 = 5m) lets changes spread quickly but means more lookups against the authoritative server.
• Crucially, TTL controls the lifetime of the answer that was cached before your change, not after it.

To see the current records and their TTLs, run a DNS lookup to inspect the A, CNAME, MX, and NS records along with the TTL returned in the response.

Why it is slow: the cache lives in many places

When a visitor types your domain, the answer passes through several caching layers. If any one of them is holding the old value, that visitor keeps reaching the pre-change server until that cache expires.

• OS and browser cache — even your own machine caches briefly (usually the shortest).
• ISP and public resolver caches — your carrier's DNS or a public resolver like 8.8.8.8 holds the answer for the full TTL. Most of the perceived delay happens here.
• Authoritative name server (NS) changes — changing the name servers themselves is slowest, because the NS records registered at the parent TLD typically carry a 24 to 48 hour TTL.

That is why the same change lands at different times depending on a visitor's location and carrier. You might see the new IP locally while someone elsewhere still sees the old one. To view that spread at a glance, query many regional resolvers at once with theDNS propagation checker.

Worked example: changing an A record with TTL 3600

Setup: the A record TTL is 3600 (one hour), and you change the IP from 1.1.1.1 to 2.2.2.2. Suppose one ISP resolver cached the old value (1.1.1.1) just five minutes before your change.

The takeaway is plain: anyone using that resolver keeps hitting the old server for up to one full hour after your change. Not because the data arrived late, but because they have to wait for the cache to expire.

For planned changes: lower the TTL 24 to 48 hours ahead

When you know the date in advance, such as an IP move or a server migration, you can almost eliminate the delay. The trick is not the change itself but spreading a short TTL before you make it.

1. 24 to 48 hours before: lower that record's TTL from 3600 to 300 (5 minutes).
2. Wait until the old (long) TTL has fully expired everywhere, so every resolver now knows the short TTL.
3. Make the actual change (new IP or name servers).
4. The old value now disappears within five minutes at most, so propagation finishes almost immediately.
5. Once the change is stable, raise the TTL back to 3600 or higher to reduce ongoing load.

Before a migration, walk through the DNS change checklist so you do not miss any records, and afterward verify with theDNS propagation checker that every region now resolves to the new value.