Note: replace @ip_master with the IP Address of the Primary. The zone file must be in /var/cache/bind/ because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in /etc/apparmor.d/usr.sbin.named).

Restart the server, and in /var/log/syslog you should see something similar to:

Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.

Testing

Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.

Chrooting BIND9

Chrooting BIND9 is a recommended setup from a security perspective if you don't have AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need. AppArmor is installed by default on recent Ubuntu releases. Unless you've explicitly disabled AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you'll need this information, which isn't covered in the instructions that follow here.

To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below

Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

$ sudo chown bind:bind /chroot/named/etc/namedb/slave

This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.