BIND named.conf: Every Option Explained (2026)

BIND’s named.conf is more than just a configuration file; it’s the central nervous system for your DNS server, dictating everything from security policies to performance tuning.

Let’s see named.conf in action, managing DNS zones and security. Imagine a basic setup for a local zone:

options {
    directory "/var/named";
    listen-on port 53 { 127.0.0.1; 192.168.1.10; };
    allow-query { localhost; 192.168.1.0/24; };
    recursion yes;
    dnssec-enable yes;
    dnssec-validation auto;
};

acl "trusted" {
    localhost;
    192.168.1.0/24;
};

zone "example.local" IN {
    type master;
    file "db.example.local";
    allow-update { none; };
};

zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "db.192.168.1";
    allow-update { none; };
};

This snippet illustrates how options sets global parameters, acl defines trusted networks, and zone blocks specify authoritative data.

The core problem named.conf solves is providing a structured, human-readable way to configure the complex behaviors of the BIND DNS server. Without it, you’d be wrestling with binary flags and a much less intuitive interface. It allows administrators to define authoritative zones (where your domain’s records live), forwarders (where to send queries it can’t answer), access control lists (who can query your server), and a myriad of other operational parameters.

Internally, BIND parses named.conf at startup and whenever the configuration is reloaded. It translates these directives into internal data structures and operational states that govern how the named process handles DNS requests. For instance, the listen-on directive tells BIND which network interfaces and ports to bind to, ensuring it’s reachable. allow-query then acts as a gatekeeper, filtering incoming requests based on their source IP address. recursion yes; enables recursive lookups, allowing your server to fetch answers from other DNS servers on behalf of clients.

Understanding the options block is crucial. Here’s a breakdown of commonly used options and their impact:

directory "/var/named";: This is the base directory for zone files and other BIND data. If your zone file db.example.local is declared in a zone statement, BIND will look for it in /var/named/db.example.local. Changing this to /etc/bind/zones would mean all your zone files need to reside there.
listen-on port 53 { 127.0.0.1; 192.168.1.10; };: This directive specifies which IP addresses and ports named should listen on for incoming DNS queries. 127.0.0.1 is the loopback interface (localhost), and 192.168.1.10 is a specific internal IP. If you want BIND to respond to queries on your server’s public IP 203.0.113.5, you’d add that: listen-on port 53 { 127.0.0.1; 192.168.1.10; 203.0.113.5; };. This ensures your server is accessible on the intended interfaces.
allow-query { localhost; 192.168.1.0/24; };: This controls which clients are allowed to query your DNS server. localhost refers to 127.0.0.1, and 192.168.1.0/24 is a private network subnet. To allow queries from any IP address (generally not recommended for public servers), you’d use any;. To restrict it further, you might specify individual IPs or ACLs. This is a primary security mechanism.
recursion yes;: When set to yes, BIND will perform recursive lookups for clients. This means if BIND doesn’t have the answer in its cache or authoritative data, it will query other DNS servers to find it. Setting this to no turns your server into an authoritative-only server, which is common for public DNS servers but not for internal resolvers.
dnssec-enable yes;: Enables DNS Security Extensions (DNSSEC) processing. This is critical for validating DNS responses and preventing cache poisoning attacks. When yes, BIND will attempt to use DNSSEC validation if the DNS records are signed.
dnssec-validation auto;: Configures how DNSSEC validation is performed. auto is generally recommended, meaning BIND will attempt to validate DNSSEC signatures using the configured trust anchors. Other options include yes (strict validation) and no (disable validation).
forwarders { 8.8.8.8; 8.8.4.4; };: If your server needs to perform recursion and you don’t want it to do the full lookup itself, you can specify forwarders. BIND will send queries it can’t answer authoritatively to these servers (e.g., Google’s public DNS). If you add forward only;, BIND will only use the forwarders and won’t attempt recursive lookups itself.
allow-recursion { trusted; };: This option, often used in conjunction with recursion yes;, restricts which clients are allowed to make recursive queries. Here, trusted is an ACL defined elsewhere, meaning only clients in the trusted ACL can ask for recursive lookups. This prevents your server from becoming an open resolver abused for DDoS amplification attacks.
max-cache-size 90%;: Limits the amount of memory BIND can use for caching. Setting it to 90% means BIND will try to keep its cache size at or below 90% of the total available memory. This prevents BIND from consuming all system RAM.
cleaning-interval 60;: Specifies how often BIND should clean up old cache entries. A value of 60 means it cleans every 60 minutes. Lower values can increase CPU usage but might keep the cache fresher.
pid-file "/var/run/named/named.pid";: Defines the path to the file that stores the Process ID (PID) of the running named process. This is useful for scripting, allowing you to easily stop or restart the service using kill $(cat /var/run/named/named.pid).
statistics-file "/var/named/named.stats";: Specifies a file where BIND will write performance statistics. This is invaluable for monitoring and troubleshooting, providing metrics on query rates, cache hits, and more.
memstatistics-file "/var/named/named.memstats";: Similar to statistics-file but focuses on memory usage statistics.
managed-keys-directory "/var/named/dynamic";: This directory is used by BIND to store information about managed trust anchors for DNSSEC.

The transfer-source option is often overlooked and can cause subtle issues in complex network environments. If your BIND server has multiple IP addresses and is acting as a secondary for a zone, the default behavior for zone transfers might not be what you expect. By default, BIND might choose an arbitrary outgoing IP for the TCP connection to the primary server. Explicitly setting transfer-source to a specific IP address on your server ensures zone transfers always originate from a predictable, known interface, which can be crucial if firewalls or network configurations are sensitive to source IP addresses.

The next thing you’ll likely encounter is configuring specific DNS record types within zone files.