12.5 DNS Caching

Overview

DNS caching is the practice of temporarily storing DNS query results so they can be reused instead of asking DNS servers again. Caching makes name resolution faster, reduces network traffic, and decreases the load on DNS infrastructure. It is a core behavior of almost every device and resolver that participates in DNS.

In this chapter the focus is on where caching happens, how long data is kept, and what benefits and risks come with DNS caches. How DNS works in general, record types, and query types are covered in other chapters.

Where DNS Caching Happens

DNS data is cached in several layers between your application and the authoritative DNS servers. Each layer can answer a DNS question from its own cache if it has a fresh entry.

Typical layers include:

Each layer usually checks its cache first. If it finds a valid entry, it replies immediately and does not ask upstream DNS servers again.

Time To Live (TTL)

Every DNS record includes a Time To Live, or TTL. TTL tells caches how long they are allowed to keep and reuse a DNS answer without asking again.

A TTL is specified in seconds. For example, a DNS record might have a TTL of 300, which is 5 minutes.

TTL is decided by the owner or administrator of the domain when they configure their authoritative DNS zone. Different records in the same zone can have different TTL values.

How TTL Counts Down

When a resolver receives a DNS answer with a TTL value, it stores the record and starts counting down the TTL locally.

For example:

1. An authoritative server sends an A record with TTL 600.
2. A recursive resolver receives it at time T and stores it with a remaining TTL of 600.
3. After 200 seconds, the same resolver still has the record. The remaining TTL is now 400.
4. If a client asks again at that moment, the resolver answers from cache and includes the current remaining TTL (about 400) in the response.
5. When the remaining TTL reaches 0, the cache entry must be discarded or refreshed by performing a new lookup.

Applications and end hosts only see the remaining TTL, not the original value.

Cache Hits and Misses

A cache is useful only when it already holds the needed data. Two basic outcomes are:

A cache hit gives a faster response, since it avoids network round trips to recursive or authoritative servers. A cache miss adds delay while a fresh lookup is performed.

For frequently visited sites or commonly used domains, caches often produce many hits. For rare domains, more lookups result in misses.

Types of Cached DNS Data

Caches do not store only successful answers. They can store several kinds of information.

Common cached items include:

Positive and negative caching behave differently, especially with TTLs.

Positive vs Negative Caching

Positive caching stores successful DNS responses. For example, if a lookup for www.example.com returns an IP address with a TTL, that response can be reused until the TTL expires.

Negative caching stores the fact that a domain or record does not exist. If a resolver learns that a name is not found, it can cache that “no such name” result for a shorter period to avoid repeating useless queries.

Negative cache durations are controlled by special settings in the DNS zone, such as the minimum TTL in the zone’s SOA record. They are usually smaller than TTLs for positive records.

Benefits of DNS Caching

DNS caching provides several concrete advantages.

First, it improves performance for users. If a cached entry exists, name resolution is almost instant because there is no need to contact external DNS servers. Web pages load faster, and applications connect more quickly.

Second, it reduces DNS traffic across networks. Each cache hit avoids one or more upstream queries. This saves bandwidth and reduces the load on recursive and authoritative DNS servers.

Third, it increases resilience. If upstream DNS servers are temporarily unreachable, cached answers may still allow access to previously visited domains until their TTLs expire.

Drawbacks and Tradeoffs

The main drawback of caching is that it introduces a delay between DNS changes and what clients see. If a site changes its IP address, some users may still connect to the old address until old cache entries expire.

This problem is known as DNS propagation delay. Propagation is not mysterious. It is simply caches waiting for TTLs to run out.

From the perspective of someone managing a domain, long TTL values mean more stable caching and fewer DNS queries, but also slower updates when records change. Short TTL values allow quicker changes, but cause more DNS traffic and less effective caching.

Caching on Client Devices

Client devices usually implement at least one cache layer: the operating system resolver cache. Many systems also benefit from application-level caches.

Some web browsers maintain their own DNS caches instead of relying only on the OS. This can keep DNS answers available even if the OS cache is cleared, and it lets the browser share results across its own tabs and windows.

Clients usually have small cache sizes. When the cache is full, older entries are evicted to make room for new ones. Some systems prefer to remove the least recently used entries first.

Caching on Local and ISP Resolvers

Local resolvers, such as home routers or enterprise DNS servers, act as shared caches for many devices. They store answers obtained from upstream recursive or authoritative servers and reuse them for any client that asks.

ISP or public recursive resolvers maintain large caches for huge numbers of users. Their caches often have high hit rates for popular domains, which significantly speeds up name resolution for those domains and reduces load on the wider DNS infrastructure.

Because they serve many clients, these resolvers are particularly sensitive to TTL choices. A small change to TTLs of large or popular zones can affect traffic volume at scale.

Cache Invalidation and Flushing

When DNS records must change quickly, administrators sometimes cannot wait for TTLs to expire naturally. In these cases they may perform cache invalidation or cache flushing on specific resolvers they control.

Cache invalidation means removing or marking an entry as unusable before its TTL expires. After invalidation, the next query triggers a fresh lookup to authoritative servers.

Public and ISP resolvers usually do not allow arbitrary users to force cache flushing, so in many cases you must still wait for TTLs to expire in caches you cannot manage.

Caching and DNSSEC

DNSSEC introduces cryptographic signatures on DNS data, and these signatures are also cached along with the records they verify. DNSSEC does not remove caching, but it adds validation steps at resolvers.

When a DNSSEC validating resolver answers from cache, it uses data that has already been validated. When it refreshes data, it must validate new signatures. TTLs continue to control how long data stays in cache, just as with unsigned DNS.

Security Considerations

DNS caching can be attacked through techniques such as cache poisoning, where an attacker tries to insert false data into a cache. If successful, many clients using that cache may be redirected to malicious servers.

Modern resolvers use randomization, validation rules, and sometimes DNSSEC to reduce this risk. Even with these protections, caches remain a potential target because poisoned entries are reused by many clients until their TTLs expire.

Another consideration is privacy. A cache reveals which domains have been queried recently by its users. Logs that record cache entries and lookups can expose browsing patterns if not protected properly.

Practical Effects for End Users

From an end user perspective, DNS caching explains several common experiences.

A website may change hosting and some users reach the new server while others still see the old server. The differences often come from different caches with different remaining TTLs.

Clearing the DNS cache on a computer or browser can fix some connectivity or access issues, especially when stale or incorrect DNS data is stuck in a local cache.

Switching to a different DNS resolver, such as a public resolver instead of an ISP resolver, may produce different results temporarily, because each resolver has its own cache contents and TTL countdowns.

Understanding these behaviors helps to interpret delays after DNS changes and to troubleshoot name resolution problems more systematically.