What is a DNS cache, and how long do records stay in it?

Where does a DNS answer actually get cached?

A single lookup passes through several caches before you notice anything, and each one keeps its own copy for its own length of time:

• The browser. Chrome, Edge and Firefox each keep a small DNS cache of their own, separate from the operating system's. Chrome's is visible at chrome://net-internals/#dns, and clearing it only affects that browser, not the rest of the machine.
• The OS stub resolver. Windows runs the DNS Client service and caches answers you can list with ipconfig /displaydns; macOS caches through mDNSResponder; most Linux desktops run systemd-resolved, a local caching stub resolver you query with resolvectl. This is a real cache with its own TTL countdown, not just a copy of what the browser has.
• The router. Most home routers run a small DNS forwarder that answers from its own cache before passing a query upstream, which is why restarting the router sometimes fixes a DNS problem that was really somewhere else.
• The recursive resolver. Your ISP's resolver, or a public one, handles the most lookups on the internet and holds the largest and most shared cache. Once it has an answer, every device that asks it gets the cached copy until it expires.

Each layer is independent. Flushing the cache on your laptop does nothing to the cache your router or your ISP is still holding, and it does nothing for anyone else's machine.

What is a TTL, and who actually honors it?

Every DNS record carries a time to live: a number in seconds, set by whoever manages the zone, that tells a resolver how long it may reuse the answer before asking again. RFC 1035 defines it as the interval a record "may be cached before the source of the information should again be consulted," and a TTL of zero means the answer must never be cached at all.

Every cache in the chain, browser, stub resolver, router, recursive resolver, is supposed to honor that number, counting down from the moment it first fetched the record. In practice, some ISP resolvers apply their own floor on top of it, commonly an hour or more, regardless of what the zone says the TTL should be. That is why lowering a TTL to speed up a future change helps most resolvers but is not a guarantee for every one of them.

What is negative caching, and why can a brand new record stay missing?

A resolver does not only cache records that exist. If a query comes back with no such name (NXDOMAIN) or with no record of the type asked for, that failure gets cached too, a behavior called negative caching. RFC 2308 sets the negative cache's lifetime from the SOA record's minimum field, and RFC 9520 now makes caching that failure mandatory rather than optional for a compliant resolver.

This is the mechanism behind a familiar problem: you create a new subdomain, query it a second too early, get NXDOMAIN, and the resolver remembers "does not exist" for the length of the zone's negative TTL, even though the record now exists. Windows makes the two kinds of entry visible separately: ipconfig /displaydns lists both the positive answers and the negative ones, and ipconfig /flushdns explicitly discards negative cache entries as part of clearing the cache.

Why does a site resolve for you and not for someone else?

Because there is no single shared cache. Two people asking two different resolvers, or asking the same resolver at two different moments, can get two different answers for the same name. One resolver's copy might still be fresh from a lookup an hour ago; another might never have seen the name before and go fetch the current value. Neither one is wrong, they are just on different clocks. If this is happening right after you changed a record, how to check DNS propagation walks through comparing several resolvers side by side and reading how much time each one has left.

How do you read the TTL of a record that is still cached?

Query the name directly and keep the full output instead of the short form:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

The number before the record type, 847 in this example, is seconds remaining before that particular resolver's copy expires; it is not the record's original TTL, which only the authoritative server can tell you for certain. Run the same query again a few seconds later and the number will have dropped by roughly that many seconds, confirming you are reading a live countdown rather than a static setting. If a name will not resolve at all rather than resolving with a low number, that is a different failure: how to flush DNS covers clearing your own cache first, and what a DNS resolver actually does covers what happens next in the chain when your own cache is not the problem.

A cache explains why one visitor sees a change immediately and another does not; it does not explain a record that never updates anywhere. Run a live lookup with the DNS query tool to see the current answer from outside your own network, and if the site needs to stay reachable on a schedule rather than checked once, that is what distributed monitoring from many checkpoints is for. HostTracker has monitored websites since 2004, now watches 500,000+ sites from 300+ checkpoints in 158 cities, and alerts by email, SMS, voice call, Slack, Telegram and more when a check fails, including a check that expects a specific IP address and flags it the moment the answer changes.

Frequently asked questions

Does a full DNS cache slow down my computer?

No. A DNS cache is a small table of names and addresses, typically a few hundred entries at most, and looking one up costs nothing measurable. If lookups feel slow, the cache itself is not the cause; a distant or overloaded resolver is the usual one.

Does clearing my cache fix things for other people?

No. ipconfig /flushdns, dscacheutil -flushcache and resolvectl flush-caches only clear the cache on the machine you run them on. Everyone else is still reading from their own browser, their own router and their own resolver, each on its own timer.

Is a DNS cache the same thing as a CDN cache?

No, though the two get confused. A DNS cache stores the answer to "what is the IP address for this name." A CDN cache stores the actual page or file content at a server close to the visitor. Clearing one has no effect on the other.

Can I set my own TTL if I do not manage the domain?

No. The TTL is a property of the record, set in the authoritative zone by whoever manages the domain's DNS. As a visitor, the only lever you have is choosing to query a resolver that respects a short TTL rather than one that enforces its own floor.

Why does the TTL I see change every time I query?

Because you are asking a different resolver, or asking the same one at a different moment in its countdown. Query the authoritative nameserver directly with dig example.com @ns1.yourdns.example to see the TTL as it was originally set, with nothing already counted down.