Set Up Multiple Pi-Holes with Redundant DHCP

This guide might help you to configure a dual Pi-hole setup, to ensure that your devices always have multiple Pi-hole DNS servers available and that DHCP fallback is working properly.

Why Two Pi-holes?

  • Redundancy. Using two Pi-holes ensures your network’s DNS is always available, even if one Pi-hole goes down. There are several reasons why this setup is beneficial:

  • Continuity: If one Pi-hole fails or is offline for maintenance, the other Pi-hole continues to serve DNS requests, keeping your network operational.

  • Hardware Limitations: Most people use Pi-hole on Raspberry Pi devices, which are not “enterprise-grade” systems and are prone to failure. For example, frequent write activity can degrade the SD cards in these devices over time.

  • Preventing Bypass: If your Pi-hole is the only DNS server and goes offline, some devices will switch to hardcoded backup servers, often from public DNS providers. These servers won’t offer the privacy protections and ad-blocking features of Pi-hole.

  • Unintended Backup DNS Usage: Some people intentionally set public resolvers as backup entries in DHCP, thinking they’ll only be used if Pi-hole is unavailable. However, many devices will randomly choose between primary and secondary DNS, defeating the purpose of Pi-hole’s filtering.

  • IoT Devices and Smart Home Gear: Home automation systems, smart TVs, and IoT devices are common offenders here. In my own environment, about 10% of queries are directed at the secondary Pi-hole, and these devices often have a much higher rate of blocked queries compared to the primary.

Using multiple DHCP servers

While using multiple DHCP servers in the same network is generally discouraged, it can work well if configured correctly. Issues arise when DHCP servers distribute conflicting information, but by coordinating the settings between Pi-hole #1 and Pi-hole #2, you can avoid these problems.

Client DNS Handling

Keep in mind that the terms “primary” and “secondary” DNS are somewhat misleading. Most DNS clients don’t strictly prioritize the first server over the second. Instead, they might use both servers simultaneously, favor the one with the fastest response time, or only switch to the secondary if the primary is unresponsive. As a result, even with this setup, expect around 70% of queries to go to the primary Pi-hole and 30% to the secondary, depending on the clients’ behavior.

By following this configuration, you’ll have a resilient setup that keeps DHCP active and ensures DNS availability even if one Pi-hole goes down. As long as both Pi-holes aren’t offline simultaneously, your network should continue functioning smoothly.

Step-by-Step Guide

1: Configure DHCP on Your Router

First, disable the DHCP server on your router. If you can’t completely turn it off, configure its DHCP range to a single IP address, preferably reserved for one of the Pi-holes that’s always active. This prevents the router from distributing conflicting DHCP information.

2: Assign Static IPs to Your Pi-holes

Both Pi-holes need static IP addresses, configured manually (not just reserved via the router’s DHCP). This setup is crucial to ensure they always have predictable addresses for network devices to rely on.

Example:

  • Router: 192.168.1.1
  • Pi-hole #1: 192.168.1.10
  • Pi-hole #2: 192.168.1.20

3: Enable DHCP on Pi-hole #1

Enable the DHCP server on Pi-hole #1, setting a range for your devices, such as 192.168.1.100-149. By default, this Pi-hole will act as your primary DNS and DHCP server for the devices in this range.

Next, create a configuration file (/etc/dnsmasq.d/08-custom-dhcp.conf) on Pi-hole #1 with the following content:

dhcp-option=6,192.168.1.10,192.168.1.20

This configuration tells Pi-hole #1 to distribute both its own IP (192.168.1.10) and Pi-hole #2’s IP (192.168.1.20) as DNS servers. As a result, clients receiving IPs from this Pi-hole will have both DNS servers set up, ensuring they can switch if one goes offline.

4: Enable DHCP on Pi-hole #2

Now enable the DHCP server on Pi-hole #2 with a separate range, for example, 192.168.1.150-199. Using distinct ranges makes it easier to track which Pi-hole provided the IP address to each client. Technically, you could use the same range, but it’s recommended to avoid overlaps for clarity and troubleshooting.

Create the same configuration file (/etc/dnsmasq.d/08-custom-dhcp.conf) on Pi-hole #2, but swap the order of the DNS servers:

dhcp-option=option:dns-server,192.168.1.20,192.168.1.10

This file prioritizes Pi-hole #2 as the primary DNS and Pi-hole #1 as the secondary. This way, if Pi-hole #1 goes down and more devices connect through Pi-hole #2, they’ll default to using Pi-hole #2 as the primary DNS.

5: Adjust DHCP Lease Times for Faster Failover

If one Pi-hole goes down, clients connected to that Pi-hole will keep the existing DNS settings until their DHCP lease expires. To reduce this delay, you can shorten the DHCP lease time in each Pi-hole’s web interface. This setting ensures that clients renew their leases more frequently and switch to the active Pi-hole’s DNS configuration more quickly when the primary Pi-hole goes down.

Syncing configurations

To keep most of your configurations in sync, consider using a tool like Pi-hole Cloudsync. pihole-cloudsync allows you to designate a primary Pi-hole for managing settings. It uploads adlists, blocklists, custom DNS names, and CNAMEs to a private Git repository, while secondary Pi-holes download these files to stay in sync. This setup ensures centralized configuration management across multiple Pi-holes. It works with any Git repo accessible to your Pi-holes.