Otherwise a second PiHole set as the secondary DNS in DHCP would keep things online.

No, that just creates time outs and delays when either of them is offline.

The proper way is to have a standby pihole that takes over the IP address of the main pihole when it goes down. It’s quite easy to achieve this with keepalived.

Mental note: have to migrate my gitea instance over to forgejo.

The encryption i was talking about is the encryption of your dns server

You mean encryption between the client and your DNS server, on your local network?

Just wanted to chime in and say that with a pihole you can also have encryption if you point to a local resolver like cloudflared or unbound.

My pihole forwards everything to a cloudflared service running on 127.0.0.1:5353 to encrypt all my outgoing DNS queries, it was really easy to setup: https://docs.pi-hole.net/guides/dns/cloudflared/

DNS-over-HTTPS

You can also do that with running cloudflared or unbound on your pihole.

For me gravity sync was too heavy and cumbersome. It always failed at copying over the gravity sqlite3 db file consistently because of my slow rpi2 and sd card, a known issue apparently.

I wrote my own script to keep the most important things for me in sync: the DHCP leases, DHCP reservations and local DNS records and CNAMES. It’s basically just rsync-ing a couple of files. As for the blocklists: I just manually keep them the same on both piholes, but that’s not a big deal because it’s mostly static information. My major concern was the pihole bringing DHCP and DNS resolution down on my network if it should fail.

Now with keepalived and my sync script that I run hourly, I can just reboot or temporarily shutdown pihole1 and then pihole2 automatically takes over DNS duties until pihole1 is back. DHCP failover still has to be done manually, but it’s just a matter of ticking the box to enable the server on pihole2, and all the leases and reservations will be carried over.

That’s what I do. I do have a small VM that is linked to it in a keepalived cluster with a synchronized configuration that can takeover in case the rpi croaks or in case of a reboot, so that my network doesn’t completely die when the rpi is temporarily offline. A lot of services depend on proper DNS resolution being available.

You can use log2ram to mitigate that.

Alternatively, you can even boot a root filesystem residing on an NFS share, but in the case of a rpi hosting the network’s DNS and DHCP services, you could end up with a chicken and egg problem.