You changed your nameservers or updated an A record an hour ago, and your site (or your neighbor's laptop, or your phone on mobile data) still shows the old page. Nothing you did was wrong — this is DNS propagation, and it trips up almost everyone the first time they touch a domain's DNS. Here's what's actually happening behind the scenes, how long it really takes, and how to check it properly instead of just refreshing the browser forty times.
Symptom
You'll usually notice one of these after a DNS change:
- Your site loads the old host's page for you, but a friend on a different network sees the new one (or vice versa)
- You updated an A record to point at a new server, but visiting the domain still hits the old IP
- Email suddenly stops arriving after an MX record change, then comes back a day later on its own
- A DNS checker tool shows different answers depending on which location you test from
- Your browser shows the new site, but curl from a VPS somewhere else still returns the old one
None of this means the change failed. It means different parts of the internet haven't caught up with your zone file yet.
What "Propagation" Actually Means
DNS isn't one central database you update and everyone instantly reads. It's a caching system, deliberately, for speed. When you update a record at your DNS provider (SkyServer's DNS zone editor, Cloudflare, your registrar, wherever), that change lands immediately on the authoritative nameservers for your domain. But almost nobody queries the authoritative nameservers directly for every page load — that would be slow and would hammer those servers with traffic.
Instead, resolvers everywhere — your ISP, your phone carrier, Google's 8.8.8.8, your office router, your operating system, even your browser — cache the answer for a period of time called the TTL (Time To Live). TTL is a number, in seconds, that you (or the previous owner of the zone) set on each record. A resolver that already has your old A record cached with a TTL of 3600 will keep serving that old answer for up to an hour, even though the authoritative server already has the new one.
"Propagation" is really just this: the old cached answer expiring at every resolver around the world, one by one, at whatever pace their individual TTLs allow.
Why It Takes Different Amounts of Time for Different People
This is the part that confuses people most — why does your coworker see the new site instantly while you're stuck on the old one for hours? A few layers are at play, each with its own cache:
| Layer | What It Caches | Typical Delay |
|---|---|---|
| Authoritative nameservers | Your actual record change | Instant to a few minutes |
| Recursive resolvers (ISP, 8.8.8.8, 1.1.1.1) | The record's TTL-bound answer | Until the old TTL expires (often 30 min – 24 hrs) |
| Your router / local network DNS | A shorter-lived copy of the resolver's answer | Minutes to a few hours |
| Operating system DNS cache | Recently resolved hostnames | Until OS cache clears or TTL expires |
| Browser DNS cache | Its own internal hostname cache, separate from the OS | Usually 1 – 60 minutes, browser-dependent |
| Nameserver changes at the registrar | Which nameservers are authoritative at all | 2 – 48 hours, occasionally longer |
Notice that nameserver changes (switching who's authoritative for your whole domain) behave differently from record changes (updating an A or MX record within nameservers that haven't changed). Nameserver changes are slower because the change itself has to propagate at the parent zone (the TLD registry, like .com or .in) before anyone even knows which servers to ask. A plain A record change under nameservers that already exist and haven't changed is usually much faster, bounded mostly by that record's own TTL.
How to Actually Check Propagation (Properly)
Don't just keep refreshing your browser — it's checking its own cache, not the real DNS state. Use tools that bypass local caching:
- dig (Linux/Mac, or WSL on Windows) — query a specific resolver directly:
Thedig example.com A @8.8.8.8 dig example.com NS @1.1.1.1@8.8.8.8tells dig to ask Google's resolver instead of your default one, skipping your router and ISP's cache. - nslookup on Windows works the same way:
nslookup example.com 8.8.8.8 - A propagation checker site (whatsmydns.net or similar) queries dozens of resolvers around the world at once and shows you a map of who has the new answer and who's still stale. This is the fastest way to see the real global picture instead of guessing from your one connection.
- Check the TTL directly so you know how long to expect the wait:
The number right before the record type (e.g.dig example.com A +noall +answer3600) is the TTL in seconds. Divide by 3600 for hours.
If dig against 8.8.8.8 already shows your new record, propagation to that resolver is done — any staleness left is downstream, in your own OS or browser cache, or on someone else's network you don't control.
How to Clear Your Own Local Cache
If everyone else sees the new site but you don't, it's almost always your own machine holding an old answer:
- Windows:
ipconfig /flushdnsin Command Prompt - Mac:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd-resolved):
sudo resolvectl flush-caches - Chrome: visit
chrome://net-internals/#dnsand click "Clear host cache" - Router: reboot it, or check its admin panel for a DNS cache clear option
Prevention: Plan the Change, Don't Just Make It
The pros in the world of DNS never make a big change and hope for the best. A little prep saves hours of "is it done yet" checking:
- Lower the TTL a day before the change. If your A record currently has a TTL of 86400 (24 hours), drop it to 300 (5 minutes) at least 24 hours in advance. Once the old TTL has expired everywhere with the new low value cached, resolvers will only hold the next change for 5 minutes instead of a full day.
- Make the actual change, then wait out the old TTL window before assuming something's broken. If you lowered TTL a day ahead, this window is now short.
- Raise the TTL back up afterward (once things are stable) to something like 3600 or higher — very low TTLs mean more DNS query volume and slightly slower first-time lookups for visitors.
- For nameserver changes specifically, budget up to 24–48 hours and don't decommission the old host until you've confirmed traffic has fully moved — keep the old server running as a safety net during the window.
- Never make DNS changes right before you need to leave or right before a weekend if you can help it, in case something needs a quick fix.
Common Misconceptions
A few things people assume that aren't quite right:
- "Propagation takes 24–48 hours, always." That's a safe worst-case number people quote for nameserver changes, not a fixed rule. A record change with a 5-minute TTL can be fully live everywhere in under 10 minutes.
- "If my browser shows the old site, the DNS change failed." Almost always it just means your browser or OS cached the old answer. Check with dig against an external resolver before assuming anything is broken.
- "I need to wait for propagation before testing the new server." You don't — use a hosts file entry (or curl with a custom DNS override) to test the new server directly by IP before DNS has even started propagating.
Frequently Asked Questions
Why does whatsmydns.net show green in some locations and red in others?
Each colored dot represents a different resolver, and each one caches independently based on when it last queried your domain and what TTL was set at that time. Green means that resolver already has your new answer; red means it's still serving a cached older one. This is normal mid-propagation and will even out as each resolver's cache expires.
Can I force propagation to happen faster everywhere?
Not directly — you can't reach into someone else's ISP resolver and clear its cache. What you can control is your own record's TTL (set it low before a planned change) and your own local caches. Once a resolver's TTL for the old value expires, it will fetch the new one on its next query; there's no way to push it there sooner.
My nameserver change has taken more than 48 hours. Is something wrong?
It's worth double-checking at that point. Confirm the new nameservers are actually saved at your registrar (not just at your DNS provider), and query the TLD's own servers directly, e.g. dig example.com NS @a.gtld-servers.net for a .com domain, to see whether the parent zone even has the new nameservers listed. If the registrar shows the old nameservers, propagation hasn't started at all — the record hasn't actually been submitted yet.
Does propagation affect email the same way it affects websites?
Yes, and it can be more disruptive because mail servers cache MX lookups too. During an MX record change, some senders' mail servers may deliver to the old server for a while after you've switched. If you're migrating mail hosts, keep the old mailbox active and reachable for at least the TTL window (ideally 24–48 hours) so nothing bounces or gets lost mid-transition.
Is there a difference between checking propagation with dig and just using an online checker?
Functionally they're doing the same thing — querying a resolver and reporting the answer. dig gives you full control over which resolver to ask and full detail on the response (TTL, all record types), which is better for troubleshooting. Online checkers are faster for getting a broad geographic snapshot in one view, which is more useful for a quick "how far along are we" check.
