What Is DNS Cache? Browser & OS Caching Explained

What Is DNS Cache?

Every time a device resolves a domain name — say, example.com — to an IP address, that answer doesn't come free. A full recursive lookup means a resolver queries a root server, then a TLD server, then the domain's authoritative nameserver, before it finally gets a usable IP. That round trip typically costs tens to hundreds of milliseconds. DNS cache exists to avoid paying that cost on every single request.

When a DNS response comes back, it arrives with a TTL — a number of seconds the record is considered valid, defined per RFC 1035 as an unsigned 32-bit integer. Any layer that receives the response — the browser, the OS, the router, the ISP's recursive resolver — is permitted to store that answer locally and hand it back to future requests for the same name, without re-querying anything, until the TTL runs out.

This is why the first visit to a new domain feels slightly slower than the tenth: the first lookup does the full resolution chain and populates every cache layer along the way; the following visits are served straight from cache. It's also why DNS problems can be confusing — you might fix a broken record at the authoritative nameserver and still see the old value for minutes or hours, because a cache somewhere between you and that nameserver hasn't expired yet.

How DNS Caching Works

A DNS lookup and cache write happens in a fixed sequence:

1. Application requests a name. A browser tab loads example.com, or a CLI tool calls getaddrinfo().

2. Local caches are checked first, in order. Browser cache → OS resolver cache → configured DNS server (often the router, or a public resolver like 1.1.1.1 or 8.8.8.8) → that resolver's own cache.

3. On a cache miss, a recursive query runs. The resolver asks a root server for the TLD nameserver, asks the TLD nameserver for the authoritative nameserver, then asks the authoritative nameserver for the actual record. You can trace this exact path yourself with the DNS Lookup tool or NS Lookup tool.

4. The answer is cached at every layer it passed through, each layer storing it against the record's TTL, counting down independently from the moment it was cached — not synchronized across layers.

5. Subsequent requests within the TTL window are answered directly from whichever cache holds a still-valid entry, with zero network round trip to the authoritative server.

Because each cache layer starts its own countdown, cache state is never perfectly consistent across devices, browsers, or ISPs — a change to a DNS record doesn't propagate instantly; it propagates only as fast as every cache holding the old value naturally expires. You can watch that expiry process in real time with the DNS Propagation Checker, which queries multiple resolvers worldwide and shows which ones are still serving stale data.

Where DNS Cache Lives

DNS caching happens at four independent layers, each with its own storage, lifetime rules, and flush method:

Interpretation: the layer closest to you (browser) usually has the shortest effective cache life because of the 60-second floor most browsers apply, while the layer furthest from you (the recursive resolver) most faithfully honors whatever TTL the domain owner actually set.

Per Chromium's DNS cache documentation, when Chrome uses the OS resolver via getaddrinfo(), it has no visibility into the record's real TTL — the OS API doesn't expose it — so Chrome defaults to a flat 60-second cache window regardless of what the DNS record specifies.

DNS Cache vs. DNS TTL

These two terms get used interchangeably but describe different things: TTL is a value set by whoever manages the DNS record; cache is the mechanism that reads and obeys that value.

• TTL (Time-To-Live) is a field in every DNS resource record — an integer in seconds, capped at 2³¹−1 per RFC 1035 §3.2.1 — that tells any resolver how long it's allowed to reuse the record before re-querying.
• DNS cache is the actual stored copy, created and expired according to that TTL, at whichever layer received the response.

Lowering a record's TTL before making a change is standard practice precisely because it shrinks the cache window everywhere downstream — a record with a 300-second TTL clears out of every honest cache within 5 minutes of expiring, while a record with an 86400-second TTL can be served stale for up to 24 hours after a change. For the full mechanics of TTL selection and propagation timing, see DNS TTL Explained.

Positive vs. Negative Caching

DNS doesn't only cache successful answers — it also caches failures, which is a common source of confusion when a newly-created record "isn't working yet."

• Positive caching stores a successful answer (an A record, MX record, etc.) for the record's own TTL.
• Negative caching stores the fact that a lookup failed — NXDOMAIN (name doesn't exist) or NODATA (name exists, but not for the requested record type) — governed by RFC 2308, which fixed a flaw in the original RFC 1034 caching model that prevented negative answers from being shared between resolvers. Negative cache lifetime is controlled by the zone's SOA MINIMUM field, typically 300–3600 seconds, not the record's own TTL (because the record doesn't exist yet to have one).

This is why a domain that returned NXDOMAIN once — because you queried it before its A record was created — can keep returning NXDOMAIN for up to an hour afterward, even though the record now exists at the authoritative server. RFC 9520, published December 2023, further formalized negative caching for resolution failures (timeouts, SERVFAIL) rather than just NXDOMAIN/NODATA, and works alongside RFC 8767 "Serving Stale Data", which permits a resolver to serve an expired cached answer rather than fail outright when the authoritative server is unreachable.

Common Issues & Troubleshooting

Problem: Site shows old content or wrong IP after a DNS change. Cause: a cache layer between you and the authoritative nameserver hasn't hit its TTL expiry yet. Fix: confirm the authoritative record is correct with the DNS Lookup tool, then flush your local caches (see below). If it's still wrong globally, check the DNS Propagation Checker to see which resolvers are lagging — you can't force other people's caches to expire early, only wait out the TTL.

Problem: A record works from your phone but not your laptop (or vice versa). Cause: each device has an independent OS-level cache with its own countdown, so they can be mid-propagation at different points. Fix: flush the cache on the lagging device specifically; there's no shared cache to fix once.

Problem: A brand-new record returns NXDOMAIN even though it's live at the nameserver. Cause: negative caching (RFC 2308) — a resolver cached the "doesn't exist" answer before the record was created. Fix: wait out the SOA MINIMUM TTL (check it with the NS Lookup tool), or flush the specific resolver's cache if you control it.

Problem: A hijacked or spoofed cache entry redirects a domain to the wrong IP. Cause: cache poisoning — a resolver accepted and cached a forged response. This is a distinct security issue from normal TTL expiry; see DNS Hijacking & Spoofing Defense for mitigation.

How to Check and Clear DNS Cache

# Windows — view and flush the OS resolver cache
ipconfig /displaydns
ipconfig /flushdns

# macOS — flush the OS resolver cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved) — view and flush
resolvectl statistics
sudo resolvectl flush-caches

For a full per-platform walkthrough, including browser-specific steps, see How to Flush DNS Cache. To check what the authoritative server is currently serving — independent of any cache — run a direct query with the DNS Lookup tool, and confirm the PTR record maps back correctly with the Reverse DNS Lookup tool when troubleshooting mail or connectivity issues tied to caching.

Key Takeaways

• ✓ DNS cache is a stored copy of a prior lookup, kept independently by the browser, OS, router, and recursive resolver — each with its own TTL countdown.
• ✓ TTL, defined in RFC 1035, is the value that controls how long a cache entry stays valid; DNS cache is the mechanism that honors it.
• ✓ Chrome and most browsers apply a 60-second minimum cache floor regardless of the record's actual TTL when using the OS resolver.
• ✓ Negative caching (NXDOMAIN/NODATA), per RFC 2308, can make a brand-new record appear missing for up to the SOA MINIMUM TTL after creation.
• ✓ You can only flush caches you control (browser, OS, router) — public resolver and ISP caches expire on their own schedule.

Frequently Asked Questions

Related Guides

• How to Flush DNS Cache (All Platforms)
• DNS TTL Explained
• DNS Hijacking & Spoofing Defense
• Fix DNS Server Not Responding (All Devices)