A cafe owner in Salthill rang me last month in a panic. "My website's down." I checked on my phone — loaded fine. She checked on hers — nothing. Her husband's laptop? Also nothing. Her daughter's phone? Worked perfectly.
Same WiFi. Same network. Some devices could reach the site, others couldn't. Classic DNS caching issue, and it catches people out more often than you'd think.
What actually happened
She'd migrated her site to a new host the day before. The domain's DNS records were updated to point to the new server's IP address. But here's the thing — not every device got the memo at the same time.
DNS doesn't update instantly. When you change a DNS record, the old IP address is cached at multiple levels: your browser, your operating system, your router, your ISP's resolver. Each cache has its own expiry timer (the TTL — Time to Live), and until that timer runs out, the device keeps using the old, stale IP.
Her phone had cleared its cache recently (she'd restarted it that morning). Her husband's laptop hadn't been restarted in a week. The browser was still sending requests to the old server, which was already shut down.
Where DNS gets cached
There are four layers of caching between you and a DNS answer:
1. Browser cache — Chrome, Firefox, Safari, and Edge all maintain their own DNS caches, separate from the OS. This is the most common source of "works in one browser, not another" problems.
2. OS cache — Your operating system caches DNS lookups too. This affects all applications on the device.
3. Router cache — Some routers cache DNS responses. Less common with modern routers, but it happens.
4. ISP resolver cache — Your ISP's DNS server caches responses based on the TTL set by the domain owner. You can't flush this one — you have to wait, or switch to a different resolver.
How browsers handle DNS caching differently
This is where it gets interesting. Each browser has its own caching behaviour, and they don't all agree:
| Browser | Default DNS cache TTL | How to clear |
|---|---|---|
| Chrome | 60 seconds (ignores TTL > 60s) |
chrome://net-internals/#dns → Clear host cache |
| Firefox | 60 seconds |
about:networking#dns → Clear DNS Cache |
| Safari | Follows OS cache | Clear via OS (see below) |
| Edge | Same as Chrome (Chromium-based) |
edge://net-internals/#dns → Clear host cache |
Chrome aggressively caps DNS TTL at 60 seconds internally, regardless of what the domain's actual TTL is set to. That's why Chrome often picks up DNS changes faster than Safari — Safari relies on macOS's system-level DNS cache, which respects the original TTL and can hold onto stale records for hours.
This is exactly why my client's daughter (Chrome on her phone) could see the new site while her husband (Safari on his MacBook) couldn't.
How to flush DNS on every platform
When you're troubleshooting DNS caching issues, flushing the cache forces your device to do a fresh lookup:
macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Windows
ipconfig /flushdns
Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
Chrome (all platforms)
Navigate to chrome://net-internals/#dns and click "Clear host cache". Then go to chrome://net-internals/#sockets and click "Flush socket pools" — this clears any connections still pinned to the old IP.
Firefox
Navigate to about:networking#dns and click "Clear DNS Cache".
How to verify the fix
After flushing, confirm your device is resolving to the correct IP:
dig example.com +short
Compare the result to what you expect. If you don't have dig installed, use the online dig tool at publicdns.info — it queries from an external server, so you'll see the current authoritative answer without any local caching interfering.
If your local result differs from what publicdns.info shows, something between you and the authoritative server is still caching the old record.
How to prevent this in the first place
If you're planning a migration, lower the DNS TTL before you move:
- 48 hours before migration: Drop the TTL to 300 seconds (5 minutes) or lower
- Wait for the old TTL to expire — if it was set to 86400 (24 hours), you need to wait at least that long after lowering it
- Do the migration — update DNS records to the new IP
- After everything's stable: Raise the TTL back to a sensible value (3600-86400)
Most DNS caching issues after migrations happen because someone skipped step 1. They change the IP while the TTL is still set to 24 hours, and then half their users are stuck on the old address for a day.
You can check what TTL a domain currently has using publicdns.info — compare responses from different DNS servers to see if they've all picked up the change.
The router wildcard
One thing that caught me out on this particular job: after flushing the DNS on her husband's laptop, it still didn't work. Turned out their router (an older Eir-supplied one) was caching DNS responses too.
Power-cycling the router cleared it. Not elegant, but effective. If flushing the device cache doesn't help and you're behind a home router, this is worth trying before you go down more complicated debugging paths.
Quick reference
-
"Works in Chrome, not Safari" → Chrome caps DNS cache at 60s, Safari uses OS cache. Flush macOS DNS:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder - "Works on phone, not laptop" → Phone was restarted recently, laptop has stale cache. Flush DNS on the laptop.
- "Works nowhere on my network" → Router is caching. Power-cycle it.
- "Works on my network, not others" → ISP resolver still has old record. Wait for TTL to expire, or switch to a public DNS like 1.1.1.1 or 8.8.8.8.
- Before any migration → Lower TTL to 300 seconds at least 48 hours ahead.
- Verify current state → Check publicdns.info/tools/dig to see what the rest of the world sees.
The Salthill cafe owner? Flushed DNS on the laptop, power-cycled the router, and everything was grand. Total fix time: about three minutes once I knew what the problem was. The trick is knowing where to look.
Top comments (0)