BIND’s cache isn’t just a passive storage; it’s an active participant that can significantly bottleneck your DNS resolution if not tuned.
Let’s see it in action. Imagine a busy web server. Every time it needs to resolve an external hostname, it hits BIND. Without a well-tuned cache, BIND might be constantly re-querying upstream servers for records it just looked up, leading to high latency for your users and an overloaded BIND instance.
Here’s how BIND’s cache works: when BIND receives a query for a hostname it doesn’t have a record for, it asks the configured forwarders or root servers. Once it gets the answer, it stores it in its cache for a duration specified by the Time-To-Live (TTL) value in the DNS record. Subsequent queries for the same hostname within that TTL will be served directly from the cache, which is orders of magnitude faster than querying external servers. The max-cache-size option limits the total memory BIND can use for its cache, and max-cache-ttl and min-cache-ttl control the maximum and minimum time BIND will hold onto cached records, overriding the TTLs from the DNS records themselves.
The primary problem BIND’s cache solves is reducing external DNS query load and improving local DNS resolution speed. By intelligently caching responses, BIND minimizes the need to traverse the full DNS hierarchy for every request.
The max-cache-size option is crucial. It dictates how much memory BIND can dedicate to its cache. If this is too small, BIND will evict older cache entries prematurely, even if they have long TTLs, leading to more upstream queries. If it’s too large, it can starve other BIND processes or even the operating system of memory, causing general system instability. A good starting point for a moderately busy server might be max-cache-size 128M.
max-cache-ttl and min-cache-ttl allow you to influence how long records stay in the cache, regardless of their original TTL. Setting max-cache-ttl 86400; (24 hours) ensures that even if a record’s TTL is shorter, BIND will keep it for up to a day. Conversely, min-cache-ttl 60; (1 minute) means BIND won’t cache a record for less than a minute, even if its TTL is extremely short, preventing rapid churn of frequently changing records.
To monitor cache performance, use rndc stats. This command provides detailed statistics, including response-cache-hits and response-cache-misses. A high hit rate (hits / (hits + misses)) indicates an effective cache. You can also use dig +stats <hostname> to see how long resolution took, and if it’s consistently high, it might point to cache issues.
Tuning rrset-cache-size is also important. This controls the cache for RRsets (Resource Record Sets), which are groups of RRs with the same name, class, and type. A larger rrset-cache-size (e.g., rrset-cache-size 128M) can improve performance by reducing the overhead of managing individual records.
The dns64 and nat64 options, when configured, can add complexity. These are used for IPv6-to-IPv4 translation. If you’re using these, ensure their cache sizes are also appropriately tuned, as they introduce additional caching layers for synthesized records.
The most common mistake is to simply set max-cache-size to a very large value without considering system memory. This can lead to BIND consuming excessive memory, causing the OS to start swapping, which kills DNS performance far worse than a small cache ever could. It’s a delicate balance; you want enough cache to be effective but not so much that you starve the system.
Finally, consider the recursive-cache directive. This specifically controls the size of the cache used for recursive queries. If you’re running BIND primarily as a recursive resolver for a local network, tuning recursive-cache (e.g., recursive-cache 32M;) is as vital as max-cache-size.
Understanding the interplay between max-cache-size, rrset-cache-size, max-cache-ttl, and min-cache-ttl is key to unlocking BIND’s caching potential.
The next logical step after optimizing the cache is to fine-tune BIND’s query processing and network socket configurations.