How to check DNS propagation (and why it can take up to 48 hours)

You updated an A record, loaded the site, and it works — but a colleague still lands on the old server. Nothing is broken. You are watching DNS propagation: the window during which resolvers around the world still hold the previous answer in cache.

Why DNS changes are not instant

DNS is a cache-everywhere system by design. When a resolver looks up your record, it keeps the answer for a number of seconds set by the record's TTL (time to live). Until that timer expires, that resolver keeps serving the cached value — it does not re-ask your nameservers. Because thousands of resolvers cached your old record at different moments, they expire at different times, which is why a change looks “half-applied” for a while.

What TTL actually controls

TTL is the maximum age of a cached answer, in seconds. A 3600 TTL means resolvers may serve the old value for up to an hour after you change it. A 300 TTL means at most five minutes. TTL does not speed up the change itself — it caps how long the old answer can linger.

How to check propagation

The reliable way is to query the record from many locations at once and compare the answers:

• Query several public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) and your ISP's resolver. If they disagree, propagation is still in progress.
• Use a global propagation checker that resolves the record from dozens of countries in one view — green everywhere means the change is fully live.
• Compare against your authoritative nameservers directly. If the authoritative answer is correct but resolvers disagree, you are simply waiting out TTL; if the authoritative answer is wrong, the change never saved.

The 48-hour myth (and the kernel of truth)

“DNS can take 24–48 hours” is mostly a relic of high default TTLs and slow registrar refresh. In practice, with a sane TTL, most A/AAAA/CNAME changes are global within minutes to a couple of hours. The genuine 24–48 hour cases are nameserver changes (delegation at the registry, governed by the parent zone's TTL) and stubborn ISP resolvers that ignore low TTLs.

How to make changes apply faster

1. Lower the TTL before you change anything. Drop it to 300 a day ahead of a planned migration; once the old high TTL has expired everywhere, your actual change propagates in minutes. Raise it back afterwards to reduce lookup load.
2. Change the record, not the nameservers, when you can. Editing an A record is fast; moving nameservers triggers the slow registry-level path.
3. Verify at the authoritative source first. Confirm the new value is correct on your own nameservers before you start worrying about resolvers.

Bottom line

Propagation is not your records being slow — it is the rest of the internet holding a cached copy until TTL expires. Lower the TTL ahead of changes, check the record across multiple global resolvers, and compare against your authoritative nameservers so you can tell “still propagating” apart from “misconfigured.”