Settling the AdGuard vs PiHole debate for good

There is no way of keeping your sanity while surfing the web without adblocking. Seriously. Ads everywhere and it’s just plain annoying – and sometimes even eating up your bandwidth. On a PC there are loads of tools to block ads like browser extensions; but sometimes you cannot make use of those – this is why many people believe in DNS blocking as a feature which works – as the name implies by intentionally not finding hosts that serve ads or trackers.

To give you an example on how effective it was in freeing up some bandwidth, I implemented it as a DNS server in a students home as a ‘last effort’ to fight against the weak line available at that location. As soon as the clients picked up the new DNS server on the network, I was able to use a remote desktop connection again without going completely insane – mostly because of the vast amount of video ads back then just playing. A big win in my books.

Now there is this endless discussion going on about if AdGuard Home or PiHole is the better solution. I mean, AdGuard does a fairly good job at poking at piHole and I decided to give it a fair shot in my environment. A side by side comparison in my homelab, which sports an AMD EPYC 7282 16-Core Processor where I spun up coreOS as a docker host and pulled both containers and set them up on the same host – side by side.

At the first glance both candidates are open-source with a community, a lot of (additional) blocklists to implement and that’s basically all you need on your local network. AdGuard Home also incorporates DoH as well as DoT which are not really needed on a local network to be honest, as long as I trust my own environment. On top of that, AdGuard may also enforce safe-search which could be interesting if you have kids in your house – which I haven’t. But to even the playingfield regarding encryption I set up traefik on piHole – and yes, there may be some more knowledge required. Adguard takes the price home for an easier setup whereas I could configure piHole using a docker-compose file without having to run through a wizard asking me questions.

Setting up the DNS blocker – at least to me – is something I tend to do only once. That’s why it doesn’t really matter much to me for this test. So let’s get down to usage.

I added the same blocklists to PiHole as well as AdGuard Home which I fetched from firehol.net – and adding them in bulk is where piHole clearly takes the lead whereas AdGuard Home, sporting the more pleasing looking WebUI, lacks import functionality. So that’s definitely a win on PiHole if you change your lists a lot, which I do at least once a month with some scripting.

Resource-wise I let adGuard Home warm up a bit and I’ve seen its RAM usage increase quite a bit to 250 MB

PiHole was already running on my system for a while, so it’s fair to use the end value of 100 MB of RAM

Despite rumors of people telling me that piHole needs more RAM, I could not recreate that on my test.

The next thing I wanted to test is latency – that’s how fast I can get a reply from the DNS to my client. I decided to ‘dig’ for ‘google.de’ twice and took the ‘time’ (command). To get started, I took a baseline measurement on the infamous 8.8.8.8 DNS from Google. Asking twice is for getting the result into the cache, eliminating the need to ask an external DNS. Not that it would matter on the google dns, but I wanted to make sure it’s the same procedure for every candidate.

vbauer@ts ~ $ time dig google.de @8.8.8.8

; <<>> DiG 9.16.41 <<>> google.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.de.                     IN      A

;; ANSWER SECTION:
google.de.              299     IN      A       142.250.180.227

;; Query time: 64 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 02 15:00:37 CEST 2023
;; MSG SIZE  rcvd: 54


real    0m0.078s
user    0m0.004s
sys     0m0.004s

Now the interesting part here is the 'real' time which is the actual stopwatch here, clocking in at 78ms which is still quite impressive. Next up was my internal bind9 server clocking in at 43ms for my internal domain. Not really a slowpoke considering that it runs with an LDAP backend. Clearly the faster response time is due to it being in my local network. But it doesn't do DNS blocking at all.
PiHole came in straight with 18ms while AdGuard Home went for the 21ms mark. So performance wise, those 3ms don't really matter at all. What matters is how you like it. So my tip is setting up both and keeping the one you like more and provides the features you need.

Author:

Leave a Reply

Your email address will not be published. Required fields are marked *