I now have two Pi-holes on my network instead of one, and if you have the spare resources, I highly recommend it

I've been building out a lot of my home network for the past few months, deploying OPNsense on my Ugreen NAS, investing in a managed switch, and generally just taking control of as much of my network as possible. That's included the deployment of a Pi-hole, for the obvious tracking and advertisement benefits, but also the ability to deploy local resolution for domains that I would use to access my self-hosted services externally. With that said, I've now opted for two Pi-holes instead of one, and if you have the spare resources, I highly recommend it.

The idea for this came about following a weird evening where services all stopped working one by one, and the staggered nature of it threw me off in diagnosing the issue. It was then that I realized my Pi-hole had gone down, and DNS resolution had stopped working. This also explained the staggered nature of the dropouts; cached DNS responses were still working until they were emptied from the cache, and there was no way for my devices to resolve a domain to an IP address once that happened.

As a result, I've now deployed a second Pi-hole on my TrueNAS machine, and while this may seem like a strange solution, there are a few reasons for it. Not only does it prevent my entire network from going down should it happen again, but deploying two Pi-holes allows for some pretty neat networking tricks, too.

Redundancy is key

A second DNS server ready to go

The biggest benefit of a second Pi-hole is simply redundancy. I have one deployed in a Proxmox LXC and one deployed on my TrueNAS machine, and the resource usage for one is so low that there's no reason not to deploy a second one if you have the facilities to do so. On most devices, you can't just set your primary DNS as your Pi-hole and your secondary DNS as a third-party provider like Google or Cloudflare, so if your primary DNS fails with no alternative, you're just not going to be able to get online.

As for why you can't just set two separate DNS servers like that, many devices will simply use whatever DNS server replies first when configured by the DHCP, and it's not a case of simply making requests in order of primary and secondary DNS. While Windows will prioritize the first DNS provider, systemd-based Linux distributions will enact a "parallel probe" of all servers and pick the fastest responder. The same goes for Android, macOS, and iOS, where all servers are questioned at once, and the fastest to answer is considered correct. If you can only deploy one instance of a Pi-hole, you may need to use it as your only DNS provider, depending on the devices you use.

So, having a second Pi-hole saves me when one goes down, or if I need to reboot the device it's running on, or perform any kind of maintenance. When it was running on Proxmox, a system update or any other kind of tinkering could mean that DNS requests were suddenly unresolvable, which obviously isn't ideal. My DNS server is also distributed to devices via my DHCP, so every device uses it. It's not so much a big deal if it's defined on a per-device level, but that's annoying to set up and maintain.

Any critical service shouldn't have a single point of failure, and that's what a second Pi-hole achieves. Anything that can run it will do the job, and you can mirror your Pi-hole configuration to a second instance easily. You can manually manage it, or you can use a tool like Nebula Sync to keep them synchronized.

A second Pi-hole can give you more control, too

Smart DNS and more

The biggest benefit of having two Pi-holes is the ability to designate specific controls based on devices. While you can set up client groups for blocklists, these do not extend to upstream requests and require disabling caching to work effectively. With two Pi-holes, one could use OpenDNS Family Shield, and the other could use a regular upstream resolver, where certain devices are only assigned the former through DHCP. The same applies if you wanted to use a Smart DNS for content unblocking; a second Pi-hole could be used specifically for it, allowing the first to work normally.

In that same vein, you could also use one Pi-hole specifically for blocking known domains relating to malware as well as all of your usual blocks, and the second Pi-hole could then be used for regular blocking. While this means devices that use both might not always block them (again, it may depend on which simply replies faster), but you can designate just one for a specific device that may be mission critical and requires heightened security.

I just use two Pi-holes for redundancy and failover, but there are many ways to make use of more than one if you want to play around with it. Given how a Pi-hole has very little footprint when it comes to resources on practically any device, it's worth deploying a second one and playing around with it if you're curious!