How Long DNS Propagation Actually Takes (and Why)

The short answer

There is no single number, but here is the honest version: for ordinary record edits — changing an A, AAAA, CNAME, MX, or TXT record inside a zone you already control — the change is visible worldwide within one TTL, which for most modern setups is 5 minutes to 1 hour. The word "propagation" is misleading: nothing is pushed anywhere. Your authoritative nameserver holds the new value the instant you save it, and a direct query to that server returns the new answer immediately. What you are actually waiting on is the expiry of cached copies that recursive resolvers around the world fetched *before* you made the change. Each of those cached copies lives exactly as long as the TTL that was attached to it, counting down independently on each resolver.

The famous "up to 48 hours" figure is real, but it applies mainly to one specific case: changing the authoritative nameservers themselves at your registrar. That change lives in the parent TLD zone (for example, the .com registry), whose delegation NS records commonly carry a TTL of 172,800 seconds — 48 hours — so resolvers can keep pointing at your old nameservers for up to that long. For everything else, the ceiling is whatever TTL you set. This is why the single most effective thing you can do is lower the TTL well before a planned change: drop it to 300 seconds, wait for the old TTL to fully expire, then make the change, and the world follows within about five minutes.

What "propagation" actually means (nothing propagates)

DNS has no push, replication, or broadcast mechanism between resolvers. When people say a change is "propagating," they are describing the passive expiry of independent caches, not any active distribution. The authoritative nameserver — the server listed in your zone's NS records — is the single source of truth, and it is updated atomically the moment you save the record. There is no in-between state on the authoritative side.

Everything downstream is a cache. When a user's recursive resolver (their ISP's resolver, or a public one like 8.8.8.8) needs your record, it asks the authoritative server, stores the answer, and serves that stored copy to every subsequent client until the TTL expires. During that window the resolver will not ask again, so it keeps handing out the old value even though the authoritative server already has the new one. The change is not "slow to arrive" — it already arrived at the source; the cache is simply refusing to look again until its timer runs out.

This is why a change can look simultaneously done and not-done. A dig query aimed directly at your authoritative nameserver returns the new value with zero delay, while the same lookup through a resolver that cached the old value five minutes before your edit keeps returning the old value for the rest of its TTL. Both are behaving exactly as designed.

• No protocol pushes DNS changes; resolvers only re-fetch when a cached record expires.
• The authoritative nameserver updates instantly and atomically the moment you save.
• A resolver serves its cached copy to every client until the TTL counts down to zero.
• Querying the authoritative server directly bypasses all caching and shows the true current state.
• "Old value here, new value there" is normal mid-change — not a sign anything is broken.

TTL: the countdown that controls everything

TTL (Time To Live) is a value in seconds attached to every DNS record. It tells a resolver the maximum time it may cache and reuse the answer before discarding it and asking again. A record of A 203.0.113.10 with TTL 3600 means: this is valid, do not ask again for one hour. Common values are 300 (5 minutes), 3600 (1 hour), 14400 (4 hours), and 86400 (24 hours).

The detail almost everyone gets wrong: the TTL countdown does not start when you make your change — it started when each resolver last fetched the record. If a resolver pulled your record with a 3600-second TTL just before you edited it, it keeps serving the old value for nearly the full hour afterward, no matter when you hit save. That is why the true worst case for any single resolver is one full TTL measured from the last fetch, and why the effective global settle time is "about one TTL" rather than instant.

TTL also governs *negative* answers. Under RFC 2308, when a resolver asks for a name that does not exist yet, it caches that "does not exist" (NXDOMAIN) response too, for a duration derived from the zone's SOA record — the minimum of the SOA MINIMUM field and the SOA's own TTL, with resolvers free to cap it lower by policy. This bites people who query a hostname *before* creating it: the NXDOMAIN gets cached, and the name looks broken for the negative-cache duration even after the record exists. Create the record first, then test — never the other way around.

• TTL is a per-record value in seconds — the maximum time a resolver may reuse a cached answer.
• Typical TTLs: 300s (5 min), 3600s (1 hr), 86400s (24 hr).
• The countdown started at the resolver's last fetch, not at your edit — worst case is one full TTL after that fetch.
• Lowering TTL only helps if you do it at least one old-TTL *before* the change.
• Negative responses (NXDOMAIN) are cached too under RFC 2308 — querying a name before it exists can make it look broken.
• TTL is a maximum, not a guarantee: resolvers may hold records shorter, and some hold them longer.

Why different resolvers show different answers

Every recursive resolver keeps its own independent cache with its own independent countdown. Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and each ISP's resolver fetched your record at different moments, so their TTL timers expire at different moments. At any instant during a change, some have re-fetched the new value and some are still serving the old one. This staggered expiry — not distance or "speed" — is why a propagation checker lights up green in some cities and stays red in others.

It gets subtler with the big public resolvers because they use anycast: 8.8.8.8 is not one machine but dozens of data centers worldwide advertising the same IP address, and each location keeps its own cache. So 8.8.8.8 in Dallas and 8.8.8.8 in Frankfurt can legitimately return different answers for the same name at the same second. Querying "8.8.8.8" from your laptop only tells you what your nearest Google node currently holds — it is not a global verdict.

There are also caches you do not control between the resolver and the user. Some ISP resolvers ignore or clamp your TTL — enforcing a minimum of an hour or more to cut their own query load — so your 300-second TTL buys nothing for those users. On top of that, the operating system's stub resolver, the browser's internal DNS cache, and the home router's forwarder each hold their own short-lived copies. A change can be fully live at every public resolver and still look stale on one laptop that has not cleared its local cache.

• Each resolver caches independently; their TTL timers expire at different times, so mixed results are expected.
• Public resolvers are anycast — 8.8.8.8 is many nodes, and different nodes can hold different answers simultaneously.
• Some ISPs override or clamp TTLs upward, so a low TTL doesn't help those users.
• OS, browser, and router caches add extra layers beyond the recursive resolver.
• A propagation checker samples many geographic resolvers; a partial result mid-change is normal, not an error.
• Querying one resolver from one location is a spot check, not a global status.

Why nameserver changes take longer than record edits

It is essential to separate two very different operations that both get called "DNS changes." The first is editing a record *inside* a zone you already host — changing an A record's IP, updating an MX target. That is governed entirely by that record's TTL, which you control, so it settles fast. The second is changing *which* nameservers are authoritative for the domain at your registrar — moving from one DNS provider to another. That is governed by the parent zone, which you do not control.

When you change nameservers, the delegation lives in the TLD registry's zone — the .com, .net, or .org servers that tell the world where to find your authoritative nameservers. Those delegation NS records commonly carry a TTL of 172,800 seconds (48 hours). Until that TTL expires on a given resolver, it keeps sending queries to your *old* nameservers. This — not ordinary record edits — is the real source of the "DNS can take up to 48 hours" advice, and you cannot shorten the parent TTL yourself; it is set by the registry.

Nameservers whose own hostnames live inside the domain they serve (for example ns1.example.com serving example.com) also require glue records — A/AAAA records stored at the parent to break the chicken-and-egg lookup — and those update as part of the same registry change. The practical consequence: a nameserver migration has an unavoidable overlap window where some resolvers reach the old provider and some reach the new one. The safe move is to make both the old and new nameservers serve identical zone data until the parent TTL has fully cycled.

• Editing a record within your zone is governed by your TTL; changing nameservers is governed by the parent TLD's TTL.
• TLD delegation NS records commonly have a 172,800-second (48-hour) TTL — which you cannot shorten.
• That 48-hour parent TTL is the true origin of the "DNS takes up to 2 days" rule of thumb.
• In-zone nameservers require glue records at the parent, updated with the same delegation change.
• During an NS migration, keep old and new nameservers serving identical data until the delegation TTL fully expires.

How to plan a change for near-zero downtime

For any planned record change, the winning technique is to lower the TTL in advance. The sequence: at least one *current* TTL before the change, edit the record's TTL down to 300 seconds (leaving the value itself unchanged); wait out that old TTL so every resolver has re-fetched the record and now knows the short TTL; then make the real change. Because caches now expire every five minutes, the new value reaches essentially everyone within about five minutes. Once you are confident it settled, raise the TTL back up to cut lookup load and improve resilience.

Lowering the TTL shrinks the *window* but does not eliminate it, so for anything where the old and new destinations are both real — a server IP migration, a mail move — keep the old target fully working during the transition. If the old IP stops answering the instant you flip the record, every client still holding the old cached value gets an outage until its TTL expires. Overlapping the two (old server keeps serving, new server already ready) turns a hard cutover into a seamless one.

Nameserver changes need the same overlap thinking, but you cannot pre-lower the parent TTL — so replicate the entire zone on the new provider *before* switching, and leave the old provider's zone identical and live for at least 48 hours after. For email, be especially careful with MX and with SPF/DKIM/DMARC TXT records: mail delivered during a mismatched window can bounce or fail authentication, so stage the receiving side and the records together and keep old MX targets accepting mail through the overlap.

• Lower TTL to ~300s at least one old-TTL *before* the change, so the short TTL is cached before you flip the value.
• After the change settles, raise TTL back to 3600–86400s for resilience and fewer lookups.
• Keep the old IP/server live during the overlap window — never kill it at the instant of the flip.
• For nameserver moves, replicate the full zone on the new provider first and leave the old live 48h+.
• For email, stage MX and SPF/DKIM/DMARC together and keep old MX targets accepting mail through the transition.
• Schedule changes for low-traffic windows so the residual cache window affects fewer users.

How to verify propagation (and avoid fooling yourself)

To know the true state, query the authoritative nameserver directly rather than whatever your machine happens to cache. `dig @ns1.yourprovider.com example.com A` asks the source and shows the current truth with no caching in the way. `dig +trace example.com` walks the delegation from the root down, revealing exactly which nameservers are answering — invaluable for confirming a nameserver change actually took effect at the parent. Comparing the authoritative answer against a public resolver's answer tells you precisely how far a change has settled.

In a normal dig answer the TTL field counts *down* on repeated queries — ask twice a minute apart and watch it drop; that decrementing number is the resolver's cache timer, and a value that jumps back to the full TTL means the cache just refreshed with new data. When your own machine seems stuck, flush the local layers: the OS stub cache, the browser's internal DNS cache, and the router if it forwards DNS. On the public side, Google and Cloudflare both publish flush pages that clear *their* cache for a specific name — helpful for the resolvers those tools represent, but useless for anyone else's.

Do not use "the website loads" as your test. Browsers reuse open connections, honor HSTS, and cache DNS internally, and a CDN in front can mask the origin entirely — so a page can look unchanged long after DNS is fully updated, or look updated because of a cache you forgot about. Trust dig/nslookup against known resolvers plus a multi-location checker for the geographic picture, and treat the browser as the last, least reliable signal.

• `dig @<authoritative-ns> name` shows the source of truth with no caching in between.
• `dig +trace name` walks root → TLD → your NS, confirming a delegation/NS change actually took effect.
• The TTL in a dig answer counts down each query; a reset to the full TTL means the cache just refreshed.
• Flush OS, browser, and router caches before concluding your own machine is "stuck."
• Google and Cloudflare offer per-name cache-flush pages — but they only clear their own resolvers.
• Don't judge by whether the site loads: browser connection reuse, HSTS, and CDNs all mask DNS state.

Frequently asked questions