DNS Cache

A DNS cache is temporary storage containing results from earlier Domain Name System lookups. Browsers, operating systems, routers, and recursive resolvers keep these records so repeated requests can use a local answer instead of starting a new lookup.

How a DNS cache works

When a resolver receives a DNS response, it stores the record for the period defined by its TTL. Requests for the same hostname and record type can reuse that answer while the timer remains valid. After expiration, the resolver requests updated data from the DNS hierarchy.

Caching reduces latency, network traffic, and load on authoritative servers. It is essential to DNS scalability because popular domains can generate large volumes of repeated queries.

Where DNS records are cached

A browser may keep a short-lived cache for recently visited hostnames. The operating system maintains another cache shared by applications. A home router can relay and cache queries, while an internet provider or public recursive resolver serves many users from a larger store.

Each layer can have a different remaining lifetime. Clearing one device does not remove entries held by a router, internet provider, or public resolver.

DNS cache and TTL

The DNS TTL controls how long a record may remain cached. Longer values improve cache efficiency but delay the visibility of changes. Shorter values refresh sooner but increase authoritative query volume.

A cached record retains the TTL that applied when it was stored. Lowering the value after a record change cannot shorten existing copies. Administrators must reduce it before a planned migration and wait for the previous period to expire.

Positive and negative caching

Positive caching stores successful answers such as an IP address, mail server, or verification value. Negative caching stores responses indicating that a name or record does not exist. The zone’s SOA settings influence how long negative answers remain valid.

Negative caching can explain why a newly created hostname still returns NXDOMAIN for some users. The authoritative server may already contain the record while a recursive service continues serving the earlier non-existence response.

When a DNS cache becomes stale

A valid cached record is not technically stale until its TTL expires, even if the authoritative data has changed. Users can therefore reach an old server during a planned DNS update. Incorrectly high TTL values extend this transition.

Corrupted local entries, resolver bugs, policy overrides, and inconsistent authoritative servers can also produce unexpected results. Compare several resolvers before assuming that one cached response reflects the global state.

How to flush a DNS cache

Flushing removes stored DNS data from a specific device or resolver. The next request must perform a fresh lookup. Operating systems provide commands or network controls for clearing their local stores, and browsers may maintain separate caches.

The cPanel DNS cache guide explains why clearing local data can resolve access problems after an address change. Public resolvers may provide cache-purge tools, but users cannot force every resolver worldwide to refresh.

When flushing helps

Clear the local cache after confirming that authoritative DNS returns the intended record. It can help when one device continues reaching an old address, a corrected hostname still fails locally, or a network configuration change replaced the resolver.

Flushing does not repair missing records, incorrect nameservers, broken DNSSEC, or inconsistent authoritative data. Diagnose the source first; otherwise the new lookup will retrieve the same incorrect answer.

DNS cache security

DNS cache poisoning inserts forged data so users are directed to an attacker-controlled destination. Resolvers reduce this risk through randomized query values, strict response matching, secure software, and DNSSEC validation.

Encrypted DNS protects traffic between the client and recursive resolver from local manipulation, but it does not validate unsigned authoritative data. DNSSEC provides origin authentication and integrity when the zone is correctly signed.

Best practices

Use appropriate TTL values, maintain reliable authoritative servers, and lower TTLs before planned changes. Monitor responses from several regions and resolvers. Treat cache flushing as a targeted troubleshooting step, not a substitute for correct DNS configuration.