DNS caching explained

There is not one cache. There are several, stacked, and only one of them is the TTL you set in the panel.

Authoritative servers do not cache their own zone in the recursor sense; they are the source. Recursive resolvers cache positive and negative answers per TTL. Operating systems keep a stub cache (Windows DNS Client, macOS mDNSResponder, systemd-resolved). Browsers cache additional minutes. CDNs and proxies cache the target of a CNAME. DNSFetch caches each query five minutes so repeats are cheap.

Flushing the stub

Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux with systemd: resolvectl flush-caches. Then still ask a public resolver, because your ISP’s recursor is a different box.

Why we look up on the server

A browser-only tool would show you your cache. That is useless during an incident. DNSFetch’s answers come from the application server’s resolver. They can still be cached, but they are not the Chrome cache from this morning. If we show the new A record and your office does not, flush local, then wait out ISP TTL, then check split-horizon.

Related: propagation, TTL.