A DNS cache stores answers from earlier name lookups so a device or resolver does not need to repeat the full resolution process for every request. A cached answer can make a later lookup faster and reduce queries to authoritative nameservers. It can also explain why one device still uses an older address after a DNS record changes.

There is more than one cache. An application may keep name information, an operating system may cache DNS results, and the recursive resolver that serves the network may cache them too. Clearing one layer affects that layer. It does not erase an authoritative zone or clear upstream resolvers' caches.

Where DNS Answers Can Be Cached

The authoritative nameserver publishes the DNS records for a zone. A recursive resolver obtains answers for clients and may cache them for later requests. The device's DNS client can also hold recently obtained records, and some browsers and applications maintain their own host resolution caches. These layers can produce different observations even for the same name.

For example, an authoritative server might now answer www.example.com with a new address while a recursive resolver and a laptop still hold the old one. Clearing the laptop's local cache removes only its copy. A fresh laptop query can still receive the resolver's old cached answer. Comparing answers from the authoritative server, the recursive resolver, and the application helps identify where the older value remains.

Caches are not necessarily one shared list for every program. An application using encrypted DNS directly may query a different resolver from the one configured in the operating system, and a VPN can direct internal names to a private resolver. Record the exact queried name, record type, and responding server before comparing results.

Why Entries Expire or Disappear

DNS records carry a TTL, measured in seconds, that sets their normal cache lifetime. When that lifetime expires, a resolver normally needs fresh information to answer a later query. Some resolvers can temporarily serve an expired answer when they cannot refresh it, depending on their configuration. An expired entry is therefore different from an older value that is still within its TTL.

A cache can also evict an entry before its TTL ends because it has limited memory or its implementation applies a replacement policy. A restart or an explicit cache clear can remove entries too. The TTL does not promise that every cache keeps the answer for the full interval. An application may also reuse an already open connection without asking DNS again, even after a DNS cache entry expires.

Negative answers can be cached as well. An NXDOMAIN response reports that a name does not exist, while a NODATA response reports that the name exists without the requested record type. If the lookup follows a CNAME alias, the missing name or record can be at the end of that alias chain. A newly created name may therefore remain unavailable through a resolver that still holds an earlier negative answer.

The negative cache lifetime comes from the SOA record in the authoritative response. The authoritative server sets that lifetime to the lower of the zone's SOA TTL and its SOA MINIMUM value, and the remaining lifetime decreases in the cache. The positive TTL assigned to a newly added record does not shorten the lifetime of a negative answer already cached elsewhere.

When Clearing the Local Cache Helps

A local flush is a reasonable diagnostic step when one device shows an older or negative DNS answer while the authoritative servers and the resolver used by that device already return the new answer. After you remove the outdated entry, an application that uses that cache can obtain a fresh answer on its next lookup, unless another local source supplies the result. Use the procedure for the operating system or application that holds the entry.

For a name that was just created, compare a direct query to the intended resolver with the device's ordinary lookup. If the resolver returns the new record but the device still reports NXDOMAIN, a local negative cache is one possible explanation. Clearing that cache and repeating the lookup can test this possibility. If the upstream resolver still returns NXDOMAIN, a local flush may simply retrieve the same negative result.

Check whether the application actually makes a new lookup. An existing connection or an application cache can hide the effect of an operating-system flush. A success message from the flush operation does not establish that a website will load or that an upstream answer has changed.

When Clearing the Cache Will Not Fix the Issue

If the authoritative nameserver still publishes the wrong address, flushing a laptop cannot correct it. If the parent zone delegates to the wrong nameservers, a local clear cannot repair that delegation. Those published records need to be corrected by whoever manages the relevant zone. If the authoritative data is already correct but a recursive resolver retains an older answer within its TTL, waiting for that cache lifetime to expire may be enough.

Clearing DNS will not repair a disconnected WiFi link, a blocked port, an unavailable web server, or a TLS error after the correct address is found. Repeatedly flushing a healthy cache can add avoidable lookups and can remove evidence useful for diagnosis. Preserve the first failing answer before changing the cache.

Compare Answers before and after a Local Flush

Record the name, record type, returned value or error, remaining TTL, and responding server before and after the flush. Compare the authoritative response with the answer from the resolver used by the affected application. Private DNS zones and location-dependent answers can intentionally produce different results, so compare the DNS view intended for that device.

If only the local result is outdated, clear the relevant local cache once and repeat the same lookup. If the old answer returns immediately, check which server or local source supplied it instead of assuming the flush failed. If each DNS layer returns the expected successful answer but the application still fails, investigate the connection and application next.