BIND’s negative caching can be a performance bottleneck if misconfigured, leading to unnecessary DNS lookups.
Let’s see it in action. Imagine a client requests nonexistent.example.com. If BIND doesn’t have an answer, it queries upstream. If upstream also says "doesn’t exist" (an NXDOMAIN response), BIND caches this negative response. The negative-cache-ttl setting dictates how long BIND remembers this NXDOMAIN.
Here’s a typical BIND configuration snippet:
options {
directory "/var/cache/bind";
recursion yes;
allow-query { any; };
listen-on { 192.168.1.10; };
listen-on-v6 { any; };
// Default negative-cache-ttl is 15 minutes (900 seconds)
// negative-cache-ttl 15; // This is equivalent to 900 seconds
// We'll adjust this to 5 seconds for demonstration
negative-cache-ttl 5;
};
In this example, negative-cache-ttl 5; means BIND will remember that nonexistent.example.com does not exist for only 5 seconds. After 5 seconds, if another client asks for nonexistent.example.com, BIND will perform a fresh upstream query, even though it’s highly likely the answer will be the same.
The problem this solves is reducing redundant DNS queries. When a domain legitimately ceases to exist, or a typo is common, clients might repeatedly ask for it. Without negative caching, BIND would hammer upstream DNS servers for every single request. With negative caching, BIND answers "doesn’t exist" from its local cache for the duration of the TTL, sparing upstream resources and improving client response times.
The negative-cache-ttl option directly controls this. It takes a value in seconds. A higher TTL means BIND will cache the negative response for longer, reducing upstream queries but potentially delaying propagation if a domain is recreated within that TTL. A lower TTL means BIND will re-query upstream more frequently, increasing load but ensuring faster recognition of newly created domains.
The key levers are the TTL value itself and understanding the trade-off between cache hit rate for non-existent domains and the speed at which newly created domains become resolvable.
The actual negative cache is managed internally by BIND’s caching daemon. You can inspect its state using rndc dumpdb -cache. The output will show entries, and for NXDOMAIN responses, you’ll see a TTL associated with them. If you’ve set negative-cache-ttl 5;, you’ll observe that these NXDOMAIN entries expire and are removed from the cache after 5 seconds, prompting a new query.
BIND’s default negative-cache-ttl is 15 minutes (900 seconds). This is often a reasonable compromise, but in environments with many transient or frequently mistyped hostnames, or where rapid domain recreation is common, tuning this value can yield significant improvements. For instance, in a development environment where test subdomains are constantly created and destroyed, a very low TTL like 5 seconds might be beneficial. Conversely, for a stable production environment where the chance of a non-existent domain suddenly becoming existent is low, a higher TTL (e.g., 30 minutes or 1800 seconds) could further reduce load.
The biggest surprise is how sensitive BIND’s performance can be to this single setting. Many administrators overlook negative caching entirely, leaving it at the default, unaware that a significant portion of their DNS traffic might be for non-existent records. Adjusting negative-cache-ttl can dramatically reduce the number of recursive queries BIND performs, especially under load with many clients requesting non-existent or frequently changing records.
The next step after tuning negative caching is often exploring DNSSEC validation performance implications.