DNS propagation and TTL explained

“Propagation” is really just caching

There’s no global DNS synchronization moment — every DNS record is cached independently by whichever resolver last looked it up, each on its own schedule. RFC 8499 defines TTL (time to live) as the maximum time a cached copy of a record should be treated as valid; RFC 1035 specifies TTL as a field published with every resource record. When you change a DNS record, the authoritative server (the one you or your DNS host controls) updates immediately — but every resolver that already cached the old value keeps serving it until that cached copy’s TTL runs out. “Propagation delay” is the sum of however many different resolvers are holding onto a stale cached answer and when each of their individual TTL clocks happens to expire.

example.com.  3600  IN  A  203.0.113.10

That 3600 is the TTL in seconds (one hour). Any resolver that fetches this record will serve it from cache for up to an hour before asking the authoritative server again, even if you change the record five minutes later.

Why some resolvers seem slower than others

• Different resolvers cache independently. Your ISP’s resolver, a corporate network’s resolver, a public resolver, and your phone’s mobile carrier resolver have no reason to have cached your record at the same moment, so each is on its own TTL countdown.
• Some resolvers don’t honor TTL precisely. The standard says how long a record should be cached, not a strict enforcement every resolver implementation gets exactly right — a small number of resolvers cache longer than instructed, which looks like “slow propagation” but is really a caching behavior quirk on that specific resolver.
• Local caching adds another layer. Operating systems, browsers, and some applications maintain their own short-lived DNS cache on top of whatever the configured resolver returns, independent of the resolver’s own TTL handling.
• A nameserver change is slower than a record change. Changing which servers are authoritative for your whole domain (switching registrars or DNS hosts) depends on the parent zone and every resolver picking up new NS records, which is a different and typically slower process than updating a single A, MX, or TXT record under nameservers that haven’t changed.

Realistic wait times

For an ordinary record change (A, MX, TXT, CNAME) under nameservers that aren’t changing, expect full visibility within the record’s TTL value, plus a reasonable margin for resolvers that cache slightly longer than instructed — if your TTL was 3600 seconds (1 hour), most of the internet should see the new value within a few hours. A full nameserver (registrar-level) change can reasonably take up to 24-48 hours to be visible everywhere, since it depends on additional caching layers above the record itself (the parent zone’s NS record TTLs, which are often set longer by registries).

How to plan a change with less delay

1. Lower the TTL in advance. If you know a change is coming, reduce the record’s TTL (for example to 300 seconds) at least one full old-TTL period ahead of time, so by the time you make the real change, resolvers are already re-checking frequently.
2. Make the change.
3. Check with a fresh resolver, not just your everyday network connection — use AdminKit’s DNS lookup to query the record directly, and DNS resolver test to compare results across multiple resolvers rather than trusting a single cached answer.
4. Raise the TTL back to a normal value (for most records, somewhere between 1 and 24 hours is typical) once you’ve confirmed the change is stable, since a very short TTL means more DNS query load and slightly higher latency for every lookup, with no benefit once you’re not actively changing anything.

If a change still isn’t showing up

Before assuming propagation is “stuck,” confirm the record was actually published correctly at the authoritative server — a typo or an unsaved change at your DNS host produces the same symptom (“my change isn’t showing”) as a caching delay, but needs a different fix. Query your authoritative nameservers directly (rather than a resolver that might still be caching) to rule this out, then check your TTL value against how long you’ve actually waited before concluding it’s a caching issue rather than a publishing one.