DNS negative caching is a bit of a misnomer; it’s not about caching the fact that something doesn’t exist, but rather caching the authoritative answer that a name doesn’t exist.
Let’s watch this unfold in real-time. Imagine a client trying to resolve nonexistent.example.com.
# Client initiates a DNS query for nonexistent.example.com
# The query goes to a recursive resolver (e.g., 8.8.8.8)
# Recursive resolver doesn't have it cached, so it queries the authoritative NS for example.com
# Authoritative NS for example.com responds with NXDOMAIN (Non-Existent Domain)
# This NXDOMAIN response is *not* a data record, but a status code.
# The resolver caches this NXDOMAIN response.
Now, if another client on the same network asks the same recursive resolver for nonexistent.example.com within the TTL (Time To Live) of that NXDOMAIN response, the resolver will immediately respond with NXDOMAIN without querying the authoritative server again. This is negative caching in action.
The primary problem negative caching solves is reducing the load on authoritative DNS servers. Without it, every single failed lookup would result in a query to the authoritative server, which, for popular domains with many typos or internal-only names that are frequently mistyped, could be substantial. It also speeds up resolution for non-existent names for clients talking to the recursive resolver.
Internally, the recursive resolver stores the NXDOMAIN response along with its associated TTL. This TTL is determined by the authoritative server in the original NXDOMAIN response. When a subsequent query for the same name arrives within that TTL, the resolver serves the cached NXDOMAIN.
The key levers you control are the TTLs for negative responses and the maximum amount of time a recursive resolver will hold onto a negative cache entry, even if the authoritative server provided a very long TTL.
On BIND, for instance, you can tune this with max-negative-ttl.
options {
max-negative-ttl 300; // Cache negative responses for a maximum of 5 minutes
// ... other options
};
This max-negative-ttl setting overrides the TTL provided by the authoritative server. If the authoritative server sends an NXDOMAIN with a TTL of 1 hour (3600 seconds), but max-negative-ttl is set to 300, the recursive resolver will only cache that NXDOMAIN for 5 minutes. This is crucial for rapidly changing DNS environments where a name might exist one moment and be deleted the next. A long negative cache could prevent legitimate resolution.
The dns-prefetch feature in web browsers is a practical application of this. Browsers often pre-fetch DNS records for links on a page to speed up navigation. If a link points to a non-existent domain, the browser might negatively cache that information for a short period, preventing repeated lookups for that specific non-existent domain during the page’s lifetime.
Many people assume that if a recursive resolver is returning an NXDOMAIN, it’s always querying the authoritative server. However, the presence of a valid negative cache entry means the resolver is simply returning a pre-existing "no such name" answer from its local memory, significantly reducing latency and upstream query load. The magic is that the authoritative answer for non-existence is itself cached.
The next concept you’ll likely encounter is DNSSEC validation and how it interacts with negative caching, specifically the SERVFAIL response when validation fails.