Question on redundancy with rpi4 and Pihole

After seeing the latest video on Pihole plus Synology I felt inspired. I decided to try out Pihole as our works DNS server to replace the default one that comes with our crappy router.

Yesterday I was able to get it all up and running successfully but that got me thinking. How would one go about setting up a second pi with pihole to have as a redundancy option?

Is it as simple as setting the second pi as the routers second DNS server or is there more to it than that?

Thanks!

2 Likes

##edit: see Risk’s post below…##

This.

Set a second one as a second DNS server, and the clients will check it when the first pi goes down.

But, the clients might try the first one for a while, even after it dies, so suddenly “the internet got really slow” as the clients keep querying the first one first.

When that happens, the quickest thing would be to change pi2’s IP to pi1’s IP address, and when you recondition pi1, set it up as pi2…

To extend the life of the pi’s, I would suggest moving the logs to Ram:

which reduces the strain on the OS stick.

Also, if you are using pi4,

Update the firmware, and you can use a cheap, small SSD- it will last longer than a SD card, even a $5 or $10 cheap ssd, like a 60gb or small ssd (larger would work, but save less money) and a cheapish sata to USB cable (might want to look ar UASP cables if it’s gonna be used for storage too)

You might have a look at the link for more ideas:

1 Like

Thank you so much for this Information! I especially appreciate the heads up about ram logs, i’ll be digging into all this info right away!

1 Like

There’s a network protocol called VRRP.

Basic idea is that multiple devices can negotiate with one another such that only one of them has a particular IP address. On Linux, the daemon to implement the protocol is called keepalived.

Without it, some DNS clients will pick the primary IP and wait for up to 3s for a reply before trying the secondary. That means everything slows down by 3s, until the primary DNS server comes back.

By serving a VRRP virtual IP as a DNS address instead, you’ll only have some issues until the virtual IP switches over from one host to another (few seconds) and things will be fine afterwards, the IP of the primary DNS will almost always work this way.

3 Likes

I’m going to try this! I did a little reading and as I understand it the steps are sorta as follows.

  1. Edit /etc/sysctl.conf and add net.ipv4.ip_nonlocal_bind=1

  2. Run sysctl -p

  3. Install keepalived

  4. Edit keepalived.conf on master and backup

  5. Set to same virtual router id and give the master a higher priority

  6. Set the same virtual ip address in each config file and start the service

Does this sound like i’m on the right path?

Regarding net.ipv4.ip_nonlocal_bind=1

Either that, or you let pi-hole listen on all interfaces / bind to 0.

I wrote a guide for OpenWRT wiki back in 2015:

config
vrrp_instance I1 {
  state backup
  interface br-lan
  virtual_router_id 51
  priority 101
  advert_int 1
  virtual_ipaddress {
    10.9.8.4/24
  }
  authentication {
    auth_type PASS
    auth_pass s3cret
  }
  nopreempt
}

A few notes:

  • I like to set both as backup initially with same priority and let one of them take over, YMMV.
  • Test it, as a user would, if it looks fishy it’s probably broken. (e.g. I forget whether a broadcast is sent out when an IP address is assigned in order to flush out/reset various arp caches).
  • Note that keepalived at its simplest will be moving the IP regardless of whether there’s anything listening, so in theory you might end up with the IP stuck onto a host without DNS. This situation is strictly better than not doing keepalived at all. So for bonus points, and if you feel like this is not enough, try setting up a vrrp_script that would keep trying to resolve a DNS name, and then reference it from a track_script config stanza. Also, probably a systemd Requires= rule would already help you enough, not sure how you’ll end up starting PiHole (are you running a container or locally, are you even using systemd or sticking with open-rc).
2 Likes

I’m definitely adding that guide to my bookmarks! I read through it and your guide it’s very straightforward and well written. I’m going to set this up right away!