My DNS stack kept growing until I found the tool that finally made it stop


I did it for the same reason most homelab users start self-hosting DNS — network-wide ad blocking. My homelab was already a bottleneck experiment on an 8-year-old laptop; I didn’t want a DNS infrastructure project, but a cleaner browsing experience for my family. Ad blocking led to DNS privacy. DNS privacy led to the use of encrypted upstream resolvers. Encrypted resolvers led to recursion. I tested Pi-hole, AdGuard Home, and Technitium on my home network, and the journey went further than I planned.

Related

5 powerful DNS servers you can self-host to supercharge your home network

Elevate your self-hosting journey with a DNS server that suits your needs.

My DNS stack kept growing, and I didn’t notice until it was two containers deep

It started with one problem

Being a publisher myself, I was never comfortable blocking ads, but these days, apps and websites have more ads than actual content. I could live with it, but less tech-savvy people like my mother struggled to navigate through a single app without accidentally clicking on an unwanted ad. When I first installed Pi-hole on my network, my intention was never to create a privacy-focused, isolated home network. I aimed to implement ad blocking on my whole network to avoid browser- or app-based ad blockers on every device. I have more than 15 devices at my disposal, and installing ad blockers on each one was tedious. Pi-hole was the best solution to it. Deployment on Docker was straightforward, and since I was a new homelabber, everyone in the community suggested it as the starting point. I wasn’t looking for a DNS project; I just wanted a cleaner browsing experience for my family. And Pi-hole delivered exactly that. I deployed it as an ad blocker, and it was blocking almost every ad on my devices. Since it was implemented on my dual-WAN gateway, I didn’t have to change every device’s DNS settings. In a few months, after navigating through Pi-hole, my interest in DNS grew, and I started reading more about DNS privacy. Then I went down a rabbit hole, and the one that struck me was that DNSSEC validated responses but didn’t hide queries. That ultimately led to hosting my own DNS-over-HTTPS via dnscrypt-proxy. It didn’t mean that Pi-hole wasn’t doing its job right; it was never designed to encrypt queries leaving my network. Pi-hole remained the filtering layer, and dnscrypt-proxy became my encrypted upstream DNS server. dnscrypt-proxy encrypted queries, leaving my network, and forwarded them to Cloudflare and Quad9. The setup was working perfectly. The surprising part was realizing that DNS now required two containers to work together. And I was handling updates, logs, and troubleshooting of two containers separately. That’s when I realized I’d turned a simple ad blocker into a two-container relay race, each piece doing half a job. It worked well, but maintaining them separately was quietly adding up.

OS

Linux

Price model

Free

Pi-hole is a network-wide ad blocker that acts as a DNS sinkhole, preventing unwanted ads, trackers, and malicious domains from loading on any device connected to your network. It runs on lightweight hardware, such as a Raspberry Pi or in a virtual machine. By intercepting DNS queries, Pi-hole blocks ads before they ever reach your browser or apps, improving speed and privacy. It also provides an easy-to-use web interface for monitoring and managing network traffic.

AGH solved one problem and accidentally created a bigger question

Simpler, but not simpler enough

Pi-hole and dnscrypt-proxy weren’t failing me. But managing two containers for one DNS job started to feel unnecessary. Even then, I wasn’t thinking about replacing them because they were doing the job. While scrolling through Reddit homelab threads, AGH kept coming up, and I always wondered what the fuss was about. I then decided to give it a try and run it for a few days against Pi-hole. The setup was straightforward. The UI was slightly different but had similar content — queries, clients, and blocklists. I used the same OISD big list and Steven Black’s unified hosts’ DNS blocklists. AGH was fully operational within a couple of minutes. The dashboard started populating with numbers and stats. While I was in AGH’s settings, I saw something that I didn’t expect — native encrypted upstream DNS. At that moment, I realized I no longer needed dnscrypt-proxy for DoH. And the friction of maintaining two containers was already gone. I immediately set Quad9 as an encrypted upstream provider. Everything is working fine now. I had a much cleaner management experience because filtering and encrypted DNS lived in the same place. I didn’t need to jump between dashboards and logs every time something looked off. Finally, my DNS felt like a single service again, rather than two things pretending to be one. But when I resolved one issue, my tinkerer’s mind created another. When I had moved almost everything else to self-hosted, why were my DNS requests still reaching third-party DNS resolvers? I started exploring options so that I could own the last part of the loop, the DNS. Previously, I had heard a lot about Unbound, and I started experimenting with it. I even tried running Unbound as a standalone setup, but that didn’t work for me. So, I tried to run it alongside AGH, replacing AGH’s native upstream DoH with Unbound. Surprisingly, the experiment worked in my favor. Finally, my network had no dependency on any public resolvers. But then, I was back at the starting line where I started. AGH + Unbound became the new stack. Which meant I was back to two containers doing one job — DNS. The names had changed, but the diagram on my Docker dashboard looked surprisingly familiar.

Technitium did everything the other two needed two containers for, alone

Fewer containers, worse decade of UI design

I moved from Pi-hole to Pi-hole + dnscrypt-proxy and then from AdGuard Home to AGH + Unbound. Now, what’s left? Actually, that was an interesting story. I wrote about my AGH setup, and a few readers recommended Technitium in the comments. I visited its official website and read about it. The feature list was too long, so I scanned for what I needed and then finally decided to test it. Similar to Pi-hole and AdGuard Home, the deployment and basic configuration were straightforward. As soon as I navigated to the Technitium dashboard, it felt very different. For the first time, it felt less like an “ad blocker with DNS features” and more like an “actual DNS server.” The interface was dense and, as advertised on its website, loaded with a ton of features. Lots of menus, lots of settings, lots of terminology. My initial reaction was, “This is excessive for someone who just wants network-wide filtering.”

Technitium could handle recursive resolution itself, which meant the Unbound dependency on my AdGuard Home was no longer necessary. If I ever wanted to go back to DoH, it could also forward to encrypted upstream resolvers like Cloudflare, Quad9, and Google. And my use case: ad blocking, DNS management, and resolution all lived inside one service. Finally, it started looking like the last stop in my homelab DNS setup. For the first time, I saw details that the others largely hid, like the EDE reason codes. I was able to see exactly why a query was blocked and which list triggered it, which was surprisingly useful during troubleshooting. Slowly, Technitium was proving itself the most capable platform of the three, but capability and usability have different meanings, and they weren’t the same. Pi-hole and AGH felt approachable at first glance, but Technitium expected users to already understand DNS concepts. Every feature made more sense as I learned more about it, but that learning curve is exactly where most people will give up. Technically, this was the cleanest solution I tested so far. Practically, it demanded more attention than the other two.

The best DNS server isn’t the most powerful

Pi-hole was the recommended starting point, and it solved my original problem well. But as my stack and requirements grew, Technitium proved itself the most capable solution and gave me the clearest answer to “What can self-hosted DNS actually do?” But AdGuard Home earned its spot in my setup, as it was powerful enough to make me stop thinking about DNS and easy enough to forget it’s running. It was the one that asked the least of me after setup, and for a homelab like mine, that’s the feature that actually matters.


Diterbitkan : 2026-06-21 17:30:00

sumber : www.xda-developers.com