How DNS Propagates Across the Globe

You update an A record, refresh your browser, and still see the old server. A colleague in another city sees the new one. Someone tells you to “wait for DNS to propagate” and that it can take up to 48 hours. That phrase is so common that most people imagine DNS changes slowly rippling outward across the planet like a wave. The reality is simpler and, once you understand it, much easier to control.

This guide explains what actually happens when you change DNS, why different people see different answers at the same moment, how nameserver changes differ from ordinary record changes, and how to check and speed up the process. If you need a refresher on record types first, read our DNS records basics guide.

Propagation is really cache expiry

Nothing is “propagated” in the sense of being copied from server to server around the globe. When you edit a record at your DNS provider, the change lands on your authoritative nameservers almost immediately (most providers sync their own servers within seconds to a few minutes). From that point, the correct answer is available to anyone who asks.

The delay comes from recursive resolvers: the DNS servers run by internet providers, companies and public services such as Google Public DNS, Cloudflare 1.1.1.1 or Quad9. When a resolver looks up your domain, it stores the answer in its cache for as long as the record’s TTL (time to live) allows. Until that timer runs out, it keeps handing out the stored answer without asking your nameservers again.

So when people talk about propagation, they really mean: “How long until every resolver that cached the old answer lets it expire?” Each resolver cached your record at a different time, so each one expires at a different time. That is why results look random and patchy during a change. For a deeper look at choosing TTL values, see the role of DNS TTL settings.

The layers of caching between you and the answer

A single lookup can pass through several caches, and any one of them can hold the old value:

• Browser cache – browsers keep their own short-lived DNS cache.
• Operating system cache – Windows, macOS and many Linux setups (for example with systemd-resolved) cache answers locally.
• Router or local network – home routers and office DNS forwarders often cache too.
• Recursive resolver – your ISP’s or a public resolver, shared by many users.
• Negative cache – if someone looked up a name before it existed, the “does not exist” answer is cached according to the zone’s SOA settings.

Some resolvers also apply their own minimum or maximum TTLs, and a few are known to keep records longer than instructed. This is one reason any timeline you read should be treated as a typical range rather than a guarantee.

Record changes vs. nameserver changes

Not all DNS changes behave the same way. The key question is where the cached data lives.

Changing a record inside your zone

Editing an A, AAAA, CNAME, MX or TXT record only affects data on your own authoritative servers. The waiting time is governed by the TTL that record had before you changed it. If the old A record had a TTL of 3600 seconds, resolvers that cached it just before your edit may keep it for up to an hour.

Changing nameservers

Switching to a new DNS provider means changing the NS records at your registrar, which sends the update to the registry for your TLD (for example .com or .de). The registry then publishes the new delegation in the parent zone. Two delays stack up here:

1. The time for the registrar and registry to process and publish the change. Many registries publish within minutes, but this varies by TLD.
2. The TTL on the delegation NS records in the parent zone, which you do not control. For .com and .net this is commonly two days (172800 seconds), and other TLDs use their own values.

Resolvers may also cache the NS records served by your old provider’s servers. That is why nameserver switches are the classic “up to 48 hours” case, while a simple record change with a low TTL can be done in minutes. During a provider migration, keep identical records on both the old and the new nameservers until traffic has fully moved.

These ranges are general patterns, not promises. Resolver behaviour, registry processing and how recently each resolver queried your name all affect the real result.

How to plan a change so it is fast

Because the old TTL decides the wait, the trick is to lower it before you need to make the change:

1. Check the current TTL of the records you plan to change.
2. Lower it to something short such as 300 seconds, at least one full old-TTL period ahead (if the TTL was 86400, do this more than a day in advance).
3. Make the change once the old, long TTL has had time to expire everywhere.
4. Verify the new answers from several resolvers.
5. Raise the TTL again once everything is stable, to reduce query load and improve resilience.

For nameserver moves you cannot shorten the parent TTL, but you can avoid outages by running both providers in parallel with matching records.

Checking progress from multiple resolvers

A single test from your own laptop tells you only what your local chain of caches thinks. To get a real picture, compare several sources. With dig you can query a specific resolver by putting its address after the @ sign:

dig example.com A +short @1.1.1.1
dig example.com A +short @8.8.8.8
dig example.com A +short @9.9.9.9

To see what your own servers say, bypassing every cache, ask an authoritative nameserver directly:

dig example.com NS +short
dig example.com A @ns1.your-dns-provider.net

The TTL column in a normal dig response also tells you how many seconds remain before a resolver will refresh its cached copy, which is a handy way to estimate how much longer you have to wait. For nameserver changes, you can follow the delegation from the root with dig example.com +trace. You can also confirm which nameservers the registry currently lists using the TLDix domain WHOIS/RDAP lookup.

Online “propagation checkers” that query resolvers in many countries can be useful for a quick overview, but remember they only show a sample of resolvers at one moment.

Flushing local caches

If public resolvers already return the new answer but your machine does not, the stale copy is probably local. Common ways to clear it:

• Windows: run ipconfig /flushdns in a terminal.
• macOS: run sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder.
• Linux with systemd-resolved: run resolvectl flush-caches.
• Chrome: open chrome://net-internals/#dns and clear the host cache.
• Router: restarting it usually clears its cache.

You cannot flush your ISP’s resolver yourself. Some public resolvers, including Google and Cloudflare, offer web forms to purge a cached name, which can help when testing.

Common problems that look like slow propagation

Many “propagation” complaints turn out to be configuration mistakes. Before waiting longer, rule these out:

• Editing the wrong zone – changes made at a registrar’s DNS panel do nothing if the domain uses other nameservers.
• Typos in records – a missing dot or wrong IP address looks exactly like an old cached answer.
• DNSSEC mismatch – after a provider move, an outdated DS record at the registry can make validating resolvers fail completely.
• CDN or proxy layers – if traffic passes through a CDN, the DNS may be correct while the CDN still points to the old origin.
• Application caching – some software and long-running processes resolve a name once and keep the result until restarted.

Keeping track of domain and DNS details

DNS changes often happen alongside other events: moving hosts, renewing a domain, or replacing an SSL certificate. Knowing which nameservers a domain uses, who hosts it, and when it expires saves time when something goes wrong. TLDix lets you look up registration data and track renewal dates, and the hosting lookup helps you see where a site is currently served from, which is handy right after a migration.

The main lesson is simple: DNS changes reach the world as fast as old caches expire. Plan TTLs in advance, verify from several resolvers, and you will rarely need to wait the full 48 hours.