BIND DNS servers are surprisingly resilient, but achieving true high availability means understanding how they fail and how to build redundancy around that failure.
Let’s see BIND in action with a basic primary/secondary setup.
Primary DNS Server (dns1.example.com)
# /etc/bind/named.conf.local
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 192.168.1.2; }; // IP of the secondary server
};
; /etc/bind/zones/db.example.com
$TTL 3600
@ IN SOA dns1.example.com. admin.example.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
@ IN NS dns1.example.com.
@ IN NS dns2.example.com.
@ IN A 192.168.1.1
dns1 IN A 192.168.1.1
dns2 IN A 192.168.1.2
www IN A 192.168.1.10
Secondary DNS Server (dns2.example.com)
# /etc/bind/named.conf.local
zone "example.com" {
type slave;
file "/var/cache/bind/db.example.com"; // Where BIND will store the zone transfer
masters { 192.168.1.1; }; // IP of the primary server
};
After starting BIND on both servers (sudo systemctl start bind9), you’d see dns2 pull a copy of db.example.com into its cache directory. If you query dns2 for www.example.com, it will respond. If dns1 goes down, dns2 continues to serve the zone.
This setup solves the problem of a single point of failure for DNS resolution within your domain. The primary server holds the authoritative, editable copy of the zone data. The secondary server(s) act as read-only replicas, receiving updates via zone transfers. When a client queries for a record in example.com, it can query either dns1 or dns2. If dns1 is unavailable, clients can still reach dns2 and get the necessary DNS information.
The key components are the type master and type slave directives in named.conf.local, and the allow-transfer directive on the master pointing to the slave’s IP. The masters directive on the slave tells it where to fetch the zone from. The serial number in the SOA record is crucial; BIND checks this to know if the zone has been updated and a transfer is needed.
The NS records in the zone file tell the world which servers are authoritative. For true high availability, you’d want to register both dns1.example.com and dns2.example.com as name servers with your domain registrar. This means that if your primary DNS server is unreachable, the global DNS system still knows about your secondary server and can direct queries to it.
Beyond a simple primary/secondary pair, you can add more secondary servers for increased redundancy and load distribution. These additional secondaries also pull their zone data from the primary. If you have multiple secondaries, the allow-transfer on the primary would list all their IPs.
One aspect that often trips people up is how BIND handles zone transfers. It’s not a real-time push; it’s a pull mechanism initiated by the slave. The slave periodically checks the primary’s SOA record (based on the refresh interval). If the serial number on the primary is higher, the slave requests a full zone transfer (AXFR) or an incremental zone transfer (IXFR) if supported and applicable. This means there’s a small window of time (up to the refresh interval) where the secondary might not have the absolute latest record if the primary has been updated very recently.
To distribute load and improve resilience against network partitions or individual server failures, you’d typically implement round-robin DNS or use a dedicated load balancer in front of your DNS servers. For clients to benefit from multiple authoritative servers, you need to ensure your domain registrar is configured with all your authoritative name servers (e.g., dns1.example.com and dns2.example.com).
The next hurdle is managing DNSSEC signing across multiple servers, which adds a layer of complexity to zone updates.