You updated an A record or CNAME at Cloudflare, GoDaddy, or Route 53. Your laptop’s dig returns the new value, a colleague in another office still can’t load the site, and an overseas friend gets the new IP one minute and the old one the next. This is not a bug. It is how DNS caching works: tens of thousands of recursive resolvers around the world each cache your record for the TTL you set, and there is no “purge everywhere” button.
Fastest fix (do this first): ask the zone’s own nameserver directly (dig +short yourdomain.com @<your-NS>) to confirm the change actually landed on authoritative, then flush your local caches so you see the new value immediately. Everyone else updates as their cached TTL expires — which, for standard A/CNAME/TXT records, is usually minutes to a couple of hours, not the 24–48 hours people quote (that figure is for nameserver changes, not record edits).
Which bucket are you in?
Run these three checks before doing anything else. They tell you whether the change landed, whether the delay is global or just local, and whether it is real propagation or GeoDNS by design.
| Check | Command | If it shows the NEW value | If it shows the OLD value |
|---|---|---|---|
| Authoritative landed? | dig +short yourdomain.com @<your-NS> | Change is live; wait for caches | Edit never saved — fix the record |
| Public resolvers agree? | dig +short yourdomain.com @8.8.8.8 and @1.1.1.1 | Propagation nearly done | Resolver-cache lag (normal) |
| Just your machine? | browser old but dig @8.8.8.8 new | Flush local + browser cache | Wait one TTL |
Common causes
Ordered by hit rate, highest first.
1. The old TTL is still counting down inside recursive resolvers
If the previous record had TTL 3600, every resolver that cached it before your change keeps returning the old value for up to 60 more minutes. Worst case is a resolver that cached the record one second before your edit and won’t expire it for another 59 minutes 59 seconds.
$ dig +short yourdomain.com @8.8.8.8
76.76.21.21 # new value (Vercel)
$ dig +short yourdomain.com @1.1.1.1
185.199.108.153 # old value (GitHub Pages) — Cloudflare's cache hasn't expiredHow to spot it: Query the same name against several public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9, and your ISP’s resolver). Divergent answers mean resolver-cache lag, which resolves itself as each cache expires.
2. Your ISP resolver ignores the TTL
Some ISP resolvers (notably in mainland China, India, and parts of Southeast Asia) override authoritative TTLs and force everything to between 1 and 24 hours to save on upstream lookups, regardless of what you set.
How to spot it: run dig +noall +answer yourdomain.com and read the TTL value returned. If it is far larger than what you configured authoritatively, the resolver is rewriting it. (Re-run the command a few seconds later — a TTL that does not count down at all is a strong sign of a static override.)
3. Multiple authoritative DNS sources are live
The registrar’s default NS records were never changed but you moved the zone to Cloudflare; or there is a legacy GoDaddy plus Cloudflare dual-host setup. Different resolvers ask different authoritative servers and get different answers, so the divergence never clears no matter how long you wait.
How to spot it:
dig +short NS yourdomain.com
# Expect a single, consistent set (e.g. all *.ns.cloudflare.com)
# A mix of vendors = multi-source; fix the NS records at the registrar4. OS, browser, or stub-resolver caches on your own machine
macOS mDNSResponder, Linux systemd-resolved / nscd / dnsmasq, and Chrome’s internal host cache each add their own caching layer. Authoritative is updated, public resolvers are updated, but your laptop still talks to the old IP.
How to spot it: a direct dig +short yourdomain.com @8.8.8.8 returns the new IP, but the browser still connects to the old one. That gap is almost always a local cache (see Step 3 to clear it).
5. CDN or load balancer does GeoDNS
Cloudflare, AWS Route 53 latency-based routing, and Vercel Anycast return different IPs by region on purpose. It looks like inconsistent propagation but it is the design, and it will never “converge” to one IP.
How to spot it: on https://dnschecker.org, if every “different” IP belongs to the same provider’s points of presence, it is GeoDNS, not lag. A quick whois <ip> on two of the divergent answers will show the same owning network.
Shortest path to fix
You cannot speed up DNS, but you can verify authoritative is correct, watch propagation, and make sure your own machine sees the new value immediately.
Step 1: Verify authoritative is actually updated
Bypass every cache by asking the zone’s own NS:
# Find the authoritative NS
dig +short NS yourdomain.com
# e.g. ns1.vercel-dns.com.
# Ask it directly — this must return the new value
dig +short yourdomain.com @ns1.vercel-dns.comIf this returns the old value, the change never landed on authoritative. Go back to the registrar or DNS dashboard and double-check. Two common slip-ups: a missing trailing dot on a CNAME FQDN, and using an outdated provider target. As of June 2026, Vercel issues a project-specific CNAME such as cname.vercel-dns-017.com rather than the generic cname.vercel-dns.com; the old generic value and the 76.76.21.21 A record still work, but copy the exact target your dashboard shows.
Step 2: Use dnschecker for a global view
Open https://dnschecker.org, enter the domain, pick the record type (A, CNAME, etc.), and read the map of green checks versus red crosses:
| % nodes updated | Meaning |
|---|---|
< 30% | Early — could be only minutes since the change |
50–80% | Normal progress, wait one more TTL |
> 80% but one region stuck | That region’s ISP resolver is holding its old TTL hard |
If most regions show the new value and only a few are stale, propagation is on track. If the split has not moved after a full TTL, re-check cause 3 (multiple authoritative sources).
Step 3: Flush every cache on your machine
# macOS (Catalina and later)
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux — systemd-resolved
sudo resolvectl flush-caches
# Linux — older systemd-resolve binary
sudo systemd-resolve --flush-caches
# Linux — nscd
sudo systemctl restart nscd
# Linux — dnsmasq
sudo killall -HUP dnsmasq
# Windows (Command Prompt or PowerShell as admin)
ipconfig /flushdnsChrome keeps its own cache, separate from the OS: open chrome://net-internals/#dns and click Clear host cache, then go to chrome://net-internals/#sockets and click Flush socket pools (Chrome can hold an open connection to the old IP even after the host cache is cleared).
Step 4: Temporarily switch off your ISP’s resolver
Point your system DNS at 1.1.1.1 or 8.8.8.8 (both respect TTLs strictly), then restart the browser:
# macOS — temporary
networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
# Revert to DHCP-provided DNS
networksetup -setdnsservers Wi-Fi emptyStep 5: Wait one full old-TTL cycle
Note the TTL of the previous record version (registrar dashboards usually keep history). Wait that long from your edit timestamp — commonly 300s, 1800s, or 3600s. If you don’t know it, assume 1 hour. After that window, almost every resolver re-fetches from authoritative.
For the next migration, lower the TTL to 300s about 24 hours ahead of the change, then raise it back after propagation completes. This drops the wait from an hour to roughly 5 minutes.
How to confirm it’s fixed
You are done when all three of these are true:
- Authoritative is correct:
dig +short yourdomain.com @<your-NS>returns only the new value. - Public resolvers agree:
dig +short yourdomain.com @8.8.8.8and@1.1.1.1both return the new value, and dnschecker.org is mostly green. - End-to-end works: after a local flush,
curl -sI https://yourdomain.comreturns the expected response (right server header, correct certificate, HTTP 200 or your intended redirect). The IP incurl -vshould match the new record.
A site can resolve correctly yet still fail TLS during the first hours of a migration; if curl shows a certificate error, that is an SSL-issuance lag, not DNS — see the SSL guide below.
Prevention
- 24 to 48 hours before a planned migration, lower the affected record’s TTL to 300s; raise it back after a day of stable propagation.
- Keep a single source of DNS truth (Terraform, OctoDNS, or one provider). Never dual-host a zone.
- Always use fully qualified CNAME targets with a trailing
.to preventfoo.example.com.example.comaccidents. - Run
dig +trace yourdomain.combefore going live to confirm there is no lame delegation in the root, TLD, and authoritative path. - Maintain a “DNS health” cron that queries the same name across 3 or more public resolvers every 5 minutes and alerts on divergence.
FAQ
How long does DNS propagation really take? For standard A, CNAME, or TXT edits, expect minutes up to your TTL (commonly an hour or less). The widely quoted “24 to 48 hours” applies to changing your domain’s nameservers, not editing records inside an existing zone.
My dig shows the new IP but the browser still loads the old site. Why?
Your browser or OS is holding a stale cache. Flush both (Step 3), including Chrome’s chrome://net-internals/#dns host cache and socket pools, then fully restart the browser.
Can I force DNS to update everywhere instantly? No. There is no global purge for recursive resolver caches. You can only flush your own machine and switch your resolver; the rest of the internet updates as each cached TTL expires.
Different regions keep showing different IPs and it never converges. Is it broken?
Probably not. If the IPs all belong to one provider (check with whois <ip>), that is GeoDNS by design. If they belong to different providers, you likely have two live authoritative sources — fix your NS records (cause 3).
Why does only my ISP still show the old value after a day?
Some ISP resolvers override your TTL and cache for up to 24 hours. Confirm with dig +noall +answer (the returned TTL won’t count down), and verify the rest of the world is correct via 1.1.1.1, 8.8.8.8, and dnschecker.org.
Related
Tags: #Hosting #Debug #Troubleshooting #DNS