You updated an A record or CNAME at Cloudflare / GoDaddy / Route 53. Your laptop dig returns the new value, a colleague in another office still can’t load the site, and an overseas friend gets new one minute and old the next. This isn’t a bug — it’s how DNS works. Tens of thousands of recursive resolvers around the world each cache records for the TTL you set, and there is no “purge everywhere” button. This article explains why regional inconsistency is the default and gives you a fix path that compresses “how long do I wait?” into something measurable.
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, your ISP’s resolver). Divergent answers = resolver-cache lag.
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 1–24 hours to save on upstream lookups, regardless of what you set.
How to spot it: dig +noall +answer yourdomain.com and read the TTL value returned. If it’s far larger than what you configured authoritatively, the resolver is rewriting it.
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’s a legacy GoDaddy + Cloudflare dual-host setup. Different resolvers ask different authoritative servers and get different answers.
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-source4. OS / browser-layer caches on your own machine
macOS mDNSResponder, Linux systemd-resolved, 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 @8.8.8.8 yourdomain.com returns the new IP, but the browser still connects to the old one — likely a local cache.
5. CDN / 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’s the design.
How to spot it: On https://dnschecker.org, if every “different” IP belongs to the same provider’s PoPs, it’s GeoDNS, not lag.
Shortest path to fix
You can’t 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 / DNS dashboard and double-check (watch for missing trailing dots on CNAME FQDNs).
Step 2: Use dnschecker for a global view
Open https://dnschecker.org, enter the domain, and read the map:
| % 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.
Step 3: Flush every cache on your machine
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Older systems
sudo systemd-resolve --flush-caches
# Windows (PowerShell as admin)
ipconfig /flushdnsChrome has its own layer: chrome://net-internals/#dns → “Clear host cache”, then #sockets → “Flush socket pools”.
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
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, assume 1 hour. After that, almost every resolver re-fetches from authoritative.
For the next migration, lower the TTL to 300s 24 hours ahead, then raise it back after propagation completes. This drops “wait” from an hour to about 5 minutes.
Prevention
- 24–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 → authoritative path. - Maintain a “DNS health” cron that queries the same name across 3+ public resolvers every 5 minutes and alerts on divergence.
Related
Tags: #Hosting #Debug #Troubleshooting #DNS