DNS Changes Not Propagating? Troubleshooting Guide
You updated a record, but nothing changed. Before you assume the worst, most stuck DNS updates come down to caching, a high TTL, or an edit that never reached the authoritative server. Here's how to find out which one it is and fix it.
Quick Answer
If a DNS change isn't propagating, first query the authoritative nameserver directly (dig @ns1.yourhost.com yourdomain.com). If the new value is there, the change worked and you're only waiting on caches to expire, up to the old TTL (often 1 to 24 hours). If the new value is missing at the authoritative server, it's a configuration problem: you edited the wrong record or zone, or your nameservers point somewhere else. Flush local caches, and use a global checker to see which regions have updated.
Step 1: Check the authoritative server first
Every troubleshooting session starts here. "Propagation" is just caches expiring around the internet. None of that matters if the change never reached your authoritative nameserver, so confirm the source of truth before anything else.
Query your authoritative nameserver directly, bypassing every cache in between:
dig NS yourdomain.com +short
# Query one of them directly for your record
dig @ns1.yourhost.com yourdomain.com A +short
If the new value shows up here, the change is live at the source. Your job now is patience and cache flushing, covered below. If it doesn't show up, stop waiting: it's a configuration error, and no amount of time will fix it. Jump to Step 4.
No terminal handy? Use DNSFly's DNS propagation checker to query the record across 21 global servers at once and see exactly where it has and hasn't updated.
Step 2: If the source is correct, it's caching
When the authoritative server has the new value but you still see the old one, a cache somewhere is holding the previous answer until its TTL expires. There are usually three layers of cache between you and the authoritative server, and each one expires on its own schedule.
| Cache layer | Where it lives | How to clear it |
|---|---|---|
| Browser cache | Your browser (Chrome keeps its own) | Restart the browser or clear its DNS cache |
| OS cache | Your computer's resolver | Flush the DNS cache |
| Resolver cache | Your ISP or public resolver (8.8.8.8, 1.1.1.1) | Wait for the TTL, or test against a different resolver |
You control the first two. The resolver cache is the one you have to wait out, and it holds for the TTL that was set before your change, not the new one.
Don't panic before the old TTL expires
If your record had a TTL of 3600 (one hour) when you made the change, resolvers that cached the old value can serve it for up to a full hour, no matter what you do now. Lowering the TTL after the change has no retroactive effect. Confirm the authoritative server is correct, then wait out the old TTL before assuming something is broken.
Step 3: The 5-minute checklist
Run through these in order. Most stuck updates are solved by the time you reach step 4.
1. Query the authoritative server
Confirm the new value exists at the source (Step 1). If it doesn't, it's a config error, not propagation.
2. Flush your local DNS cache
Clear your OS and browser cache so your own machine stops serving the old answer.
3. Test against a public resolver
Run
dig @1.1.1.1 yourdomain.com. If the new value appears here but not in your browser, the problem is local caching, not global propagation.4. Check for conflicting records
Two A records for the same host, or an A record plus a CNAME, will cause inconsistent answers. Remove the one you don't want.
5. Check a global propagation map
Use a global checker to see which regions still serve the old value. If most are updated, you're nearly done.
Step 4: When it's not propagation at all
If the authoritative server never shows your change, the record isn't propagating because it doesn't exist where the internet is looking. These are the usual culprits:
You edited the wrong zone or record
Double-check the hostname and record type. A change to @ (the root) is not the same as www, and an A record edit won't help if the host actually uses a CNAME.
Your nameservers point somewhere else
If you edit records at your registrar but your domain uses a different DNS provider's nameservers, your edits go nowhere. Confirm which nameservers are authoritative with dig NS yourdomain.com, then edit the zone there. See DNS vs nameservers if this is unclear.
A CDN or proxy is overriding the record
If your domain sits behind a proxy (like Cloudflare's orange cloud), the public A record points to the proxy, not your server. Change the origin inside the proxy dashboard, not just the DNS record.
The site loads but resolves to nothing
If the domain won't resolve anywhere, that's a different problem from a stuck update. Work through DNS not working instead.
Symptom to cause, at a glance
| Symptom | Likely cause | Fix |
|---|---|---|
| New value at the authoritative server, old value in your browser | Local cache | Flush OS and browser cache |
| Updated in some regions, not others | Resolver caches expiring at different times | Wait out the old TTL |
| New value missing everywhere, including the source | Wrong record, wrong zone, or wrong nameservers | Fix the record at the authoritative provider |
| Two different IPs coming back at random | Conflicting records | Remove the duplicate A or CNAME |
| DNS record correct, but the server still serves the old site | CDN or proxy origin unchanged | Update the origin in the proxy dashboard |
Lower the TTL before your next change
A day or two before a planned migration, drop the record's TTL to 300 seconds. Resolvers will then cache it for only 5 minutes, so your next change propagates almost immediately. Raise it back to a normal value (like 3600) once the migration is confirmed. More on this in how to speed up DNS propagation.
See exactly where your DNS has propagated
Query your record across 21 global servers at once. Instantly spot which regions have the new value and which still serve the old one, so you know whether to wait or start troubleshooting.
Launch DNS Propagation Checker