thelinuxvault blog

Managing BIND DNS Server Cache: Viewing and Clearing Cache

The Berkeley Internet Name Domain (BIND) is the most widely used DNS (Domain Name System) server software globally, powering millions of DNS infrastructure deployments. A critical feature of BIND (and all DNS servers) is caching, which temporarily stores DNS query results to improve performance, reduce latency, and lighten the load on upstream DNS servers. However, mismanaged cache can lead to stale or incorrect DNS records, causing outages or misrouting.

This blog dives deep into managing BIND’s DNS cache, focusing on viewing cached records and clearing stale cache—essential skills for system administrators, DevOps engineers, and anyone responsible for DNS infrastructure. By the end, you’ll understand how BIND cache works, how to inspect it, and how to safely clear it when needed.

2026-02

Table of Contents#

  1. Understanding BIND DNS Cache
    • What is DNS Caching?
    • How BIND Handles Caching
    • Why Cache Management Matters
  2. Viewing BIND DNS Cache
    • Using rndc dumpdb to Export Cache
    • Parsing the Cache Dump File
    • Using rndc stats for Cache Statistics
  3. Clearing BIND DNS Cache
    • Clearing the Entire Cache (rndc flush)
    • Clearing Specific Records (rndc flushname)
    • Clearing Subdomain Trees (rndc flushtree)
    • Restarting BIND (Last Resort)
  4. Best Practices for Cache Management
  5. Troubleshooting Common Cache Issues
  6. Conclusion
  7. References

1. Understanding BIND DNS Cache#

What is DNS Caching?#

DNS caching is the process of storing the results of DNS queries (e.g., "example.com → 93.184.216.34") locally on a DNS server. When a client requests the same domain again, the server can respond immediately using the cached record instead of querying upstream DNS servers (e.g., root servers, TLD servers, or authoritative servers). This reduces latency and bandwidth usage.

How BIND Handles Caching#

BIND acts as a recursive resolver (by default) for clients, meaning it fetches DNS records on their behalf. When BIND resolves a query, it stores the result in its cache until the record’s Time-to-Live (TTL) expires. TTL is set by the authoritative DNS server for the domain and specifies how long the record can be cached.

Key points about BIND cache:

  • Cache Location: BIND stores cache in memory by default. To persist cache across restarts, enable cache-file in named.conf (e.g., cache-file "/var/cache/bind/cache.db";).
  • Cache Size: Controlled by max-cache-size in named.conf (default: 90% of physical memory).
  • TTL Enforcement: BIND respects TTLs, so cached records auto-expire. However, manual intervention may be needed for urgent updates.

Why Cache Management Matters#

  • Performance: Cached records reduce query latency from seconds to milliseconds.
  • Reliability: Reduces dependency on upstream servers, improving uptime during outages.
  • Accuracy: Stale cache can serve outdated IPs, causing "page not found" errors or routing to old servers.

2. Viewing BIND DNS Cache#

Before clearing cache, you need to inspect it to confirm stale records exist. BIND provides two primary methods to view cache: dumping the cache to a file and checking statistics.

Using rndc dumpdb to Export Cache#

The rndc (Remote Name Daemon Control) utility manages BIND remotely. The dumpdb command exports the current cache to a text file for inspection.

Step 1: Verify rndc Configuration#

Ensure rndc is configured to communicate with BIND. Check named.conf for an controls block (required for rndc access):

controls {
  inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};

If missing, generate an rndc key with rndc-confgen -a and restart BIND.

Step 2: Dump the Cache#

Run:

sudo rndc dumpdb -cache
  • -cache: Dumps only the resolver cache (excludes authoritative zones).
  • Output File: By default, BIND saves the dump to /var/cache/bind/named_dump.db (path may vary by OS; check named.conf for dump-file).

Parsing the Cache Dump File#

The named_dump.db file contains cached records in a human-readable format. Let’s break down its structure with an example entry:

www.example.com.     300     IN      A       93.184.216.34
  • www.example.com.: The domain name (FQDN, trailing dot required).
  • 300: Remaining TTL (in seconds; 300 = 5 minutes).
  • IN: Class (Internet, the only common class).
  • A: Record type (A = IPv4 address; other types: AAAA, CNAME, MX, etc.).
  • 93.184.216.34: Record data (the IPv4 address).

Filtering the Dump File#

For large caches, use grep to search for specific domains:

grep "example.com" /var/cache/bind/named_dump.db

Or count total cached records:

wc -l /var/cache/bind/named_dump.db

Using rndc stats for Cache Statistics#

To view high-level cache metrics (hits, misses, size), use rndc stats:

sudo rndc stats

This generates a stats file (default: /var/cache/bind/named.stats). Key metrics include:

  • Cache hits: Number of queries answered from cache.
  • Cache misses: Queries requiring upstream resolution.
  • Total cache size: Number of records in cache.

Example stats snippet:

+++ Cache +++
Cache hits (requested) 12345
Cache hits (answered)  11234
Cache misses           876
Total cache size       4567 records

3. Clearing BIND DNS Cache#

If you find stale records, clear the cache selectively or entirely. Use rndc commands for safe, non-disruptive cache clearing.

Clearing the Entire Cache (rndc flush)#

To clear all cached records (use sparingly!):

sudo rndc flush
  • Effect: Empties the entire cache. BIND will re-resolve all queries from scratch.
  • Use Case: When multiple domains have stale records (e.g., after a DNS migration affecting many zones).

Clearing Specific Records (rndc flushname)#

For single domains (e.g., example.com), use flushname:

sudo rndc flushname example.com
  • Syntax: rndc flushname <domain> (FQDN optional; BIND appends the trailing dot).
  • Example: Flush www.sub.example.com:
    sudo rndc flushname www.sub.example.com

Clearing Subdomain Trees (rndc flushtree)#

To clear a domain and all its subdomains (e.g., sub.example.com and *.sub.example.com):

sudo rndc flushtree sub.example.com
  • Use Case: After updating a subdomain’s authoritative server (e.g., moving blog.example.com to a new host).

Restarting BIND (Last Resort)#

Restarting BIND clears cache but disrupts service temporarily. Use only if rndc commands fail:

# Systemd (Ubuntu/Debian/RHEL 8+)
sudo systemctl restart named
 
# SysVinit (Older RHEL/CentOS)
sudo service named restart

4. Best Practices for Cache Management#

  • Clear Cache Selectively: Prefer flushname/flushtree over flush to avoid performance hits from mass re-resolving.
  • Monitor Cache Size: Use rndc stats to ensure max-cache-size isn’t exceeded (prevents memory bloat).
  • Set Appropriate TTLs: Work with authoritative server admins to set short TTLs (e.g., 5 minutes) for frequently updated records (e.g., www).
  • Avoid Frequent Flushes: Over-clearing cache increases latency and upstream server load.
  • Automate Checks: Use tools like dnstop or Prometheus + bind_exporter to monitor cache hit/miss ratios.

5. Troubleshooting Common Cache Issues#

Cache Not Dumping?#

  • Permissions: Ensure BIND has write access to the dump directory (e.g., /var/cache/bind).
  • rndc Access: Verify controls in named.conf allows your IP (e.g., 127.0.0.1).
  • BIND Version: Older BIND versions may require dumpdb -all instead of -cache.

Flush Not Working?#

  • Check Recursive Mode: BIND only caches if configured as a resolver (recursion yes; in named.conf).
  • Verify Domain: Ensure the domain is cached (check named_dump.db before flushing).
  • TTL Already Expired: The record may have auto-expired; no need to flush.

Large Dump File?#

Use grep with record types to filter:

# Show only A records for example.com
grep -E "example.com.*IN A" /var/cache/bind/named_dump.db

6. Conclusion#

Managing BIND’s DNS cache is critical for maintaining fast, reliable, and accurate DNS resolution. By viewing cache with rndc dumpdb and rndc stats, and clearing it selectively with flush, flushname, or flushtree, you can resolve stale record issues without disrupting service. Always follow best practices like selective flushing and monitoring to keep your DNS infrastructure healthy.

7. References#