Unbound - Authoritative Recursive Caching DNS Server

[vesalius]

Curious, if this unbound implementation has the ability to work directly as a resolver and not just a forwarder to other public resolvers, i.e. cloudfare, google, etc ...?

I switched to pfsense, outstanding router software, at my home but still manage my folks place with Asus merlin. Anyway, I went setup DNS over TLS on pfSense unbound, which was quite easy.

Upon further reading, I realized that DOT was only making private my forwarded DNS request from my home network to the public resolver. After that the public resolver, i.e. cloudfare, google, etc ..., functions as a resolver and request the DNS from authoritative name servers. This means I have hidden the DNS request from my ISP. To my knowledge, none of the authoritative name servers accept DOT or DOH request. So our request from the public resolvers we choose are not encrypted to the authoritative name servers and the cloudfare, google etc have access to our DNS request history (we have to trust them not to use it). Most if not all authoritative name servers do DNSSEC.

Using Unbound in resolver mode simply cuts out the middle man, cloudfare, google, etc, and Unbound takes their place going directly the authoritative name servers. Given my internet providers' network latency, I find this implementation to generally be more responsive as well.

https://discourse.pi-hole.net/t/general-consensus-to-use-cloudflare-proxy-or-unbound/19120/2

With unbound (in resolver mode), you avoid upstream providers completely and your local resolver (unbound) deals directly with the authoritative name servers (the same ones the upstream providers use). The DNS traffic is not encrypted, but it is authenticated with DNSSEC, so the reply you receive is validated as being the answer that was sent. Unbound uses a few techniques to send as little data to the nameservers as possible and to maximize your privacy - qname minimization is one method. Since you communicate directly with the authoritative name servers, the replies are not filtered in any way. Unbound also has a very efficient cache, so after it’s been in use for a while it does not have to communicate with the name servers as often. Most users find that unbound is typically faster overall than using an upstream provider, once the cache is populated.

For these reasons, I prefer unbound to encrypted DNS:

1. No upstream DNS provider has your DNS history.
2. The results are unfiltered.
3. You have equal assurance that the DNS traffic has not been altered in transit.
4. There is no less privacy from the ISP.
5. Generally faster.
6. I have complete control over my DNS resolver.

 

[SolluxCaptor]

I just wanted to say THANK YOU, to everyone involved. This has evolved so fast into something great, I was wondering though, under WAN should my router point to itself as WAN DNS, or use original upstream? Currently left at original upstream (no radio buttons enabled). I am still seeing a lot of outgoing traffic (on port 853) going to upstream. Is this normal behavior until cached? I see my hit / miss ratio for Unbound is getting better, but each time I run a dig command I first get ~200 msec, if I run again I get 1 msec - both responses from router (first was likely upstream). If I wait about 10 mins, doing this again takes ~200 ms. Is this normal? Also running Diversion + Skynet and used optional Stubby integration. Thanks

 

[rgnldo]

Curious, if this unbound implementation has the ability to work directly as a resolver and not just a forwarder to other public resolvers, i.e. cloudfare, google, etc ...?

I switched to pfsense, outstanding router software, at my home but still manage my folks place with Asus merlin. Anyway, I went setup DNS over TLS on pfSense unbound, which was quite easy.

Upon further reading, I realized that DOT was only making private my forwarded DNS request from my home network to the public resolver. After that the public resolver, i.e. cloudfare, google, etc ..., functions as a resolver and request the DNS from authoritative name servers. This means I have hidden the DNS request from my ISP. To my knowledge, none of the authoritative name servers accept DOT or DOH request. So our request from the public resolvers we choose are not encrypted to the authoritative name servers and the cloudfare, google etc have access to our DNS request history (we have to trust them not to use it). Most if not all authoritative name servers do DNSSEC.

Using Unbound in resolver mode simply cuts out the middle man, cloudfare, google, etc, and Unbound takes their place going directly the authoritative name servers. Given my internet providers' network latency, I find this implementation to generally be more responsive as well.

https://discourse.pi-hole.net/t/general-consensus-to-use-cloudflare-proxy-or-unbound/19120/2

Exactly. I have a thin client where I wanted to leave Pfsense or OPNSense. But it's too much junk for a small network like mine. With an Asus router with FW Merlin, that's great. Unbound is working great. If you prefer you can configure unbound without stubby, exclusively authoritative. The stubby solution is expected and acceptable by the dnsprivacy.org team.

I am traveling. Happy new year to all.


Enviado do meu iPhone usando Tapatalk

 

[SolluxCaptor]

Curious, if this unbound implementation has the ability to work directly as a resolver and not just a forwarder to other public resolvers, i.e. cloudfare, google, etc ...?

I switched to pfsense, outstanding router software, at my home but still manage my folks place with Asus merlin. Anyway, I went setup DNS over TLS on pfSense unbound, which was quite easy.

Upon further reading, I realized that DOT was only making private my forwarded DNS request from my home network to the public resolver. After that the public resolver, i.e. cloudfare, google, etc ..., functions as a resolver and request the DNS from authoritative name servers. This means I have hidden the DNS request from my ISP. To my knowledge, none of the authoritative name servers accept DOT or DOH request. So our request from the public resolvers we choose are not encrypted to the authoritative name servers and the cloudfare, google etc have access to our DNS request history (we have to trust them not to use it). Most if not all authoritative name servers do DNSSEC.

Using Unbound in resolver mode simply cuts out the middle man, cloudfare, google, etc, and Unbound takes their place going directly the authoritative name servers. Given my internet providers' network latency, I find this implementation to generally be more responsive as well.

https://discourse.pi-hole.net/t/general-consensus-to-use-cloudflare-proxy-or-unbound/19120/2

Ah I think you just answered my question! So if you enable Stubby, you are then not running Unbound as an authoritative resolver as it uses DoT only, but will still get cached results from Unbound. If you opt not to use Stubby, you get full authoritative solution albeit with no DoT support?

 

[dave14305]

Ah I think you just answered my question! So if you enable Stubby, you are then not running Unbound as an authoritative resolver as it uses DoT only, but will still get cached results from Unbound. If you opt not to use Stubby, you get full authoritative solution albeit with no DoT support?

Using Stubby with Unbound makes little sense to me. If I want to use DoT, I will just use the firmware’s built-in Stubby directly as designed without Unbound. To forward from dnsmasq to Unbound to Stubby to public upstream DNS is inefficient. Forwarding from dnsmasq to Unbound as a recursive resolver is how I’m running my router now. This gives me the benefits of Diversion ad-blocking with dnsmasq and trusting no public DNS resolvers since Unbound is my recursive resolver. Unbound sends requests unencrypted, but the destinations are numerous (i.e. each authoritative name server).

 

[dave14305]

I was wondering though, under WAN should my router point to itself as WAN DNS, or use original upstream? Currently left at original upstream (no radio buttons enabled).

I would leave WAN DNS as ISP (or other preferred public DNS) to ensure the router can boot and resolve names normally until Unbound is fully up and running and can take over as dnsmasq upstream resolver.

 

[SolluxCaptor]

Using Stubby with Unbound makes little sense to me. If I want to use DoT, I will just use the firmware’s built-in Stubby directly as designed without Unbound. To forward from dnsmasq to Unbound to Stubby to public upstream DNS is inefficient. Forwarding from dnsmasq to Unbound as a recursive resolver is how I’m running my router now. This gives me the benefits of Diversion ad-blocking with dnsmasq and trusting no public DNS resolvers since Unbound is my recursive resolver. Unbound sends requests unencrypted, but the destinations are numerous (i.e. each authoritative name server).

I would leave WAN DNS as ISP (or other preferred public DNS) to ensure the router can boot and resolve names normally until Unbound is fully up and running and can take over as dnsmasq upstream resolver.

Thank you very much for this! This is the route I will go then. It isn't like my ISP can't see my destination IPs anyway, and if I didn't want that - VPN is the way to go.

 

[dave14305]

Why does the installer script allow forwarding of local queries upstream (removing bogus-priv and domain-needed from dnsmasq.conf)? I can't find any post discussing the merits of this. The average user isn't going to configure Unbound to manage local hostnames, so it seems wrong to forward them upstream to Unbound. Also the deletion of no-negcache is enabling negative caching (a horrible double negative). If you intend to reduce dnsmasq cache-size to zero, you should not also be enabling negative caching.

 

[rgnldo]

Why does the installer script allow forwarding of local queries upstream (removing bogus-priv and domain-needed from dnsmasq.conf)? I can't find any post discussing the merits of this. The average user isn't going to configure Unbound to manage local hostnames, so it seems wrong to forward them upstream to Unbound. Also the deletion of no-negcache is enabling negative caching (a horrible double negative). If you intend to reduce dnsmasq cache-size to zero, you should not also be enabling negative caching.

Well I did not understand your questions. It is working perfectly. It makes no sense to use a resourceful DNS server over another. Since dnsmasq can only be used as DHCP, unbound does the DNS service. How do you show crash logs? Here it is working 100% and with stubby.

Sorry, I don't understand your arguments, they don't make sense to me.

Feel free to suggest changes as long as you maintain user support


Enviado do meu iPhone usando Tapatalk

 

[rgnldo]

Keeping up with unbound development. Soon we will have native support for query TCP/TLS. [emoji2]


Enviado do meu iPhone usando Tapatalk

 

[SomeWhereOverTheRainBow]

Using Stubby with Unbound makes little sense to me. If I want to use DoT, I will just use the firmware’s built-in Stubby directly as designed without Unbound. To forward from dnsmasq to Unbound to Stubby to public upstream DNS is inefficient. Forwarding from dnsmasq to Unbound as a recursive resolver is how I’m running my router now. This gives me the benefits of Diversion ad-blocking with dnsmasq and trusting no public DNS resolvers since Unbound is my recursive resolver. Unbound sends requests unencrypted, but the destinations are numerous (i.e. each authoritative name server).

Yea your direct path is not apparent while using unbound , that contributes to the overall privacy.

 

[dave14305]

Well I did not understand your questions. It is working perfectly. It makes no sense to use a resourceful DNS server over another. Since dnsmasq can only be used as DHCP, unbound does the DNS service. How do you show crash logs? Here it is working 100% and with stubby.

I am asking why these specific dnsmasq changes are part of the installer. Why are they useful?

             echo -e "${TAB}pc_delete \"no-negcache\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"domain-needed\" \$CONFIG\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"bogus-priv\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11

The last two lines are the same as enabling “Forward local domain queries to upstream DNS” on the WAN page in the GUI. Why is this a good idea when using Unbound?

 

[SomeWhereOverTheRainBow]

I am asking why these specific dnsmasq changes are part of the installer. Why are they useful?

             echo -e "${TAB}pc_delete \"no-negcache\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"domain-needed\" \$CONFIG\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"bogus-priv\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11

The last two lines are the same as enabling “Forward local domain queries to upstream DNS” on the WAN page in the GUI. Why is this a good idea when using Unbound?

Yea this question is good to ask especially for end users , not all end users are going to know how to configure their unbound to handle this type of setup.

 

[SolluxCaptor]

Yea your direct path is not apparent while using unbound , that contributes to the overall privacy.

Yep. When running this way, if you run a DNS leak test - it will show you as the DNS resolver (because you are if running fully recursive). That is what Unbound is meant for - mostly! Happy new year all, looking forward to native DoT support within Unbound proper, I know that will be coming soon!

 

[rgnldo]

I am asking why these specific dnsmasq changes are part of the installer. Why are they useful?

             echo -e "${TAB}pc_delete \"no-negcache\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"domain-needed\" \$CONFIG\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11
             echo -e "${TAB}pc_delete \"bogus-priv\" \$CONFIG\t\t\t\t\t\t# unbound_installer"                >> /jffs/scripts/unbound.postconf    # v1.11

What's the point of concern? These directive aren't even activated in other operational systems that use dnsmaq. Now you want integration with diversion, Pi-hole etc, I recommend you use it, but you should do the reverse at unbound. If you wish to use the unbound just as cache, remove as much as possible from the unbound file of the unbound file. You should know that.

[/QUOTE]The last two lines are the same as enabling “Forward local domain queries to upstream DNS” on the WAN page in the GUI. Why is this a good idea when using Unbound?[/QUOTE]
It's about a directive from FW Merlin.

You should know if you're following the development line of FW Merlin. Big part of our script unbound's success is given by the advances generated with the implementation of stubby S embarked on fw. It's very difficult to organize a solution of third - landed device. The requests, I am now organizing the implementation in FreshTomato FW. In FreshTomato, it's a little easier.



Enviado do meu iPhone usando Tapatalk

 

[rgnldo]

Sorry about the outcome. I'm on vacation trip and tapatalk is a little more complicated.


Enviado do meu iPhone usando Tapatalk

 

[dave14305]

What's the point of concern?

If you’re going to override users’ firmware GUI settings, there should be a very good reason that is essential to the operation of unbound. These will “leak” local hostnames upstream for no good reason, which could be a privacy concern.

I’m happy to agree to disagree and move on. I appreciate what I’ve learned from your experience. Feliz Ano Novo!

 

[rgnldo]

If you’re going to override users’ firmware GUI settings, there should be a very good reason that is essential to the operation of unbound. These will “leak” local hostnames upstream for no good reason, which could be a privacy concern.

I’m happy to agree to disagree and move on. I appreciate what I’ve learned from your experience. Feliz Ano Novo!

It is working as expected. I did a lot of testing, including with dedicated servers, mini ATX. I implemented unbound on EdgeRouter as well. I was surprised by the FW Merlin, the unbound has good performance, owes nothing. But recognize that organizing on embedded slides is not easy. Feliz ano novo.


Enviado do meu iPhone usando Tapatalk

 

[SolluxCaptor]

As a side-note, the installer script does not seem to account for whichever subnet you happen to use on your network under access-control (allow). It assumes 192.168.1.0/24, but in my case I use 192.168.2.0/24 - this would be nice to see auto detected as a future addition to the installer script. (No rush though! Loving this project.)

Oddly, it seems to work either way (with cache hit quite high) - but I manually added my subnet into "access-control:" in place of 192.168.1.0/24 (as this subnet is not used anywhere in my network).

 

[rgnldo]

As a side-note, the installer script does not seem to account for whichever subnet you happen to use on your network under access-control (allow). It assumes 192.168.1.0/24, but in my case I use 192.168.2.0/24 - this would be nice to see auto detected as a future addition to the installer script. (No rush though! Loving this project.)

Oddly, it seems to work either way (with cache hit quite high) - but I manually added my subnet into "access-control:" in place of 192.168.1.0/24 (as this subnet is not used anywhere in my network).

I agree! Fixed

# don't be picky about interfaces but consider your firewall
interface: 0.0.0.0

access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/24 allow
access-control: 192.168.0.0/24 allow

Thanks for your collaboration


Enviado do meu iPhone usando Tapatalk