Adventures in PiHole

You really need more than one DNS server. DNS is such a vital service that when – not if – your local DNS cache dies you'll be dead in the water and puzzled for some time before you FINALLY realize that the cat turned off the Raspberry Pi running PiHole or Blockblock.

The problem, however, is replication. If you only use blocklists, you can just set 'em both up to use the same block list and Bob's your uncle. But if, like me, you use the local dnsmasque features of pihole for “split dns” functionality, you need a bit more.

rqlite

rqlite is a raft-elected distributed database with databases that are readable by sqlite3. So I got the brilliant idea (LOL) of setting up rqlite replication between the piholes. I fought with it for a bit, and eventually got it to replicate, but once replication was working I couldn't get rqlite to notice changes to the DB and replicate 'em, even though I used the —on-disk flag.

So then I considered re-factoring pihole to use the rqlite libraries directly. While researching this idea, I came across gravity-sync.

gravity-sync

gravity-sync is a set of scripts that sync the important databases in the /etc/pihole directory. It's smart, so it only replicates changes, and it seems reliable enough. It has automation, so you can synchronize the databases every fifteen minutes ( which I do ). This means you need to make changes to the primary DNS first or you'll get differential resolution for fifteen minutes. I've sometimes resorted to doing a manual sync after a change, but thus far it's been the only issue I've encountered with gravity-sync.

Conclusion

Documentation on gravity-sync is good, installation is simple; it's my recommendation until such a time as I feel ambitious enough to fork pihole and refactor it to use rqlite or dqlite for databases.