You updated your DNS records 30 minutes ago. The site doesn’t load, or it loads the old server’s content. You refresh, you wait, you @ your DNS provider on X. Almost every time, the records are correct — they just haven’t propagated to every resolver yet, or your own machine is still holding the old answer.
The single fact that explains 90% of these cases: propagation runs on the TTL (Time To Live) that was set on the record before you made the change. If the old record carried a TTL of 86400 (24 hours), some resolvers will keep handing out the old IP for up to 24 hours no matter what you do now. Lowering the TTL today only speeds up the next change.
The diagnostic rule: trust dig, not the browser. The browser layers its own cache, HSTS state, and connection reuse on top of DNS, so it lies to you about what DNS is actually returning.
TL;DR
- Run
dig yourdomain.com +short. If it returns the new IP, DNS is fine — the problem is local (cache, HSTS, CDN). - Run
dig NS yourdomain.comto confirm you edited records at the active nameservers. - Flush your OS DNS cache and Chrome’s host cache (they’re separate).
- If
dig @8.8.8.8shows new butdig @your-isp-resolvershows old, there’s nothing to fix — wait out the old TTL. ISP resolvers usually catch up within 1–24 hours.
Which bucket are you in?
Run one command, then jump to the matching cause below.
dig yourdomain.com +short returns | What it means | Go to |
|---|---|---|
| The new IP | DNS is fine; problem is local or downstream | Cause 2 (local cache), 5 (CDN), 6 (HSTS) |
| The old IP | A resolver is still caching the old record | Cause 1 (old TTL), 4 (slow resolver) |
Nothing / NXDOMAIN | Record missing or edited in the wrong zone | Cause 3 (wrong provider) |
A Cloudflare anycast IP (e.g. 104.x / 172.67.x) | Record is proxied; this is expected | Cause 5 (CDN) |
Common causes
Ordered by how often they’re the real culprit, highest first.
1. The old TTL was high (most common)
Every record has a TTL telling resolvers how long they may cache the answer. The value that matters is the one that was live at the moment you changed the record. If it was 3600 (1 hour) or 86400 (24 hours), that’s the worst-case wait.
How to spot it:
dig +nostats yourdomain.comIn the ;; ANSWER SECTION: line, the number after the name is the TTL the resolver is reporting right now. Run it twice a minute apart — if the number is counting down, that resolver is serving a cached copy and the countdown tells you how many seconds until it refetches.
2. Local OS / browser cache
Even after DNS has propagated globally, your own machine keeps serving the stale answer until its local cache TTL expires. Chrome maintains a DNS cache that is completely separate from the OS cache, so you often need to clear both.
How to spot it: dig from the terminal returns the new value, but the browser still loads the old site.
Flush the OS cache:
- macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd-resolved, the default on Ubuntu 22.04+/Fedora 33+):
sudo resolvectl flush-caches - Windows 11:
ipconfig /flushdns(run the terminal as Administrator)
Then flush Chrome (it has its own resolver cache and reuses live sockets):
- Open
chrome://net-internals/#dns→ click Clear host cache. - Open
chrome://net-internals/#sockets→ click Flush socket pools, so Chrome doesn’t reuse an existing connection to the old IP.
3. You changed records at the wrong DNS provider
You have a registrar (where you bought the domain) and possibly a separate DNS host (Cloudflare, Route 53, etc.). Only one set of nameservers is authoritative, and it’s whichever set the registrar’s NS records point to. A common failure: you edit records in the registrar’s built-in DNS panel while your nameservers actually point to Cloudflare — so your edits go nowhere.
How to spot it:
dig NS yourdomain.com +shortIf the returned nameservers (e.g. xxx.ns.cloudflare.com) don’t match the provider where you just made the change, you edited the inactive zone.
4. Some resolvers serve the old answer longer
Public resolvers — Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9 — generally honor TTL well. ISP and corporate resolvers sometimes round TTLs up or apply a minimum cache time, so they lag. There’s nothing technical to do here except wait.
How to spot it — query several resolvers directly:
dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +shortIf all three return the new value but specific users still can’t load the site, their local or ISP DNS is the holdout.
5. A CDN/proxy in front is returning a cached response
If DNS points at a CDN (Cloudflare proxied/orange-cloud, Fastly, CloudFront), visitors hit the CDN’s cache, not your origin. Correct DNS does not purge CDN cache — that’s a separate action.
How to spot it: compare a request through the CDN vs. straight to the origin IP.
curl -sI https://yourdomain.com # through the CDN
curl -sI --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com # bypass the CDNIf the CDN response is old and the origin response is new, purge the CDN cache. Note: on Cloudflare, proxied (orange-cloud) records always report a fixed Auto TTL of 300 seconds and the public answer is Cloudflare’s anycast IP, not your origin — so dig will not show your server’s real IP. That’s expected, not a bug.
6. The browser’s HSTS pinning
If the old site sent a Strict-Transport-Security header (especially with includeSubDomains and a long max-age), the browser will force HTTPS to whatever it now resolves and will refuse to bypass a cert mismatch. You’ll see NET::ERR_CERT_AUTHORITY_INVALID or Your connection is not private, with no “proceed anyway” link.
How to spot and fix it: open chrome://net-internals/#hsts, scroll to Delete domain security policies, type the domain, and click Delete. Restart Chrome. If the same domain loads fine in a different browser, HSTS state was the cause.
Shortest path to fix
Step 1: Verify with dig, not the browser
dig yourdomain.com +shortShould return the new IP or target. If it does, DNS itself is propagating fine and the problem is downstream (local cache, HSTS, or CDN). Skip straight to Steps 4–5.
Step 2: Test multiple resolvers and regions
Use dnschecker.org, which queries resolvers in dozens of locations worldwide. If most show the new value and a few still show the old, propagation is simply in progress — keep waiting, don’t keep changing records.
Step 3: Confirm you edited the active DNS provider
dig NS yourdomain.com +shortThe nameservers listed are the authoritative ones. Make your record changes there, nowhere else.
Step 4: Flush local + browser DNS
After confirming global propagation:
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Windows 11 (Administrator terminal)
ipconfig /flushdnsThen clear Chrome at chrome://net-internals/#dns (Clear host cache) and flush socket pools at chrome://net-internals/#sockets.
Step 5: Pre-lower TTL before your next change
In your DNS provider, set the record’s TTL to 300 (5 minutes) at least 24 hours before a planned change. On change day, the old cached entries expire within 5 minutes, so propagation feels near-instant. Provider notes for June 2026:
| Provider | Default/Auto TTL | Lowest manual TTL | Notes |
|---|---|---|---|
| Cloudflare (DNS only) | Auto = 300s | 60s (non-Enterprise), 30s (Enterprise) | Range is 60s–86400s; see Cloudflare’s TTL docs |
| Cloudflare (proxied) | Auto = 300s, fixed | Not editable | Public answer is Cloudflare’s anycast IP |
| AWS Route 53 | none default — you set it | 0s allowed | Common practice: 300s |
| Namecheap | Automatic (often ~1800s) | 60s | ”Automatic” hides the real number; set an explicit low value before a migration |
| GoDaddy | 1 hour (3600s) | 600s (10 min) | Lower well ahead of any migration |
Step 6: Wait out the ISP resolvers
If dig @8.8.8.8 shows the new value but a user’s ISP DNS shows the old one, there is no technical lever to pull — it’s a cache on a server you don’t control. ISP resolvers typically catch up within 1–24 hours, bounded by the old record’s TTL.
How to confirm it’s fixed
You’re done when all three of these are true:
- Authoritative answer is correct.
dig +short yourdomain.com @$(dig +short NS yourdomain.com | head -1)returns the new IP. Querying the authoritative nameserver directly bypasses every cache, so this is the source of truth. - Public resolvers agree.
dig @8.8.8.8 yourdomain.com +shortanddig @1.1.1.1 yourdomain.com +shortboth return the new IP. - Your own machine sees it. After flushing,
dig yourdomain.com +short(no@server, so it uses your configured resolver) returns the new IP, and an incognito window loads the new site. Use incognito so a service-worker or HTTP cache from the old site can’t mask the result.
If step 1 is correct but step 2 lags, you’re just waiting out propagation — nothing is broken. If step 2 is correct but step 3 lags, the holdout is your local or ISP cache.
Prevention
- Lower TTL to
300at least 24h before any planned DNS or migration change. - Always verify the authoritative nameservers with
dig NSbefore editing records. - Verify DNS state with
dig, never with the browser. - Purge CDN cache as a separate step whenever you change origin DNS.
- Write down which provider holds your authoritative zone (a one-line note in your repo README or runbook) so a teammate doesn’t edit the wrong panel during an incident.
FAQ
How long does DNS propagation really take?
It’s bounded by the TTL on the old record, not by some fixed global timer. With a TTL of 300s, most resolvers refresh within 5 minutes; with 86400s (24h), worst case is 24 hours. Public resolvers like 8.8.8.8 and 1.1.1.1 honor TTL closely; some ISP resolvers lag.
dig shows the new IP but my browser still loads the old site. Why?
Your browser cache is separate from DNS. Flush the OS cache, then clear Chrome’s host cache at chrome://net-internals/#dns and flush socket pools at chrome://net-internals/#sockets. If you get a cert error you can’t dismiss, also clear HSTS at chrome://net-internals/#hsts.
I edited my records but dig NS shows a provider I didn’t change. What happened?
You edited the wrong (inactive) zone. The provider listed by dig NS is the authoritative one. Re-make your changes in that provider’s DNS panel.
My Cloudflare record is proxied and dig shows a Cloudflare IP, not my server. Is that broken?
No. Proxied (orange-cloud) records resolve to Cloudflare’s anycast IP by design, and always report a 300-second TTL. To see your origin, set the record to DNS-only (grey-cloud) temporarily, or check the origin directly with curl --resolve.
Can I force every resolver in the world to drop the old record? No. You cannot purge caches on resolvers you don’t operate. The only control you have is the TTL you set before the change. After the change, the remaining wait is whatever the old TTL allowed.