You updated your DNS records 30 minutes ago. The site doesn’t load, or loads the old server’s content. You refresh, you wait, you panic, you tweet at your DNS provider. The vast majority of the time the records are correct — they just haven’t propagated globally yet. Or your local OS is caching the old answer. DNS propagation runs on TTL (Time To Live) values set before you made the change: if your old TTL was 24 hours, some resolvers will keep serving the old IP for up to 24 hours regardless of what you do now.
The diagnostic key: use dig, not the browser, to see what DNS is actually saying.
Common causes
Ordered by hit rate, highest first.
1. TTL was high before the change (most common)
DNS records have a TTL specifying how long resolvers may cache the answer. If your TTL was 3600 (1 hour) or 86400 (24 hours) at the moment you changed the record, that’s how long some resolvers will keep serving the old IP.
How to spot it:
dig +nostats yourdomain.comLook at the line ;; ANSWER SECTION: — the number after the name is current TTL. To see what TTL was set, check your DNS provider’s history (if available).
2. Local OS / browser cache
Even after DNS propagates globally, your computer caches the old answer until its local TTL expires.
How to spot it: dig from terminal returns new value, but browser still shows old. That’s local cache.
Flush:
- macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux:
sudo systemd-resolve --flush-cachesorsudo resolvectl flush-caches - Windows:
ipconfig /flushdns - Browser: also flush browser’s internal DNS cache (Chrome:
chrome://net-internals/#dns→ “Clear host cache”)
3. You changed records at the wrong DNS provider
You have two providers — registrar’s default DNS and a separate DNS provider (Cloudflare, Route 53). The active one is determined by which nameservers the registrar points to. You changed records at the inactive provider.
How to spot it:
dig NS yourdomain.comNote the actual nameservers. If they’re not the ones for the provider where you made the change, you changed at the wrong place.
4. Some resolvers ignore TTL, serve old longer
Public resolvers (8.8.8.8, 1.1.1.1) generally respect TTL. ISP resolvers and some corporate DNS servers may serve stale records longer. There’s nothing you can do except wait.
How to spot it:
# Check multiple resolvers
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @9.9.9.9 yourdomain.comIf all three show new value but the site doesn’t load for some users, those users’ DNS is stale.
5. CDN/proxy in front returning cached response
If your DNS points to a CDN that caches origin responses, even with correct DNS your visitors hit the CDN’s cache. CDN purge is separate from DNS.
How to spot it: curl -sI the URL through CDN vs. bypassing it. If CDN serves old content while origin serves new, purge CDN cache.
6. Browser’s HSTS pinning
If your old site had Strict-Transport-Security with includeSubDomains, browsers may still try HTTPS to the old IP/cert even after DNS change.
How to spot it: Browser shows NET::ERR_CERT_AUTHORITY_INVALID or similar. Clear HSTS for the domain in browser settings.
Shortest path to fix
Step 1: Verify with dig (not browser)
dig yourdomain.com +shortShould return the new IP / target. If it does, DNS itself is propagating fine. Issue is local cache or downstream.
Step 2: Test multiple resolvers and regions
dnschecker.org shows resolution from 30+ countries. If most show the new value but some don’t, propagation is in progress.
Step 3: Confirm you changed at the active DNS provider
dig NS yourdomain.comThe nameservers listed are the active ones. Change records there, not anywhere else.
Step 4: Flush local DNS
After verifying global propagation:
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Windows
ipconfig /flushdnsAlso flush browser DNS cache (Chrome: chrome://net-internals/#dns).
Step 5: Lower TTL for future changes
In your DNS provider, set TTL to 300 (5 minutes) at least 24 hours before you plan to make a change. This way, on change day, propagation completes in minutes.
Step 6: Wait it out for ISP resolvers
If dig @8.8.8.8 shows new but ISP DNS shows old, there’s nothing technical to do — wait. ISP resolvers usually catch up within 1-24 hours.
Prevention
- Lower TTL to 300 at least 24h before any planned DNS change.
- Always verify the active nameservers before editing records.
- Use
dig, not the browser, to verify DNS state. - Purge CDN cache when changing origin DNS.
- Document which DNS provider is canonical for your domain in
CANONICAL_DOMAIN.md.