To guarantee high-availability in your network, it can be useful to operate more than one DNS server in your environment to catch up with any server failures. This is particularly true if you run a public DNS server where continuous access to the service is crucial and where it is not uncommon to have five and more DNS servers at once. Since configuring and managing multiple DNS servers can be time consuming, the BIND DNS server uses the feature of transferring zone files between the nodes so that every DNS server has the same domain resolving and configuration information. In order to do this, we need to define one primary and one or more secondary or slave DNS servers. Then we only have to adjust our zone file once on the primary server which will transfer the current version to all our secondary servers, keeping everything consistent and up-to-date. For a client it will then make no difference which DNS server they are connecting to.
To complete this recipe, you will require at least two CentOS 7 servers in the same network which can see and ping each other. An Internet connection will be required to download and install the BIND server software on all the computers we want to include in our DNS server farm. In this example, we have two servers, 192.168.1.7
which is already installed and configured as a BIND server, and 192.168.1.15
which will be our second BIND server within the subnet 192.168.1.0/24
. You should also have read and applied the zone file recipe from this chapter and created a forward and reverse zone file because this is what we want to transfer between DNS servers.
We begin this recipe by installing BIND on every CentOS 7 computer we want to include in our BIND DNS server cluster. To do this, follow the recipe Setting up an authoritative-only DNS server for all the remaining systems. Before we can start, we need to define which server will be our primary DNS server. For simplicity in our example, we will choose the server with the IP address 192.168.1.7
. Now let's make all our DNS server nodes aware of their role.
vi /etc/named.conf
192.168.1.15
, change accordingly):allow-transfer { 192.168.1.15; }; notify yes;
listen-on
directive to include the DNS server's primary network interface (in our example 192.168.1.7
, so change appropriately):listen-on port 8053 { 127.0.0.1;192.168.1.7; };
8053
in your server's firewall (or create a firewalld service for it, see Chapter 6, Providing Security):firewall-cmd --permanent --zone=public --add-port=8053/tcp --add-port=8053/udp;firewall-cmd --reload
/var/named/centos7.home.db
and /var/named/db.1.168.192
, to include our new secondary DNS server. In the forward zone file, add the following lines (you can also use the nsupdate
program to do this) into the appropriate sections:NS ns2.centos7.home. ns2 A 192.168.1.15
NS ns2.centos7.home. 15 PTR ns2.centos7.home.
named-checkconf && systemctl restart named
For simplicity and to demonstrate, just install named
on any server you want to use as a BIND slave (we only show the important configuration here):
yum install bind; vi /etc/named.conf
include /etc/named.rfc1912.zones
;. Immediately following this line, create a space for your work and add the following zones (replace the zone and file names appropriately):zone "centos7.home" IN { type slave; masters port 8053 { 192.168.1.7; }; file "/var/named/centos7.home.db"; }; zone "1.168.192.in-addr.arpa" IN { type slave; masters port 8053{ 192.168.1.7; }; file "/var/named/db.1.168.192.db"; };
named
to write into its zone file directory before restarting BIND:chown :named /var/named -R; chmod 775 /var/named -R setsebool -P named_write_master_zones 1 named-checkconf && systemctl restart named
rndc refresh centos7.home.
ls /var/named/*.db
dig @127.0.0.1 client2.centos7.home.
In this recipe, we showed you how to set up secondary BIND servers in your network which can help in increasing the stability and availability of your DNS server system.
So what did we learn from this experience?
We started our journey by deciding which of our servers should be the primary and which should be the slave DNS servers. Then we opened the BIND main configuration file on the primary server and introduced two lines of code to configure our server to be the head of our DNS cluster. The allow-transfer
directive defines to which clients we want to transfer our updated zone files while the notify yes
directive enables automatic transfer when any changes to the zone files happen. If you have got several secondary BIND DNS servers, you can add more than one IP address into the allow-transfer
directive, separated by semicolons. Then we opened our zone files we created in a former recipe in this chapter and introduced a new line IN NS <IP address>
which defines the IP address of our secondary DNS servers we need to be aware on every DNS node in our system. If we have got multiple servers, then we introduce multiple IN NS
lines. Finally, we introduced a small comment to easily check the successful zone file transfer on our secondary servers.
Afterwards, we configured our slave DNS server(s). Here we introduced the same zone file definitions as on the primary server's BIND configuration, with the exceptions that we used type slave
instead of master to denote we are a secondary DNS server and will get a copy of the zone files from the master node by defining the primary DNS server's IP address using the masters
directive (please do not forget that our master BIND is listening on the non-default port 8053
in our example).
Since we had not created or copied the zone files ourselves on the slave DNS server, it was then easy to check if the zone file transfer had been successful after restarting the BIND service using the ls
command. Finally, we verified the transferred zone file content by running test queries using dig
or nslookup
to see if we could resolve the same local hostnames on our secondary DNS server. Remember if you later make changes to your master's zone files you have to increase their serial
number in order that those changes get transferred to all your slaves.