Once I’d got my Raspberry Pi back up and running, one of the things I was desperate to try out was Pi-Hole, a DNS sinkhole capable of running even on my extremely old Pi. DNS sinkholes make it possible to block ads, trackers and malware at source, speeding up browsing and improving privacy. The particular advantage of a Pi-Hole is that it cannot operate at the network level, blocking ads automatically on every device that connects to a WiFi network. Well, it’s got to be worth a go, right?
Installing Pi-Hole was surprisingly straightforward. Reserving DNS addresses on my router seemed surprisingly buggy, so I simply selected a target static IP address high enough that it was unlikely to ever be reached by my router’s built in DHCP.
Once I had established that that was working, I went ahead and beefed up the blacklists (i.e. the list of domains that should be blocked) using this helpful tool. The default settings are pretty cautious, but since I am around most of the time to fix the odd issue it makes sense for me to take a slightly riskier approach.
Next, I installed cloudflared and enabled it using this walkthrough (using the ARM variant). Unfortunately I encountered a segmentation fault when trying to run the daemon, but reverting to 2018.7.2 fixed that, which was great (see edit). Using cloudflared enables DNS-over-HTTPS, which is great, albeit at the expense of reliance on Cloudflare, a private company. Mozilla’s been grappling with the same conundrum and I concluded, on balance, that since I was going to be reliant on a third party anyway, I might as well be reliant on CloudFlare. Ironically, Mozilla’s implementation, once enabled by default, will conflict with pi-hole, so I’ve gone ahead and disabled it.
So far I’ve been manually configuring devices to use Pi-hole. This is problematic for a number of reasons, not least because (a) every time I get a new device I’d need to configure it (b) some devices, usch as smart TVs, cannot be configured in this way and (c) it’s difficult to configure, say, a phone to work with the Pi-hole when connected locally but not when out and about. The primary method of enabling network-wide coverage (changing the default DNS provider in my router’s settings) is blocked to me. However, once I’m confident in the Pi-hole I should be able to turn off DHCP on the router and have the Pi-hole take on that function, allowing it to configure the default DNS itself. As an easy defense against DHCP issues I’ve also preconfigured known-good static IPs for several local devices, again using higher numbers than should ever be allocated automatically.
There are a few other things I’ll be considering as well, like https for the web interface and recursive resolution. But for now it’s working pretty well but (pretty) low effort.
EDIT (31 May 2020): With the release of PiHole v5, I decided it was time to update Raspbian to Buster, which I did ‘in place‘ (not recommended). It took a bit of fiddling to get working. In particular, I found I had a weird issue where the Pi would lose its connection to the network around midnight every day. I’m still not 100% what caused this, but I fixed it by removing two extraneous programs:
apt-get remove avahi-daemon
apt-get remove wicd
and adding the following to config.txt:
I was also able to update cloudfared to 2019.8.1, via the link here, without any segfaults (woo!).