Day 3: Research Pi-hole
This is a fairly light day. It is my first day back at work after being out of the office for a couple of weeks so my energy level is fairly low.
Goals
- Begin researching/tinkering with Pi-hole
Findings/Results
- I have used Pi-hole in the past and it worked pretty well, but the SD card on the Pi I was running it on died and I never set it back up. It suffered from only having a single instance so if I did any maintenance I’d need to update the network configuration to use an alternate DNS provider to avoid outages. I also used cloudflared to do DNS-over-HTTP using Cloudflare as my DNS provider. This time I’d like to do a few different things to make this more robust:
- Deploy Pi-hole on Kubernetes to allow me to have multiple instances
- This Helm chart looks like a good starting point.
- Setup a Kubernetes cron job to use gravity-sync to keep the replicas in sync with the primary Pi-hole node.
- Use my newly configured Rook-managed Ceph cluster for storage.
- Use the virtual IP address I setup for the k3s Kubernetes API to ensure that I have a resilient way to access Pi-hole. I think I can get by with a single VIP for both Kubernetes and Pi-hole since the routing will not work if I lose Kubernetes.
- I would like to explore deploying
unboundinstead ofcloudflaredthis time around. Both handle upstream DNS resolution, butunboundwould run on my cluster so I can be sure the DNS logs are not available outside of my network unless I decide for them to be.- Article from Pi-hole on this subject
- There are not very active pre-existing Helm charts for deploying
unbound, but I think this one from pascaliske looks like a good starting point. -
When I get this working it might be worth contributing on this GitHub issue. It mentions wanting to document how to configure both tools to work together so it would be a good place to share what I learn.
- Deploy Pi-hole on Kubernetes to allow me to have multiple instances