The phrase "DNS propagation" is misleading. Nothing propagates. Authoritative nameservers do not push updates outward, and recursive resolvers do not subscribe to changes. What actually happens is that every resolver holding a cached copy of the old answer keeps serving it until its countdown reaches zero, then asks again and gets the new answer. Propagation time is therefore just cache-expiry time, and cache-expiry time is set by you.
What is a TTL and where does it come from?
Every DNS record carries a TTL (time to live) in seconds. When an authoritative nameserver answers a query, it stamps the record with that TTL. The recursive resolver that received the answer — your ISP's resolver, Google Public DNS, Cloudflare 1.1.1.1, your corporate resolver — stores the answer and decrements the counter. Until the counter hits zero, every client behind that resolver gets the cached answer without the authoritative server being contacted at all.
You can read the remaining TTL directly. Query a recursive resolver twice a few seconds apart and watch the number fall:
# Ask a public resolver — the TTL shown is what remains in its cache
dig @8.8.8.8 +noall +answer example.com A
# Ask the authoritative nameserver — always the full configured TTL
dig @a.iana-servers.net +noall +answer example.com AThat difference is the whole story. If the authoritative server already returns your new value but a public resolver still returns the old one, nothing is broken — you are simply watching a cache run out. Compare several resolvers at once with DNS Compare, or check 85 resolvers with the DNS Propagation Checker.
Why do people say 24 to 48 hours?
The 48-hour figure is folklore left over from an earlier internet. It comes from three real things that have mostly stopped being true: TTLs of 86400 seconds were once the default in hand-edited zone files; some ISP resolvers historically clamped or ignored short TTLs and refreshed on their own schedule; and TLD registries once pushed zone updates in periodic batches rather than continuously.
Today most managed DNS providers default to somewhere between 300 and 3600 seconds, and the major TLD registries publish zone changes within minutes. If you lowered your TTL beforehand, a record change is usually live everywhere inside the TTL window with no surprises. Support teams still quote 48 hours because it is a safe upper bound that nobody gets fired for — not because it describes the mechanism.
Which caches actually delay a change?
| Layer | What it caches | Typical delay |
|---|---|---|
| Registry / parent zone | Your NS delegation and DS records | Minutes to publish; parent TTL (often 86400s for .com) to expire |
| Authoritative nameservers | The zone itself, across a provider anycast fleet | Seconds to a few minutes |
| Recursive resolvers | Individual records, per record type | Up to the record TTL |
| Negative cache | The fact that a name does *not* exist | Up to the SOA minimum, capped by resolver policy |
| Operating system | Resolved names, per OS stub resolver | Seconds to minutes, varies by platform |
| Browser | Its own internal DNS cache and connection pool | Usually about a minute, plus keep-alive sockets |
Two of these routinely surprise people. The first is the parent zone. Changing your nameservers at the registrar is not a change to your zone — it is a change to the delegation records published by the TLD. Those NS records have their own TTL set by the registry, not by you, and it is commonly a full day for .com. That is why a nameserver migration behaves so differently from an A record edit. Check what the parent is currently handing out with the NS Record Lookup.
How does negative caching work?
When a resolver asks for a name that does not exist, it does not get nothing — it gets an authoritative NXDOMAIN, with the zone's SOA record in the authority section. The last field of that SOA is the minimum field, and per RFC 2308 it sets how long the "this does not exist" answer may be cached. Resolvers cap it at their own maximum, but you cannot go below what you published.
# The SOA carried with an NXDOMAIN sets the negative cache lifetime
dig this-name-does-not-exist-9182734.com A
# Read your own zone's SOA — the last number is the negative TTL
dig +short example.com SOAThis is the single most common reason a *newly added* record seems slower than an *edited* one. If somebody checked the hostname before you created it, resolvers cached the non-existence, and the record stays invisible to them until that negative TTL expires — regardless of how short you set the record's own TTL. Read your zone's value with the SOA Record Lookup before you promise anyone a timeline.
What genuinely makes a change take longer?
- A high TTL you forgot to lower. The change is instant at the authoritative server and invisible to everyone whose resolver cached the old value an hour ago. Nothing can shorten this except waiting; there is no way to invalidate a third-party resolver's cache.
- A nameserver change rather than a record change. You are now waiting on registry publication plus the parent zone's NS TTL, and some resolvers keep using the old nameservers until then. If the old and new zones disagree, users get inconsistent answers during the window.
- Negative caching of a name that did not previously exist. Covered above — governed by the SOA minimum, not the record TTL.
- Editing the wrong zone. Records changed at a registrar that is not the active DNS host do nothing at all. This is not slowness, it is a no-op that looks like slowness.
- A CDN or proxy in front of the record. If traffic is proxied, the DNS answer is the proxy's address and will not change when you change the origin. The origin swap happens inside the proxy's configuration, on its own schedule.
- Local caching on the machine you are testing from. Your OS stub resolver and your browser both cache. This affects one person, not the internet, and is the least interesting cause — but it is the one most often mistaken for a global problem.
How do you plan a change so timing is predictable?
Work backwards from the TTL. Lower it well before the change — at least one full old-TTL period ahead, so that every cached copy of the long TTL has expired and been replaced by the short one. Then make the change, verify at the authoritative servers first, and only afterwards check public resolvers. The full timeline is in Lower Your TTL Before a DNS Migration.
For mail, treat the MX cutover with extra care: sending servers cache MX answers too, and a queued message can sit for days before retrying. Verify the result with the MX Lookup and, once mail is flowing to the new host, re-check authentication with the Email Deliverability Test. If something is genuinely stuck rather than merely cached, work through Why Is My DNS Not Propagating?.