BIND 9: Configure Slave Zones

BIND 9: Configure Slave Zones

Today we are going over one of the fundamental aspects of administering a DNS infrastructure, that is maintaining consistency across multiple replicas.  The simplest method of accomplishing this is to have a master/slave relationship.  Essentially you have a read-write (master) copy and a read-only (slave) copy of the zone.  The slave looks to the master for information on changes.

Basic BIND Configuration

Here we are going to look at the key components of a BIND configuration, this should be the same regardless of if this is a master or a slave server.

# cat /etc/named.conf
options {
 directory "/var/named";
 version "unknown";
 pid-file "/var/named/named.pid";
 auth-nxdomain no;
 forwarders { 8.8.8.8; 8.8.4.4; }; // these are the forwards to be used for all non-authoritative queries.
 allow-transfer { "none"; }; // this is always none, we enable transfers on a zone-by-zone basis in each zone definition.
 allow-notify { "none"; }; // this is always none, we enable notifications on a zone-by-zone basis in each zone definition.
 allow-recursion { 127.0.0.1; 192.168.1.0/24; }; // include all networks you want to be able to recursively perform queries.
 notify explicit; // this turns off the default behavior of all servers sending notifies to all servers with an NS record.
 also-notify { 192.168.1.12; 192.168.1.13; }; // this turns on notifications for specific servers (so master would notify slaves).
};

Creating Acl Statements

Here we can get a little more fancy.  The acl statement is primarily for BIND views, however it also works as short hand for repetitive items.  Here we are going to use it to define the CIDR notation of our slave servers.

 acl slaves { 192.168.1.12/32; 192.168.1.13/32; };

Required Zones

Now we get into setting up our required zones.

zone "." {
 type hint;
 file "root.servers";
};

zone "localhost" {
 type master;
 file "localhost.db";
 allow-update{ none; };
};

zone "0.0.127.in-addr.arpa" {
 type master;
 file "localhost.rev.db";
 allow-update{ none; };
};

Configure Master Zones

Here is the definition for our master zones, in this case domain.local and 192.168.1.x.  I have not included the zone files themselves, but as long as you have a working zone file you can use this method to keep it in sync across multiple servers.

# cat /etc/named.conf
zone "domain.local" {
 type master;
 file "master/domain.db";
 allow-transfer { slaves; };
};

zone "1.168.192.in-addr.arpa" {
 type master;
 file "master/192.168.1.rev.db";
 allow-transfer { slaves; };
};

Configure Slave Zones

Define our slave zones.  Here we need to define where the master is and what servers we allow to notify which in this case is the master(s).  Another thing to notice is that the file location is not in the standard location.

# cat /etc/named.conf
zone "domain.local" {
 type slave;
 file "/var/cache/named/domain.db";
 masters { 192.168.1.11; };
 allow-notify { 192.168.1.11; };
};

zone "1.168.192.in-addr.arpa" {
 type slave;
 file "/var/cache/named/192.168.1.rev.db";
 masters { 192.168.1.11; };
 allow-notify { 192.168.1.11; };
};

When dealing with slave zones, it is really important to remember that you have to be very disciplined about updating the serial numbers in the zone files.  The numbering scheme really doesn’t matter as long as it always goes up, but I tend to use YYYYMMDD## so the first update of June 24 2014 would have a serial number of 2014061401, the second would be 2014061402, and on and on.

Check Your Configuration

We can use the named-checkconf utility to parse the configuration and ensure that it is correct (from a syntax and structure perspective).  There is also one for the zones named-checkzone.

# named-checkconf /etc/named.conf