How to Setup BIND as an Authoritative DNS Server

An authoritative DNS server is the definitive source of DNS records for the domains it hosts. Unlike recursive resolvers that query other servers, authoritative servers directly answer queries with the records they maintain. In this guide, we'll configure BIND 9 as an authoritative-only DNS server.

1. Authoritative vs Recursive Servers

Understanding the difference is crucial:

• Authoritative servers provide definitive answers for domains they host. They don't perform recursion.
• Recursive resolvers query other servers on behalf of clients to find answers.

Running authoritative-only servers offers better performance and security since they only handle queries for zones they're responsible for.

2. Installation

Install BIND on your system:

Debian/Ubuntu:

sudo apt update
sudo apt install -y bind9 bind9utils dnsutils

RHEL/Rocky/AlmaLinux:

sudo dnf install -y bind bind-utils

3. Authoritative-Only Configuration

Configure BIND to only serve authoritative responses. Edit /etc/bind/named.conf.options (Debian) or /etc/named.conf (RHEL):

options {
    directory "/var/cache/bind";

    // Listen on all interfaces
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };

    // Disable recursion - this is authoritative only
    recursion no;
    allow-recursion { none; };

    // Allow queries from anyone (public authoritative server)
    allow-query { any; };

    // Disable zone transfers by default (override per-zone)
    allow-transfer { none; };

    // DNSSEC
    dnssec-validation auto;

    // Security hardening
    version "not disclosed";
    minimal-responses yes;

    // Rate limiting
    rate-limit {
        responses-per-second 15;
        window 5;
    };
};

4. Zone Configuration

Define your zones in /etc/bind/named.conf.local (Debian) or add to /etc/named.conf (RHEL).

4.1. Primary Zone (Master)

zone "example.com" {
    type primary;
    file "/var/lib/bind/zones/example.com.zone";
    allow-transfer { 10.0.0.2; };  // Secondary server IP
    also-notify { 10.0.0.2; };     // Notify secondary on changes
};

// Reverse DNS zone for 192.168.1.0/24
zone "1.168.192.in-addr.arpa" {
    type primary;
    file "/var/lib/bind/zones/192.168.1.rev";
    allow-transfer { 10.0.0.2; };
    also-notify { 10.0.0.2; };
};

4.2. Secondary Zone (Slave)

On a secondary server:

zone "example.com" {
    type secondary;
    file "/var/lib/bind/zones/example.com.zone";
    primaries { 10.0.0.1; };  // Primary server IP
};

5. Creating Zone Files

Create the zones directory:

sudo mkdir -p /var/lib/bind/zones
sudo chown bind:bind /var/lib/bind/zones

5.1. Forward Zone File

Create /var/lib/bind/zones/example.com.zone:

$TTL 86400
$ORIGIN example.com.

@   IN  SOA ns1.example.com. admin.example.com. (
            2024121201  ; Serial (YYYYMMDDNN)
            3600        ; Refresh (1 hour)
            1800        ; Retry (30 minutes)
            604800      ; Expire (1 week)
            86400       ; Minimum TTL (1 day)
)

; Nameservers
@           IN  NS      ns1.example.com.
@           IN  NS      ns2.example.com.

; Nameserver A records
ns1         IN  A       10.0.0.1
ns2         IN  A       10.0.0.2

; Mail servers
@           IN  MX  10  mail.example.com.
@           IN  MX  20  mail2.example.com.

; A records
@           IN  A       93.184.216.34
www         IN  A       93.184.216.34
mail        IN  A       10.0.0.10
mail2       IN  A       10.0.0.11
ftp         IN  A       10.0.0.20

; CNAME records
webmail     IN  CNAME   mail.example.com.
smtp        IN  CNAME   mail.example.com.
imap        IN  CNAME   mail.example.com.

; TXT records for email authentication
@           IN  TXT     "v=spf1 mx a:mail.example.com -all"
_dmarc      IN  TXT     "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; AAAA records (IPv6)
@           IN  AAAA    2001:db8::1
www         IN  AAAA    2001:db8::1

5.2. Reverse Zone File

Create /var/lib/bind/zones/192.168.1.rev:

$TTL 86400
$ORIGIN 1.168.192.in-addr.arpa.

@   IN  SOA ns1.example.com. admin.example.com. (
            2024121201  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400       ; Minimum TTL
)

; Nameservers
@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.

; PTR records
1       IN  PTR     ns1.example.com.
2       IN  PTR     ns2.example.com.
10      IN  PTR     mail.example.com.
11      IN  PTR     mail2.example.com.
20      IN  PTR     ftp.example.com.
100     IN  PTR     server1.example.com.

6. Understanding the SOA Record

The Start of Authority (SOA) record is critical for zone operation:

Serial number format: Use YYYYMMDDNN format where NN is the revision number for that day.

7. Validate Configuration

Check the configuration syntax:

# Check named.conf
sudo named-checkconf

# Check zone files
sudo named-checkzone example.com /var/lib/bind/zones/example.com.zone
sudo named-checkzone 1.168.192.in-addr.arpa /var/lib/bind/zones/192.168.1.rev

Expected output for valid zones:

zone example.com/IN: loaded serial 2024121201
OK

8. Start and Enable BIND

sudo systemctl enable --now named
sudo systemctl status named

9. Testing

Test your authoritative server:

# Query the server directly
dig @localhost example.com
dig @localhost example.com NS
dig @localhost example.com MX
dig @localhost www.example.com A

# Test reverse lookup
dig @localhost -x 192.168.1.10

# Check SOA record
dig @localhost example.com SOA

# Test AXFR (zone transfer) - should fail from unauthorized IPs
dig @localhost example.com AXFR

10. Reload Without Restart

After making zone changes, reload without full restart:

# Reload all zones
sudo rndc reload

# Reload specific zone
sudo rndc reload example.com

# Check server status
sudo rndc status

Important: Always increment the serial number when modifying zone files!

11. Logging Configuration

Add logging for troubleshooting:

logging {
    channel default_log {
        file "/var/log/named/default.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };

    channel xfer_log {
        file "/var/log/named/xfer.log" versions 3 size 5m;
        severity info;
        print-time yes;
    };

    category default { default_log; };
    category xfer-in { xfer_log; };
    category xfer-out { xfer_log; };
    category notify { xfer_log; };
};

12. Firewall Configuration

Allow DNS traffic:

# UFW
sudo ufw allow 53/tcp
sudo ufw allow 53/udp

# firewalld
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

13. Best Practices

• Run at least two authoritative servers for redundancy
• Use TSIG keys for secure zone transfers between primary and secondary
• Implement DNSSEC for cryptographic validation
• Monitor zone serial numbers to ensure secondaries are synchronized
• Use meaningful serial numbers (date-based format recommended)
• Set appropriate TTLs - lower for frequently changing records
• Keep logs for troubleshooting and security auditing

14. Conclusion

You now have a functioning authoritative DNS server. Key points:

• Authoritative servers only answer for their configured zones
• Disable recursion for security and performance
• Use primary/secondary architecture for redundancy
• Always increment serial numbers when updating zones
• Validate configuration before reloading

In the next posts, we'll cover securing zone transfers with TSIG keys, implementing DNSSEC, and integrating with dynamic DNS updates.