Unbound DNS, PiHole vs. AdGuard Home

[jimjohn]

Hi,

I am currently using Unbound DNS to blacklist DNS queries. I just tried our AdGuard Home on a VM and yes - it has a nice GUI and some nice toggles to play around with compared to Unbound in the OPNsense plugin. Similar things for PiHole.

So I am asking myself, is there any benefit on using PiHole / AdGuard Home ON TOP of Unbound Blacklisting?

I also saw that there is a community package for AdGuard Home within OPNsense.

What is your guys opinion on these three alternatives?

[bimbar]

I would like to use one of the more powerful alternatives to (in my case) bind, but I think the added features probably are not worth the potential problems this brings with it.

Bind on a opnsense cluster is fast and reliable, the other solutions:
- adguardhome on opnsense - not sure if that survives updates and reboots with any reliability
- pihole or adguard on some other platform loses me the reliability a cluster brings

So, for now, I'll abstain. On another note, I do favor bind over unbound due to its seemingly much better performance, especially with big blacklists.

[jimjohn]

I would like to use one of the more powerful alternatives to (in my case) bind, but I think the added features probably are not worth the potential problems this brings with it.

Bind on a opnsense cluster is fast and reliable, the other solutions:
- adguardhome on opnsense - not sure if that survives updates and reboots with any reliability
- pihole or adguard on some other platform loses me the reliability a cluster brings

So, for now, I'll abstain. On another note, I do favor bind over unbound due to its seemingly much better performance, especially with big blacklists.

Well, I did not know BIND. Does it have a similar approach as Unbound by "asking" multiple DNS Servers for DNS resolution in the background? At least in the OPNsense plugin's settings page I could not find a place to enter a DNS server. Furthermore, the blocklists seem different from Unbound.

That said - I found AdGuard Home having the most comprehensive selection of Blacklists.

[cgone]

Three things why I prefer pihole over blocking via unbound:

• I want a clean resolver on and for the firewall itself.
• pihole has counters against cname cloaking.
• The GUI is much nicer, if you want analyse why a app or website is not working.

Hint: Use max-cache-ttl very low on pihole, so that the very good cache/prefetching of unbound works.

[jimjohn]

Three things why I prefer pihole over blocking via unbound:

• I want a clean resolver on and for the firewall itself.
• pihole has counters against cname cloaking.
• The GUI is much nicer, if you want analyse why a app or website is not working.

Hint: Use max-cache-ttl very low on pihole, so that the very good cache/prefetching of unbound works.

Hmm, the firewall itself can target their own DNS queries to its local Unbound. Actually, I think this is what it does natively.

- Did you compare AdGuard Home vs. PiHole?

[Giant850]

Have you considered NextDNS? I used to run Pi-Hole + Wireguard, but recently dumped Pi-Hole. NextDNS is very much like Pi-Hole in terms of block lists, but I think is a better solution. I haven't used AdGuard home before, so I can't compare NextDNS to that. But I'm exceptionally happy with NextDNS + OPNsense. I followed this guide:

https://www.derekseaman.com/2021/04/how-to-nextdns-opnsense-firewall.html

[Patrick M. Hausen]

Just throwing around ideas, my setup:

• BIND listening on 127.0.0.1:53530
• AdGuardHome listening on all interfaces :53, forwarding to BIND
• NAT port forward rules on interfaces where I want to bypass AdGuardHome

I run BIND instead of Unbound, because I have several secondary zones.
AdGuardHome looks like it is way more capable than either the BIND or the Unbound blacklists.
On interfaces where I don't want AdGuardHome (servers), I put a NAT rule forwarding :53 directly to BIND.

Works like a charm.

Kind regards,
Patrick

[jimjohn]

Something inside me votes against CLIing on the OPNsense box. Actually, I'd like to have a solution which is manageable via GUI and more important - somehow maintained or at least compatible with OPNsense.

Blocklists aside - does BIND spread DNS requests as Unbound does?

[Patrick M. Hausen]

What do you mean by "spread"?

And of course all of this is managed in the UI. AdGuardHome is available via @mimugmail's community repo:
https://www.routerperformance.net/opnsense-repo/

[jimjohn]

What do you mean by "spread"?

And of course all of this is managed in the UI. AdGuardHome is available via @mimugmail's community repo:
https://www.routerperformance.net/opnsense-repo/

Spread: Unbound does not use a single DNS server but queries multiple ones AFAIK. (?)

I read that but could not find an example on how to integrate it. Or would I have to enter it manually in the sources.list?

[Patrick M. Hausen]

Spread: Unbound does not use a single DNS server but queries multiple ones AFAIK. (?)

If you configure an explicit forwarder combined with "forward-only", BIND will query only one. You can achieve the same with Unbound of course. But why would you? Every recursive namesever is capable of starting with a root zone cache and working from there. That is the point of the "distributed" in DNS.

I read that but could not find an example on how to integrate it. Or would I have to enter it manually in the sources.list?

Which sources.list? This ain't Debian or Ubuntu

Just do

Code: [Select]

fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.confonce in the CLI. You can manage community packages in the UI afterwards.

[mimugmail]

So I am asking myself, is there any benefit on using PiHole / AdGuard Home ON TOP of Unbound Blacklisting?

I also saw that there is a community package for AdGuard Home within OPNsense.

What is your guys opinion on these three alternatives?

Today I installed Adguard at a school to make it more safe. Real fun to work with it

[jimjohn]

Spread: Unbound does not use a single DNS server but queries multiple ones AFAIK. (?)

If you configure an explicit forwarder combined with "forward-only", BIND will query only one. You can achieve the same with Unbound of course. But why would you? Every recursive namesever is capable of starting with a root zone cache and working from there. That is the point of the "distributed" in DNS.

Not sure I understood correctly, can you rephrase? Though the advantage with Unbound would be that it does query a bunch of DNSses randomly? What is the concept behind it then?

I read that but could not find an example on how to integrate it. Or would I have to enter it manually in the sources.list?

Which sources.list? This ain't Debian or Ubuntu

You're right. Too many parallel things. 

Just do

Code: [Select]

fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.confonce in the CLI. You can manage community packages in the UI afterwards.

[Patrick M. Hausen]

Not sure I understood correctly, can you rephrase? Though the advantage with Unbound would be that it does query a bunch of DNSses randomly? What is the concept behind it then?

This is just how every recursive DNS server, be it Unbound, BIND or any other works. And it does not precisely query them randomly. I'll show you.

Imagine your DNS server is just restarted and the cache is therefore empty. One of your client systems ask for the address of www.opnsense.org.

The nameserver is preconfigured with a list of servers that are responsible for the root zone ("."). This is currently:
(I'll edit out IPv6 AAAA records to keep the size at least a bit lower)

Code: [Select]

;; ANSWER SECTION:
. 439919 IN NS j.root-servers.net.
. 439919 IN NS a.root-servers.net.
. 439919 IN NS h.root-servers.net.
. 439919 IN NS b.root-servers.net.
. 439919 IN NS m.root-servers.net.
. 439919 IN NS d.root-servers.net.
. 439919 IN NS g.root-servers.net.
. 439919 IN NS f.root-servers.net.
. 439919 IN NS c.root-servers.net.
. 439919 IN NS i.root-servers.net.
. 439919 IN NS e.root-servers.net.
. 439919 IN NS l.root-servers.net.
. 439919 IN NS k.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net. 439919 IN A 198.41.0.4
b.root-servers.net. 439919 IN A 199.9.14.201
c.root-servers.net. 439919 IN A 192.33.4.12
d.root-servers.net. 439919 IN A 199.7.91.13
e.root-servers.net. 439919 IN A 192.203.230.10
f.root-servers.net. 439919 IN A 192.5.5.241
g.root-servers.net. 439919 IN A 192.112.36.4
h.root-servers.net. 439919 IN A 198.97.190.53
i.root-servers.net. 439919 IN A 192.36.148.17
j.root-servers.net. 439919 IN A 192.58.128.30
k.root-servers.net. 439919 IN A 193.0.14.129
l.root-servers.net. 439919 IN A 199.7.83.42
m.root-servers.net. 439919 IN A 202.12.27.33

It picks one of them at random and asks it for the nameservers for the "org" zone. Result:

Code: [Select]

;; ANSWER SECTION:
org. 86400 IN NS b2.org.afilias-nst.org.
org. 86400 IN NS c0.org.afilias-nst.info.
org. 86400 IN NS a0.org.afilias-nst.info.
org. 86400 IN NS b0.org.afilias-nst.org.
org. 86400 IN NS d0.org.afilias-nst.org.
org. 86400 IN NS a2.org.afilias-nst.info.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 94209 IN A 199.19.56.1
a2.org.afilias-nst.info. 94209 IN A 199.249.112.1
b0.org.afilias-nst.org. 94209 IN A 199.19.54.1
b2.org.afilias-nst.org. 94209 IN A 199.249.120.1
c0.org.afilias-nst.info. 94209 IN A 199.19.53.1
d0.org.afilias-nst.org. 94209 IN A 199.19.57.1

Next, pick one of those and ask it for the nameservers for "opnsense.org". Result:

Code: [Select]

;; ANSWER SECTION:
opnsense.org. 7952 IN NS ns1.openprovider.nl.
opnsense.org. 7952 IN NS ns2.openprovider.be.
opnsense.org. 7952 IN NS ns3.openprovider.eu.

Now a lot of additional queries take place starting at the top again, because it needs to learn about either "nl", or "be", or "eu" - all not in the cache, either. But eventually it will have picked e.g. "ns1.openprovider.nl" and learned its IP address: 52.57.114.204

Lastly it will ask this server for "www.opnsense.org" and get 81.171.2.181.


This is what recursive nameservers do every single time. This is how the Internet works. If you don't run your own nameserver, your simple router can tell your client systems the address of the nameserver(s) provided by your ISP. Then your ISP's nameserver does precisely that.

Or you can use 8.8.8.8 - then Google does that on your behalf all the while learning about what domains you lookup.


If you run your own it simply works like this. This is at the same time the best protection of your privacy available, because no single entity will ever receive all of your lookup information.

You can run your own but then force it by configuration not to do all that, but instead forward all your request to a single configured upstream nameserver or "forwarder". But why would you do that? You are handing the owner of that single server all your privacy relevant information on a silver platter. Just let your local nameserver do its job.


HTH,
Patrick

[jimjohn]

@pmhausen Thanks, that's a very, very helpful post.

Actually, I want to take the first approach. The "randomly picking" part was what I meant with "spreading" the requests over several servers.

Could you give me the CLI commands you entered so that I can try it out manually myself? Just to learn. Did you use nslookup or dig or something else?

Thanks!