1. Introduction
Usually, when we design a new network, we want to make it as resilient as possible. Nevertheless, we may have services that still have single points of failure. This means that if they have issues, outages may happen. So, one of the concerns is whether it’s possible to have multiple DHCP servers on the network. In this article, we’ll discuss how to do it and why we should bother.
2. About DHCP
At first, we must define DHCP. It stands for Dynamic Host Configuration Protocol, defined on IETF RFC 2131 and its many extensions. On IPv4, DHCP is the main form of distributing host configuration. Of course, it’s an essential service. It can avoid the laborious work of configuring each network. Hence, it can manage each host’s IP address, network masks, DNS server address, network routes, and proxy, among others. In order to do that, DHCP works by temporarily leasing IP addresses to clients from a pool of addresses. After the leases expire, the addresses go back to the address pool and are reused. One of the first misconceptions we may have is that each network must have only one DHCP server. That’s far from true. This notion comes from the fact that we can’t, as a rule, have two hosts on the network using the same IP address. If we do, we’ll see address conflict errors. Also, a rogue DHCP server is one of the ways to attack it. As DHCP can send DNS, route, and proxy information, it can trick the hosts into man-in-the-middle fake servers.
2. Basic DHCP Configuration and Its Single Point of Failure
Let’s start from the basics. On simple or non-critical networks, it’s usual practice to configure a single DHCP service. Often, the service can even run on appliances such as switches or routers. On Linux, the more common open-source software packages for DHCP are:
- dhcpd — This is standard in many distributions, has a lot of features, and is on active duty in many enterprises.
- dnsmasq — This is a great choice for lightweight deployments, especially with IoT and SoC as servers. It has DHCP, DNS, TFTP, and PXE on a conveniently low-footprint server.
Microsoft added its own DHCP server implementation on Windows Servers, which is also quite widespread in enterprises. Let’s see review the DHCP workflow: 
- The client sends a broadcast DHCP Discover packet. It also sends the last address it had, if any.
- The server responds with a DHCP Offer. It can renew the last lease, or just send a new one.
- The client broadcasts a DHCP Request to accept the offer.
- The server sends a DHCP Acknowledge confirming the lease.
3. DHCP Issues
For a service that’s still massively used, DHCP has a lot of issues. First, DHCP doesn’t support any form of strong client and server authentication. This means that fake (rogue) servers may send false offers pointing client hosts to malicious routers, DNS, or proxy servers. This opens a vector for man-in-the-middle attacks. On the other hand, malicious clients could flood the server with successive fake negotiation requests. As a result, the server’s address pool may become depleted, rendering it unable to lease new addresses to valid users. This is one of the usual DHCP denial-of-service attacks. In conclusion, if the server fails, clients don’t receive address leases or renewals. So, they won’t be able to correctly interact within the network. The only temporary safeguard against this is setting a longer lease time. The lease time can be high enough so that short DHCP service failures don’t affect clients with valid leases. But, this is hardly enough. Because of these shortcomings, all major enterprise-grade switches have at least some form of DHCP attack protection. For instance, we can specify which ports may have DHCP servers. That way, client packages are broadcast only to them, and no other port may send DHCP server messages. Some may even monitor and throttle down clients that aggressively send DHCP Discover messages, or ports using too many MAC addresses.
4. Multiple Servers: Benefits and Cautions
Many of those issues could be avoided if we could have more DHCP servers on the network. Fortunately, we can. If there are multiple servers on the same network, the client will receive multiple offers. Then it will choose and respond to only one. However, the problem is that there is no standardized way for one server to share its state with others. So, if their pools contain the same addresses, they can be offered to different hosts. That’s why there are some strategies we can use to reduce these risks. We can even use more than one strategy according to our needs:
- Create subnetworks: Each subnetwork has its own DHCP server. This can help reduce broadcast overhead, lower collision risks, and, of course, limit the universe of affected clients, in case of a DHCP service failure.
- Create a failover configuration: The main DHCP server has a standby server that takes its place in case of failure. Some DHCP servers such as the ISC have native support for it. But it can be also done using fail-over clusters with shared storage among nodes.
- Split the address pools between multiple DHCP servers: All are online, providing the DHCP offers with non-overlapping address pools. If one fails, the other keeps the service on. No modification to the network is needed, nor do we need a fancy clustering configuration. The drawback is that if only one server is up, its address pool must be large enough to accommodate all customers.
The last technique is good enough for most scenarios. Just remember to correctly configure the DHCP option that advertises the default route. By the way, with multiple DHCP servers, we can advertise different default gateways for the same network without the need for dynamic routing protocols. To tune the gateway being advertised we must add the following options to the configurations files: In dhcpd, editing the dhcpd.conf with the option routers:
subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
default-lease-time 600 max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 239.252.197.255;
option routers 239.252.197.1;
option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
}
In dnsmasqd, editing the dnsmasqd.conf:
# Define the subnet
dhcp-range=239.252.197.10,239.252.197.250,255.255.255.0,2h
# DNS configuration
server=239.252.197.2
server=239.252.197.3
dhcp-option=option:domain-search,isc.org
# Default router
dhcp-option = option:router, 239.252.197.1
5. Conclusion
In this tutorial, we explored some basics of how DHCP works, and we acknowledged some of its risks. That was necessary to assess the advantages of having multiple DHCP servers on the network. Our businesses are becoming more and more dependent on stable network services, to the point that even minor outages can impact our results. Reducing the points of failure and getting higher resilience from our infrastructure, especially when it can be done with little effort, is always valuable.