After exploring the options on how to enjoy your own digital nusic, I decided to install my first local NAS ever. But that story is reserved for another planned blog post! In this post, I'd like to summarize the options and steps taken to deploy a Pi-Hole as a Docker container on the (Synology) NAS. I've been struggling to get the settings just right and it's still fresh enough to remember and write down the details.

Yes, there are ample guides on how to get the thing up and running. Bootstrapping a Docker container is child's play nowadays, especially with DSM 7, the Synology OS. Just install the "Docker" application, find the correct one in the "registry" tab, download it, and configure desired capabilities and environment variables. The basics are well-explained in Kev Quirk's guide. The problems I've been struggling with are:

• How to use the Pi-Hole image¹ in conjunction with Synology's custom DNS Server (I used it for local custom DNS domains and the reverse proxy);
• How to use the Pi-Hole in conjunction with a router/modem from an ISP that refuses to let you customize the DNS server settings;
• How to use the Pi-Hole in conjunction with other running stuff on the NAS that introduce port conflicts.

My ISP, Proximus (well, technically, Scarlet, the cheap alternative), comes with a sealed-tight modem called a BBox3. Modifying settings in 192.168.1.1 is limited to enabling/disabling Wifi, fiddling with DHCP, and that's about it. Since the Pi-Hole acts as a DNS server, resolving brainbaking.com into its IP (and the other way around), blocking nasty domains if necessary, you need some way to pass all network traffic through the NAS. My initial solution was to put another router in front of the modem, patch LAN1 to the WAN port there, and attach everything (but the TV decoder, that requires snooping stuff according to userbase.be experts I didn't dare to touch) to the second router.

That would look something like this:

I didn't like the solution, but it worked. There are too many moving components involved. The second router is yet another device tucked away and silently eating Watts. Having both DSM's DNS Server application installed and the Pi-Hole means you have to enable a forward first policy in the DNS server, as explained by Joel Buckley here. The problem is that the forward IP will change with each boot unless you script it... Installing the Docker container after the DNS server was activated causes the container to constantly reset as port 53, the DNS listening port, already is in use. Set that to whatever, we won't need it.

The Pi-Hole software comes equipped with basic local custom DNS capabilities. It's nowhere near advanced as Synology's DNS Server software, but it was enough to give my NAS a custom domain name and to resolve the subdomains. The reverse proxy settings in DSM still work. This means we can eliminate one DNS server!

After a day of fiddling, I finally discovered the DHCP server tab in the Pi-Hole admin panel. A DHCP server hands out internal IP addresses to "DHCP clients" (your networked devices), such as 192.168.1.234. But it doesn't stop there, it also sets their DNS server, bingo! That means if you disable your router's DHCP server and use the Pi-Hole's (only one DHCP server broadcasting in the network is a good idea), the connected devices will still automatically be routed through the Pi-Hole. Without having to touch DNS server settings---which I couldn't change in the first place. That means we can also loose the second router. Do remember to setup your NAS as a static IP independent of the DHCP server (that isn't there yet when you boot the NAS)!

Now the setup looks like this:

Much better. Relying on the Pi-Hole's DHCP also eliminated the problem that the client name wasn't passed along. This means the logs were full of "Broadcom.Home" entries, regardless of its source. I contemplated flashing the second router with custom firmware such as the OpenWrt one, but limited compatibility with the D-Link I have meant reduced Wi-Fi capabilities and potentially bricking it. OpenWrt would theoretically allow for more fine-grained options such as other mystic dmasq.d settings that hopefully would resolve the client name issue.

I was worried about being dependent on the NAS (well, Docker container in the NAS) as a DHCP server. What if it reboots or is offline? DHCP lease timeouts are usually set at a week or month or so, so once a device has an IP (and DNS settings), it won't need the DHCP server anymore. The trouble isn't the DHCP server but the DNS server. As soon as that goes down, any domain name won't resolve.

You can usually configure two DNS servers in routers, but that is now done automatically. Choosing a second DNS server is strongly discouraged since apparently, it isn't used as a fall-through backup server, but as an alternating server. That means that one request will go through the Pi-Hole, and another suddenly will not, rendering all our efforts futile. A solution would be to use two Pi-Holes, but for the moment, I'm done fighting with network stuff.

Yet another problem. Once the Pi-Hole is done with your DNS request, it has to pass it as an "upstream request" to another DNS server, which will eventually resolve it. By default, Google's 8.8.8.8 is enabled, but you can also configure it to use Quad9 (conveniently, 9.9.9.9), a privacy-focused open DNS based off Switzerland. We didn't have much luck with that: it introduced a lot of latency before caching. After reverting to the factory settings of the BBox3 modem, Scarlet's Belgian DNS server, things again were very smooth.

Pfew. In the end, my limited networking skills might have led me to over-engineer the first solution, but I'm glad it works flawlessly now. The only challenge that remains---besides fiddling with blacklisting domains---is: what if the NAS goes down? For the moment, I don't feel like buying a Raspberry Pi just to install a backup DNS server, but it's certainly possible. Time will tell how stable the NAS OS itself is.

Addendum: After reading through this excellent guide on how to choose the DNS server and checking if my ISP supports DNSSEC (it does) and QNAME minimisation (it doesn't), I decided to test Cloudflare's 1.1.1.1 public provider. It does have a server in Brussels, and the nearest Quad9 is in Amsterdam. For even more privacy, I could also setup DNS-over-HTTPS.

Someday.

Addendum 2: The Proximus/Scarlet TV decoder doesn't align well with Pi-Hole's DHCP server. After a power cut, a new lease was necessary, but ipTV failed to boot correctly. A thread on userbase.be describes the same issue. The only solution I found is to temporarily re-enable your BBox's DHCP, and revert after the lease.