DNS propagation is really TTL expiry — here is how long it takes

DNS does not "propagate" — there is no global push. When you change a record, nothing notifies the world's resolvers; they simply keep serving the old cached value until its TTL (time to live) expires, then fetch the new one on the next query. So the practical wait is bounded by the record's TTL plus however long ago each resolver last looked it up. A record with a 300-second TTL is current almost everywhere within a few minutes; one with an 86400-second TTL can serve stale answers for up to a day. Nameserver (NS / registrar) changes are a separate, slower case.

Why TTL is the real clock

Every record you publish carries a TTL — the number of seconds a resolver is allowed to cache it. The update reaches a given resolver only after its cached copy expires:

example.com.   300   IN   A   203.0.113.10

That 300 means "cache for five minutes." A resolver that fetched the record one minute before your change will keep serving the old IP for four more minutes; one that never had it cached gets the new value immediately. There is no way to force every resolver to drop its cache early — TTL is a ceiling on staleness, not a signal you can send.

The fix for a planned change is to lower the TTL first. Drop it to 300 (or 60) at least one full old-TTL period before the cutover, make the change, watch it settle quickly, then raise the TTL back up for normal caching efficiency.

Why nameserver changes take longer

Changing a record inside your existing zone is gated only by that record's TTL. Changing which nameservers are authoritative — repointing NS records at the registrar — is gated by the parent zone instead:

• The parent zone (the TLD, e.g. .com) publishes the NS delegation with its own TTL, often 24–48 hours.
• Registrar edits also pass through the registry's refresh cycle before the TLD nameservers serve them.

Until both clear, some resolvers reach the old nameservers and some the new ones, so answers diverge for as long as the slower of those two windows. This is why "allow up to 48 hours" is standard advice specifically for nameserver moves, even though an in-zone A-record edit is usually minutes.

Why different tools show different answers

During the window, you will see one IP from your laptop and another from a checker in a different region. That is expected, not a bug: each resolver has its own independent cache that expires on its own schedule. A "DNS propagation checker" is really just querying many resolvers at once and showing you which have refreshed. When every queried resolver agrees, the change is effectively complete.

You can inspect a record's current TTL and value directly to confirm what is actually being served and how long it will stay cached.

Look up your DNS records →

Further reading

• Can you put a CNAME on the root/apex domain?
• No MX record found: what it means and how to fix it
• CAA records explained: limiting who can issue your certificates
• RFC 1035 — Domain Names: Implementation and Specification (defines TTL and caching)
• RFC 2181 — Clarifications to the DNS Specification (TTL semantics)