In Chapter 6, Configuring Network Services, we set up DHCP and DNS servers. This is great, but unfortunately there's one major problem. Either one is a single point of failure. If the DHCP server were to go down, new devices wouldn't be able to receive an IP address, and clients that are currently connected will drop off the network as their current IP lease expires. If the DNS server were to go down, clients wouldn't be able to reach destinations by the hostname. Depending on the scope of your network, this downtime might be hard to deal with, so having redundancy for these services may be a good idea.

With a DHCP server configured for redundancy with another server, it will synchronize its list of IP addresses that were issued, and each will detect if the other stops responding. In this case, the secondary would take over the task of issuing new IP addresses. With DNS, it's just a matter of adding another DNS server on your network, but I'll talk more about that in just a bit.

Let's start with adding redundancy to our DHCP server. The initial one that was created earlier can be considered the primary server for the sake of simplicity. The next thing you would do is create another server to serve as the secondary. This can be another physical server or even a VM, the choice is yours. Install isc-dhcp-server as we discussed in Chapter 6, Configuring Network Services. Once you have the second server stood up, we can begin.

Starting on our primary node, we should add some additional code to our /etc/dhcp/dhcpd.conf file. I've bolded the lines of configuration that are new and for the purpose of adding redundancy:

default-lease-time 86400;
max-lease-time 86400;
option subnet-mask 255.255.252.0;
option broadcast-address 10.10.99.255;
option domain-name "local.lan";
authoritative;
failover peer "dhcp-failover" {
  primary; 
  address 10.10.96.2;
  port 647;
  peer address 10.10.96.1;
  peer port 647;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
  mclt 3600;
  split 128;
}
subnet 10.10.96.0 netmask 255.255.252.0 {
  option routers 10.10.96.1;
  option domain-name-servers 10.10.96.1;
  pool {
    failover peer "dhcp-failover";
    range 10.10.99.100 10.10.99.254;
  }
}

range 10.10.99.100 10.10.99.254;

For the most part, the same configuration we've done on our primary server can be copied over to the secondary. Feel free to use the /etc/dhcp/dhcpd.conf file we have here as a base for starting the configuration on the second server. Again, I'll highlight what's different between the two. The code is as follows:

default-lease-time 86400;
max-lease-time 86400;
option subnet-mask 255.255.252.0;
option broadcast-address 10.10.99.255;
option domain-name "local.lan";
authoritative;
failover peer "dhcp-failover" {
  secondary; 
  address 10.10.96.1;
  port 647;
  peer address 10.10.96.2;
  peer port 647;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
}
subnet 10.10.96.0 netmask 255.255.252.0 {
  option routers 10.10.96.1;
  option domain-name-servers 10.10.96.1;
  pool {
    failover peer "dhcp-failover";
    range 10.10.99.100 10.10.99.254;
  }
}

mclt 3600;
split 128;

You should notice that the address of the primary and secondary are reversed in each. In the first configuration file, the primary is 10.10.96.1 and the secondary was set to 10.10.96.2. In the second, this was changed to 10.10.96.2 and 10.10.96.1, respectively. Also, pay careful attention to the IP addresses, subnet mask, and any other value that would likely be different from one network to the next. If you start the DHCP service on both your servers (on Debian, it's isc-dhcp-server, and on CentOS it's dhcpd) you should see them communicate via the logs. The specific logs to check would be /var/log/syslog in Debian-based systems and /var/log/messages in CentOS systems. You can easily test if this is working, by disabling the DHCP service on one of the servers and you should see the other issuing IP addresses in its place.

Now that we have redundancy configured for DHCP, let's do the same for DNS. In fact, this is a great deal easier. All you have to do is designate another server to act as your secondary DNS server (you can create a new machine, or just add it to your secondary DHCP server) and then copy over your configuration files and zone files to the new server. Again, Chapter 6, Configuring Network Services, has all the relevant details for these files. If you want to save a bit of time, you could even just clone your original DNS server into a new machine, which is easy to do if you're using virtualization or understand how to use the dd command. After whatever method you prefer for creating the secondary server and copying your zone files over, test that DNS is working on the new server. Once it is, we turn back to our DHCP configuration to deploy this secondary server to all of our nodes.

In our /etc/dhcp/dhcpd.conf file, look for the following line:

option domain-name-servers 10.10.96.1;

Change it to the following:

option domain-name-servers 10.10.96.1, 10.10.96.2;

You're done. Now, every time your clients' lease expires or they request a new IP address, they'll automatically be provided the secondary DNS address.

The only thing left to do at this point is to configure any nodes you may have set up with static IP addresses to use the secondary DNS server. As I've mentioned somewhere in the neighborhood of a thousand times by now, I highly prefer static leases (reserving IP addresses for various nodes on the DHCP server) to manual static IP assignments for this reason and more. You only need to configure them in the DHCP server. But if you do have any nodes you've configured networking by hand (to each their own), just update their init scripts. Again, you'll find this configuration in /etc/network/interfaces (Debian) or /etc/sysconfig/network-scripts/<if-name>.cfg (CentOS).