Set Up a BIND Authoritative DNS Server (2026)

BIND is the workhorse of the DNS world, and setting up an authoritative server means telling the internet where to find your domain’s records.

Let’s watch BIND in action. Imagine you have a domain, example.com, and you want BIND to be the source of truth for its DNS records.

Here’s a simplified named.conf file, the main configuration for BIND:

options {
    directory "/var/named";
    listen-on port 53 { 192.168.1.10; }; // Listen on this IP address
    allow-query { any; };
};

zone "example.com" IN {
    type master;
    file "db.example.com"; // The zone file containing records
    allow-transfer { 192.168.1.11; }; // IP of a slave server
};

This configuration tells BIND to:

1. Listen for DNS queries on its network interface 192.168.1.10 on port 53.
2. Be the "master" for the example.com zone.
3. Load the records for example.com from a file named db.example.com located in /var/named.
4. Allow zone transfers (copying the zone file) only to the IP address 192.168.1.11, which would be a secondary (slave) DNS server.

Now, the db.example.com zone file itself:

$TTL 86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023010101 ; Serial
                        3600       ; Refresh
                        1800       ; Retry
                        604800     ; Expire
                        86400 )    ; Minimum TTL
;
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
ns1     IN      A       192.168.1.10
ns2     IN      A       192.168.1.11
www     IN      A       192.168.1.20
mail    IN      A       192.168.1.30

This file defines the "Start of Authority" (SOA) record, which is crucial. It includes:

• The primary name server for the zone (ns1.example.com.).
• The administrator’s email address (admin.example.com., with the first dot replaced by @).
• A serial number (2023010101). This number must be incremented every time you change the zone file. Slave servers use this to detect updates.
• Refresh, Retry, Expire, and Minimum TTL values that govern how slave servers interact with the master.

It also defines:

• Name Server (NS) records, indicating ns1.example.com and ns2.example.com are authoritative for example.com.
• Address (A) records mapping hostnames (ns1, ns2, www, mail) to IP addresses.

When a DNS resolver needs to find www.example.com, it first queries a root server. The root server might say, "I don’t know, but ask the .com servers." The resolver then asks a .com server, which says, "I don’t know, but ask the authoritative servers for example.com." The resolver then queries ns1.example.com (which is running BIND on 192.168.1.10). BIND looks up www in its db.example.com file and returns the IP address 192.168.1.20.

BIND is surprisingly adept at managing a vast number of zones and queries, but its power comes from its configurability. You can define complex delegation scenarios, DNSSEC security extensions, and even custom response policies. The options block is where you set global parameters, while each zone block defines a specific DNS zone BIND is responsible for. The type master; directive is key for authoritative servers; type slave; would be used on secondary servers.

The serial number in the SOA record is the single most important piece of information for zone replication. If you edit db.example.com and forget to increment the serial number, slave servers will not pick up your changes, leading to inconsistent DNS resolution across your infrastructure.

One of the most powerful, yet often overlooked, features is the ability to use views. Views allow you to present different DNS answers to different clients based on their IP address. For example, you could have internal clients resolve internal.example.com to a private IP address, while external clients querying the same name would get a public IP address, or no answer at all. This is configured using view blocks in named.conf, with match-clients clauses to define which IP ranges get which view.

The next hurdle you’ll likely face is ensuring high availability and redundancy, which involves setting up multiple authoritative servers, including slave servers that automatically synchronize zone data from the master.