BIND DNS Server — The Most Popular DNS Software

BIND (Berkeley Internet Name Domain) is the most widely used DNS server software on the internet. Developed at the University of California, Berkeley in the 1980s, it has been maintained by the Internet Systems Consortium (ISC) since 1994. It powers the majority of DNS servers worldwide, including many of the root nameservers.

BIND is a complete DNS implementation. It can act as an authoritative nameserver for your domains, a recursive resolver for your network, or both simultaneously. It supports every DNS record type, DNSSEC, zone transfers, split DNS, and response policy zones. If you can name a DNS feature, BIND supports it.

Installing BIND

On Debian and Ubuntu, install BIND with: sudo apt update && sudo apt install bind9. The package name is bind9, and the service name is named (short for name daemon). The configuration files are in /etc/bind/. The main configuration file is named.conf.

On CentOS, RHEL, and Fedora: sudo dnf install bind. The configuration files are in /etc/named.conf and /etc/named/. On these distributions, the service is called named. Enable it to start on boot: sudo systemctl enable named.

After installation, BIND starts immediately with a default configuration that provides a caching recursive resolver. It listens on localhost only, which is safe but not useful for a network DNS server. The initial log file is usually at /var/log/syslog, /var/log/messages, or /var/log/named.log.

BIND Configuration

BIND's configuration is split into multiple files. The main file, named.conf, includes three sections. The options block sets global settings like listening addresses, forwarders, and access control. The zone blocks define which domains BIND is authoritative for. The logging block controls what gets logged.

A basic caching resolver configuration sets forwarders to public DNS servers and allows queries from the local network. Forwarders are upstream DNS servers that BIND queries when it does not have the answer cached. Without forwarders, BIND performs full recursive resolution starting from the root servers.

To host authoritative DNS for your own domain, you add a zone definition pointing to a zone file. The zone file contains your DNS records. BIND reads the zone file and serves the records to clients. Zone transfers send copies of the zone to secondary nameservers specified in the zone definition.

After any configuration change, check the syntax: sudo named-checkconf. This catches syntax errors before they cause BIND to fail. For zone files, use sudo named-checkzone example.com /etc/bind/db.example.com.

Running Authoritative DNS with BIND

BIND is the most common choice for hosting authoritative DNS. ISPs, hosting companies, and large organizations use BIND to serve DNS records for their domains. The configuration is straightforward: define the zone in named.conf and create the zone file.

A typical authoritative zone definition includes the zone name, type (master or slave), the zone file path, and access control for zone transfers. Master zones are the primary copy. Slave zones are replicas from a master. Allow-transfer lists which secondary servers can request zone transfers.

DNSSEC signing is built into BIND. You generate signing keys with dnssec-keygen, configure the zone to use them, and BIND handles the signing automatically. The signed zone includes RRSIG, DNSKEY, and NSEC/NSEC3 records. BIND also supports automatic DNSSEC key rollover.

For the format of zone files and how to structure them, see our DNS zone file guide.

BIND Security Best Practices

BIND has had security vulnerabilities in the past, but modern versions are well-hardened. The most important security measure is running BIND in a chroot jail. This restricts BIND's filesystem access to a specific directory. If an attacker compromises BIND, they cannot access the rest of the system.

Restrict zone transfers to authorized secondary servers only. An open zone transfer allows anyone to download your entire DNS configuration, revealing all subdomains and server names. Use the allow-transfer option with a list of trusted IP addresses.

Limit recursive queries to authorized clients. If BIND is configured as a recursive resolver for the public, it can be used in DNS amplification attacks. Restrict recursion to your own network using the allow-recursion option or the recursion no directive for external queries.

Keep BIND updated. The ISC releases security patches regularly. Subscribe to their security announcements and update immediately when critical vulnerabilities are disclosed. Use your distribution's package manager to receive updates.

Troubleshooting BIND

When BIND does not work as expected, check the logs first. BIND logs detailed information about queries, zone transfers, and errors. The log location depends on your system. On Debian: /var/log/syslog. Check for error messages related to zone loading, permission problems, or configuration syntax.

Use rndc (Remote Name Daemon Control) to manage BIND at runtime. sudo rndc status shows whether BIND is running and how many queries it has handled. sudo rndc reload reloads the configuration without restarting. sudo rndc flush clears the DNS cache.

Test DNS resolution through BIND: dig @127.0.0.1 example.com. If BIND is authoritative for the domain, the answer section shows the records from your zone file. If BIND is a recursive resolver, the response includes an additional section with the resolution path.

For more on setting up BIND as part of your DNS infrastructure, see our DNS server setup guide.