"DNS propagation" is one of the most misleading phrases in networking. Nothing actually propagates. When you change a record at your authoritative nameserver, that change is live instantly. What you are really waiting for is old answers to expire from thousands of independent caches scattered across resolvers, routers and applications around the world.
Understanding that distinction is the difference between refreshing a page for two days in frustration and knowing exactly when — and where — your change has taken effect.
What actually happens when you change a record
A DNS lookup rarely reaches your authoritative nameserver. Between the user and your zone sit recursive resolvers — your ISP's resolver, public resolvers like 1.1.1.1 and 8.8.8.8, and corporate resolvers. Each one caches the answer it receives and serves that cached copy to everyone behind it until the cache entry expires.
So when you update an A record, the authoritative server returns the new value immediately. But a resolver that fetched the old value five minutes ago will keep serving it until its cached copy times out. The length of that timeout is the record's TTL.
TTL is the only knob that matters
TTL (Time To Live) is a value, in seconds, attached to every DNS record. It tells resolvers how long they are allowed to cache the answer. A record with a TTL of 3600 can be cached for one hour; a TTL of 300 means five minutes.
example.com. 300 IN A 203.0.113.10 ; ^^^ ; TTL in seconds — cache for 5 minutes
The critical detail: the TTL that governs how long a change takes is the TTL of the record as it existed before you changed it. If your A record had a TTL of 86400 (24 hours) and a resolver cached it an hour ago, that resolver will keep serving the old value for the next 23 hours no matter what you do at the authoritative server.
The pre-migration TTL trick
This is why experienced operators lower the TTL before a planned migration:
- A day or two ahead, drop the TTL on the records you plan to change to something short, like 300 seconds.
- Wait for the old, longer TTL to fully expire so resolvers pick up the short TTL.
- Make the actual change. Now caches only hold the value for five minutes.
- Once you confirm the change is stable, raise the TTL back up to reduce lookup load.
Lowering the TTL after you have already made the change does nothing for caches that are still holding the old value under the old, long TTL. Plan ahead.
How to verify a change has gone live
Because there is no single global state, "is it done?" really means "have the resolvers I care about picked up the new value?" Check it deliberately rather than trusting one refresh:
- Query your authoritative nameserver directly to confirm the new value is actually being served at the source.
- Query several public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) to see what the wider internet is getting.
- Query from multiple geographic locations, since different regions hit different resolver caches.
- Compare the TTL in each answer — a shrinking TTL means the resolver is counting down a cached copy; a fresh full TTL means it just fetched the new value.
A DNS propagation checker automates the last three steps by querying resolvers across many regions at once and showing you which ones already return the new value and which are still serving stale data.
Realistic timing expectations
For a record whose previous TTL was 300 seconds, most resolvers converge within a few minutes. For records that had a 24-hour TTL, worst-case convergence can genuinely take a full day. Registrar-level changes such as swapping nameservers add another layer because they involve the TLD's servers and their own TTLs, which are often measured in days.
The "48 hours" figure you see everywhere is a conservative worst case, not a rule. With low TTLs set in advance, most changes are effectively global in minutes.