Home Lab Build – Part 4: Pi-Hole

Some Background

Pi-Hole acts as a DNS sinkhole and is a great solution for blocking any unwanted content such as ads within your network. Some might argue that this can be achieved using browser plugins however this is application specific and only applies to network traffic within the browser and isn’t supported across all devices. Pi-Hole works at the network level meaning it applies to any device on the network with no software to install.

I’ve been using Pi-Hole in my home network long before starting up my home lab and it works just perfectly! Since the footprint for running Pi-Hole is very small, I have it running on a first gen Raspberry Pi and being a Linux based OS, its stability is rock solid. Performing such a crucial role, my only concern has always been the fact it is a single point of failure. Without it there is no DNS resolution which means most devices on the network stop working and my smart home is suddenly not very smart anymore! I needed some redundancy built in to allow for hardware failure and it turns out that is entirely possible using Gravity Sync and Keepalived

Redundant Pi-Hole Instances

So how does this work? You build yourself a second Pi-Hole server which will be kept in sync with the first one using Gravity Sync – a Pi-Hole specific replication application. Next we use Keepalived to allow for an almost seamless IP failover to the secondary Pi-Hole if the primary ever fails.

Gravity Sync will replicate most of the Pi-Hole data such as adlists and DNS however there a few things it doesn’t replicate:

• Modify or sync the individual Pi-hole’s upstream DNS resolvers.
• Sync individual Pi-hole DHCP scoping information or leases.
• Merge query logs, statistics, long-term data, caches, or other resolution information.

The first 2 items in the list didn’t apply in my case since I don’t use the DHCP functionality and my upstream DNS resolvers will never change. The third item on the list relates to ad block related data. For example, the dashboard and query log of the secondary Pi-Hole instance will not display any data unless it becomes active. This shouldn’t come as a dealbreaker and is a small price to pay for continuous uptime.

For my setup I built a new primary Pi-Hole instance as a VM running on my NUC, with the Raspberry Pi running as the secondary to cater for hardware failure.

Setup

I must admit there are a number of steps to get this working but once everything is in place it really is a case of set and forget. Rather than regurgitate the process step by step, there is a fantastic writeup over at David’s Homelab which I used and covers the entire process end to end.

Since I already make use of Pi-Hole’s local DNS feature, I also added a new record for the virtual IP address (for example “pihole”). This makes managing things much simpler as accessing the Pi-Hole webpage (“http://pihole” in this case) will always open the active instance.