Introduction
You’ve just changed a DNS record. You saved it, confirmed it, and you’re feeling good. Then you open your browser, type in the domain, and… nothing has changed. The old site is still there. Or worse, the site doesn’t load at all.
This is the most common DNS frustration, and it has a name: propagation. But “propagation” is a misleading word. It sounds like your DNS change is slowly traveling across the internet, hopping from server to server like a message in a bottle. That’s not what’s happening.
What’s actually happening is much simpler: caching. DNS servers around the world have memorized the old answer and won’t ask for a new one until their cache expires. Your change is already live at the source, but the rest of the internet has not checked yet.
By the end of this tutorial, you’ll know how to prove whether your DNS change actually took effect, which caches are between you and the answer, and when flushing your local cache helps (and when it doesn’t).
Step 1 — Prove the Change Is Live
Before flushing anything, troubleshooting anything, or panicking about anything, answer one question: did the change actually save at the authoritative level?
Your authoritative nameservers are the official source for your domain’s DNS records. Everything else, including your ISP, Google, Cloudflare, and your router, is a copy. If the authoritative server shows the new value, the change worked and everything else is just catching up. If the authoritative server still shows the old value, no amount of cache flushing will help.
Check the authoritative answer
Query your authoritative nameserver directly, using the technique from Part 4:
dig NS yourdomain.com +short
dig @ns1.servetheworld.net A yourdomain.comIf the answer section shows your new value, the change is live. The “propagation” you’re waiting for is just cache expiration across the rest of the internet. If it still shows the old value, the change wasn’t saved or was made at the wrong provider. Revisit Part 4 for the troubleshooting steps.
Step 2 — Understand the Caching Layers
Between your browser and the authoritative nameserver, there are multiple layers of caching. Each one stores DNS answers temporarily to reduce load and speed up repeated lookups. When you make a DNS change, each layer has to independently decide to fetch a fresh answer.
Here are the layers, from closest to you to farthest:
1. Your browser
Modern browsers maintain their own DNS cache. Chrome, Firefox, Edge, and Safari all cache DNS lookups independently of the operating system. Cache duration varies by browser, version, and settings.
2. Your operating system
Your OS keeps a DNS cache that all applications share. When any program on your computer makes a DNS query, the OS checks this cache first. If there’s a fresh-enough answer, it returns it without asking anyone else.
3. Your router
Most home routers run a small DNS cache. When your computer asks the router for a DNS answer, the router may return a cached copy instead of forwarding the question to the next level.
4. Your ISP’s resolver
This is the big one. Your Internet Service Provider (ISP) runs recursive resolvers (the servers that do the heavy lifting of tracking down DNS answers). These resolvers cache aggressively because they serve thousands (or millions) of customers. The cache duration is controlled by the TTL (Time to Live) on each DNS record.
If the record had a TTL of 86400 (24 hours) when the resolver last fetched it, that resolver will not check for updates until 24 hours have passed, regardless of how many times you refresh your browser.
The timeline
When you change a DNS record, the authoritative server updates immediately. But:
- Your ISP’s resolver won’t notice until the old TTL expires.
- Your router won’t notice until it re-queries the resolver.
- Your OS won’t notice until its cache expires or is flushed.
- Your browser won’t notice until its internal cache expires.
This is why the same change can appear to be “live” on your phone (which queries a different resolver) but “not working” on your laptop.
Step 3 — Check What Public Resolvers See
Once you’ve confirmed the authoritative answer is correct (Step 1), you can check what major public resolvers are returning. This tells you whether the change has reached the resolvers that most of the internet uses.
Query Google’s resolver (8.8.8.8)
dig @8.8.8.8 A yourdomain.comQuery Cloudflare’s resolver (1.1.1.1)
dig @1.1.1.1 A yourdomain.comQuery your ISP’s resolver (default)
dig A yourdomain.com(Without the @ flag, dig uses whatever resolver your system is configured to use. This is often your ISP’s resolver, unless custom DNS or DoH settings override it.)
Compare the results. If the authoritative server and public resolvers all show the new value, the change has propagated to the major networks. If the authoritative shows the new value but a resolver shows the old one, that resolver’s cache hasn’t expired yet. It will update when the TTL expires.
Watch the TTL count down
You can see exactly how much time is left on a cached record. The TTL value in dig output shows the remaining cache time, not the original TTL:
yourdomain.com. 1847 IN A 203.0.113.50That 1847 means the resolver will serve this cached answer for another ~31 minutes. Run the same query a few minutes later, and the number will be smaller. Once it reaches zero, the resolver fetches a fresh copy from the authoritative server.
Step 4 — When (and How) to Flush DNS
Flushing your DNS cache clears the locally stored answers so your computer is forced to look them up fresh. This can help when your change is live at the authoritative level but your local machine is still serving the old answer.
Important: Flushing only clears your local machine’s cache. It doesn’t affect your router, your ISP’s resolver, or anyone else. If the ISP resolver still has the old value cached, flushing your local DNS will just result in getting the old answer again from the resolver.
- Flush when: the authoritative server shows the new value, public resolvers (8.8.8.8, 1.1.1.1) show the new value, but your computer still shows the old one.
- Don’t bother flushing when: the authoritative server still shows the old value. Flushing won’t help because the problem is at the source, not in your cache.
Flushing DNS on Windows
Open Command Prompt as Administrator and run:
ipconfig /flushdnsYou should see: Successfully flushed the DNS Resolver Cache.
Flushing DNS on macOS
The command varies by macOS version, but on modern macOS (Ventura and later):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderFlushing DNS on Linux (systemd-resolved)
If your distribution uses systemd-resolved (common on Ubuntu, Fedora, and others):
sudo resolvectl flush-caches(On older systems, this command may be systemd-resolve --flush-caches instead.)
On distributions that don’t use systemd-resolved, DNS caching behavior varies. Some don’t cache locally at all, in which case there’s nothing to flush.
Don’t forget the browser
After flushing the OS cache, also clear your browser’s DNS cache:
- Chrome: Navigate to
chrome://net-internals/#dnsand click Clear host cache. - Firefox: Navigate to
about:networking#dnsand click Clear DNS Cache. - Edge: Navigate to
edge://net-internals/#dnsand click Clear host cache.
Or just close and reopen the browser. That clears most browser DNS caches.
Step 5 — The Pre-Change TTL Strategy
The single biggest lever you have over DNS propagation speed is the TTL strategy we covered in Part 4: lower the TTL to 300 (5 minutes) a day or two before the change, wait for the old TTL to expire, then make the actual change. Resolvers pick up the new value within minutes instead of hours.
If you skip this and change a record with a 24-hour TTL, you could be waiting up to 24 hours for the world to catch up. That’s not a bug in DNS. It is the caching system working exactly as designed. See Part 4 for the full step-by-step walkthrough.
Troubleshooting: “I Changed DNS but Nothing Happened”
Here’s a quick decision tree for the most common scenarios:
The authoritative server still shows the old value
Cause: The change wasn’t saved, or you edited the wrong provider.
Fix: Log into your DNS host (check with dig NS yourdomain.com to confirm which provider that is), verify the record, and save again. See Part 4.
Authoritative shows new value, but public resolvers show old value
Cause: Normal cache expiration. The resolvers cached the old value and the TTL hasn’t expired yet.
Fix: Wait. Check the remaining TTL with dig @8.8.8.8 A yourdomain.com. The TTL field tells you how much longer the old value will persist.
Authoritative and resolvers show new value, but your browser shows old content
Cause: Local caching. Your OS, browser, router, or even a CDN edge cache may be serving stale data.
Fix: Flush your OS DNS cache, clear your browser’s DNS cache, and try again. If your router has a DNS cache, restarting it will clear that, too. If a CDN is in front of your site, purge the CDN cache as well.
Everything shows the new IP, but the website doesn’t load
Cause: Not a DNS problem. The web server at the new IP isn’t configured to respond to your domain name.
Fix: Check your web server configuration (virtual hosts, server blocks), firewall rules, and that the application is running. DNS did its job. The rest is server-side.
The site loads on your phone but not your computer
Cause: Your phone and computer use different DNS resolvers (phone on cellular data, computer on home Wi-Fi). The resolver your phone uses has already picked up the new value; your home ISP’s resolver hasn’t.
Fix: Wait for your ISP’s resolver cache to expire, or temporarily switch your computer’s DNS to a public resolver like 8.8.8.8 or 1.1.1.1 to bypass your ISP’s cache.
Want to Preview the Site Before DNS Updates Globally?
Sometimes you can’t wait for propagation. You’ve moved a website to a new server and you need to check things like the SSL certificate, database connection, and email forms work before the rest of the world gets to see it. If something is broken, you’d rather find out now than after DNS points every visitor at the new server.
Your local computer has a small text file (the ‘hosts’ file) that overrides DNS for specific domains. When you add an entry to this file, your machine skips the normal DNS lookup and goes straight to the IP address you specify. The rest of the internet is unaffected. Your visitors still see the old server while you test the new one.
The hosts file location depends on your operating system:
- Windows:
C:\Windows\System32\drivers\etc\hosts - macOS and Linux:
/etc/hosts
You’ll need admin or root privileges to edit it. On Windows, that means running your text editor as Administrator. On macOS and Linux, open the file with sudo (e.g. sudo nano /etc/hosts). Back up the file before you touch it, so you can restore it if something goes wrong.
1. Add the override
Open the hosts file and add a line at the bottom with the new server’s IP address followed by the domain name. If you use both the root domain and the www subdomain, add both on the same line:
203.0.113.50 yourdomain.com www.yourdomain.comReplace 203.0.113.50 with the actual IP of the new server, and yourdomain.com with your real domain. Save the file.
2. Verify the override is working
Use ping to confirm your machine is reaching the new IP:
ping yourdomain.comThe response should show 203.0.113.50 (your new server IP), not the old one.
digandnslookupbypass the hosts file entirely. They query DNS servers directly. To confirm the hosts override is working, usepingor your browser.
3. Test in the browser
Open the domain in your browser and confirm the new site loads. If you still see the old site, flush the DNS cache using the same commands from the steps outlined earlier in this tutorial, then clear or restart the browser and try again. A private/incognito window can also help bypass cached data.
4. When you’re done, remove the override
Once DNS has propagated and you’ve confirmed the new server is live through normal DNS, delete the lines you added from the hosts file and save it. Or restore the backup you made earlier.
Conclusion
DNS propagation is simply caching with a countdown timer. When you change a DNS record, the authoritative server updates immediately. Everything else is resolvers around the world waiting for their cached copies to expire.
The tools for dealing with it are straightforward: check the authoritative server first (dig @ns1... A yourdomain.com), compare with public resolvers (8.8.8.8, 1.1.1.1), flush local caches when needed, and use TTL strategically to control how fast changes spread.
In Part 10, the final article in this series, we look at DNS security: DNSSEC, cache poisoning, and how to protect your domain from hijacking.
Next steps: