Unbound Understanding Unbound...

[Twiglets]

Viktor,

I have been using unbound for some time [installed on a RT-AC86U Router].
1st port of call would be https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html
Also look at the included /opt/share/unbound/configs/doc/example.conf.in
Read, assimilate and understand what all the options do !!!

An alternative to using a VPN to secure your dns resolution, is to use DNScrypt-proxy to access the DNS resolvers of your choice.
[See https://github.com/DNSCrypt/dnscrypt-proxy]
You can select DNScrypt or DoH or DoT as your protocol.
[I am currently using a old RT-AC56U to run DNScrypt-proxy on !!!]

Ask me questions if you have any and 'yes' .... I know yet more potential points of failure ..... maybe !!!

In your unbound.conf define a 'forward-zone':
xxx.xxx.xxx.xxx = Address of whatever is running Dnscrypt-proxy
yyyyy = port number
name:"." will forward ALL calls to unbound through this zone.

#####################################################################
forward-zone:#DNSCrypt
name: "."
#### i.e. forward-addr: xxx.xxx.xxx.xxx@yyyyy
forward-addr: 192.168.1.250:53333
forward-first: no
forward-tls-upstream: no
forward-no-cache: no
#####################################################################

Within the dnscrypt-proxy.toml file set your address to match the forward-addr: in the unbound.conf file.

listen_addresses = ['192.168.1.250:53333']

 

[Viktor Jaep]

Viktor,

I have been using unbound for some time [installed on a RT-AC86U Router].
1st port of call would be https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html
Also look at the included /opt/share/unbound/configs/doc/example.conf.in
Read, assimilate and understand what all the options do !!!

Wow, that is certainly a plethora of information!!

An alternative to using a VPN to secure your dns resolution, is to use DNScrypt-proxy to access the DNS resolvers of your choice.
[See https://github.com/DNSCrypt/dnscrypt-proxy]
You can select DNScrypt or DoH or DoT as your protocol.
[I am currently using a old RT-AC56U to run DNScrypt-proxy on !!!]

Ask me questions if you have any and 'yes' .... I know yet more potential points of failure ..... maybe !!!

Many thanks! I certainly will! So here comes your first one...

For those who aren't proxying to DNSCrypt, and are just using a standalone router with Unbound running on it... is there any need to change the custom default DNS server info? I was reading that PiHole likes you to use 127.0.0.1: port... in our case that's 127.0.0.1:53535... Any need for this? I'm not seeing any issues thusfar with keeping things blank/default. I also read you probably don't want to mess with your WAN DNS settings, since those are still needed for vital functions when everything else goes down. Thank you!

 

[JGrana]

You know what worked really well here? I have a DIY NAS running Windows on HP mini PC with i5 CPU. AdGuard Home has Windows version. Upstream to my local OpenDNS server with DoH, about 8x blocklists from default AdGuard options listed in Security category. After AdGuard Home cache was built the DNS resolution was instant. The average processing time was about 17ms on my Cable ISP with 10-12ms default latency. This beats my pfSense with Unbound as resolver big time. Not really noticeable in Internet user experience, but measurable difference and nicer than pfBlockerNG UI.

Funny, I just purchased one from Woot - HP Elitedesk Mini 3 (i5 CPU’s). I took out the Windows disk, installed an SSD and then installed Ubuntu. Didnt like all the other stuff in Ubuntu and ended up with Debian server.
My plan was to off load some of the Addons running on my AX88U Pro. First up - Unbound.
Tried numerous web examples and could not get Unbound running. Tried all kind of .confs.
Im just spoiled at how easy to was to install on Asuswrt-merlin with unbound-manager.
(I wish @Martineau would make a version for Debian — he would be a rock star…)

At this point my little “netserver” isn’t doing much. As I said, I wanted to offload some of the functions on the router — unbound, YazDHCP. Then attempt to port over spdMerlin and possibly scribe.
I am going to attempt YazDHCP the next few days.

 

[Tech9]

Your AiMesh will stop working if you move the DHCP server as well.

 

[Twiglets]

Wow, that is certainly a plethora of information!!


Many thanks! I certainly will! So here comes your first one...

For those who aren't proxying to DNSCrypt, and are just using a standalone router with Unbound running on it... is there any need to change the custom default DNS server info? I was reading that PiHole likes you to use 127.0.0.1: port... in our case that's 127.0.0.1:53535... Any need for this? I'm not seeing any issues thusfar with keeping things blank/default. I also read you probably don't want to mess with your WAN DNS settings, since those are still needed for vital functions when everything else goes down. Thank you!

As far as I am aware there is no need to change the default DNS server as it is overridden by the setting in dnsmasq.conf in /etc
If possible read the copy of dnsmasq.conf in /etc there should be a 'server=127.0.0.1#53535' line.
That line should be the address that unbound is using in the unbound.conf file ..... in the server: section.
e.g. interface: 127.0.0.1@53535

As you may tell I have been 'hacking' these files like my life depended on it !!!

I have a very unusual setup that no-one else should copy, as it is potentially 'fragile'

My sig is very out of date as I hack things for my amusement far too often !!!



P.S. Don't get too focused on PiHole as it does use unbound but it is specifically configured for the way PiHole works. i.e. some of the settings may not be appropriate for unbound by itself.

 

[Twiglets]

Just to clarify.
Unbound will still work as designed but use DNSCrypt-proxy to perform its access to the root DNS servers & DNS access, via your DNS servers of choice, when the unbound cache fails.
DNScrypt, DoH and DoT can all be used at the same time for various DNS Servers via DNSCrypt-proxy.

DNSCrypt-proxy has 'cloaking-rules.txt' which can be used to do 'interesting' mapping of DNS lookup from one address to another .... automagically !!!

Youtube ad blocking does work for me via unbound .... see 'sh /jffs/addons/unbound/unbound_manager.sh advanced' ---> Option 3 ---> youtube

If you want to learn something new and challenge the 'internet gods' it is worth a look !!!

End of sales pitch

 

[Viktor Jaep]

End of sales pitch

Sold! Thanks so much for all this great info! Will definitely be experimenting!!

 

[johndoe85]

While I am not refuting your claim, I find it hard to believe that your ISP is being truthful to you 100 percent about that. Maybe the malicious website, and family filter parts, but they will never be a full ad-blocking implementation because they wouldn't want to hurt stakeholders or business partners. The adblocking would most likely be very limited.

Time will tell
The ISP is not like any other though, they are more for the customer than this big tech stuff.
Their name is Bahnhof and is a Swedish ISP.

 

[Viktor Jaep]

OK... I think I was going down the wrong path in trying to get my DNS resolver to appear as my VPN exit IP... It seems I could only make this happen by setting my VPN "Accept DNS Configuration" as "exclusive". But after doing a bit more analysis with DNSMON, it seems that it overrides even Unbound, and makes the NordVPN DNS servers the source, almost like in a forwarder type of scenario. I'm not quite sure why.

So, now I'm back to setting "Accept DNS Configuration" as "disabled". This again is now showing that my DNS resolver is appearing as my WAN IP... but if that's as good as it's gonna get, then so be it.

Now for the other weirdness... I would like to see how you interpret these DNSMON results...

The Sender is my VPN internal IP, and it's presumably sending DNS queries to authoritative servers across my VPN tunnel based on that info. The recipient data is what I'm questioning, as the source is the authoritative server (for the reply back), but its destination is my WAN IP. So the question here is: Why does it seem like plaintext port 53 traffic is being sent directly from the authoritative server back to my WAN IP, instead of traversing back over the VPN?

So is this Unbound feature "outgoing-interface: <VPN IP>" only a 1-way push? In that case, the ISP would be able to snoop on all this plaintext port 53 results coming back to me, and essentially making unbound useless in this supposed "more secure" scenario using a VPN tunnel. If so, it probably makes sense to go with a more secure DoT/DNSSEC setup with a security/privacy-conscious DNS provider like Quad9 than it does leaking all this plaintext port 53 Unbound data for ISPs to feast on. Does anyone have any deeper knowledge about how this all supposedly works?

@Twiglets ... do you have any input or answers to this? Also, you run DNSCrypt-proxy on another device... is there any way to run both DNSCrypt-proxy and Unbound on the same box?

 

[Twiglets]

Viktor,

"Also, you run DNSCrypt-proxy on another device... is there any way to run both DNSCrypt-proxy and Unbound on the same box?"

I have tried to run both on the same router but I could not work out how to get them to run correctly together

Trying to answer your main question but I do not have a VPN to try .... want to test before stating an answer that does not work !!!

 

[Viktor Jaep]

Viktor,

"Also, you run DNSCrypt-proxy on another device... is there any way to run both DNSCrypt-proxy and Unbound on the same box?"

I have tried to run both on the same router but I could not work out how to get them to run correctly together

Trying to answer your main question but I do not have a VPN to try .... want to test before stating an answer that does not work !!!

Thank you... I found the "interface:" item under the conf... but this isn't a value that is programmatically updated when you run the unbound command for "unbound_manager vpn <slot #>". I would need to write some script that would update that conf file separately. If it even works.

I would need to test if by putting the internal VPN ID in there would even work receiving that traffic back. Right now, it's set to 127.0.0.1:53535...

EDIT: as a quick test, I added:

interface: 10.8.0.6@53  (and 53535)
access-control: 10.8.0.0/32 allow

And neither had an impact... I left the "interface: 127.0.0.1:53535" in there...

EDIT2:

I commented out the 127.0.0.1:53535, and left the 10.0.8.6@53535 in there, and that caused major DNS resolution issues.

It's clear to say, I have no clue what I'm doing...

 

[Twiglets]

As far as I can understand, once you have set up the VPN Tunnel, you should have an address that is the 'end of the tunnel' local to you.

That is the address that you need to specify for outgoing-interface:.

This information will be available from VPN Director as far as I know.

Sorry I cannot set up a VPN to test at the moment ..... bouncing the 'Internet' while I play is a 'hanging offence' !!!

 

[johndoe85]

Just to clarify.
Unbound will still work as designed but use DNSCrypt-proxy to perform its access to the root DNS servers & DNS access, via your DNS servers of choice, when the unbound cache fails.
DNScrypt, DoH and DoT can all be used at the same time for various DNS Servers via DNSCrypt-proxy.

DNSCrypt-proxy has 'cloaking-rules.txt' which can be used to do 'interesting' mapping of DNS lookup from one address to another .... automagically !!!

Youtube ad blocking does work for me via unbound .... see 'sh /jffs/addons/unbound/unbound_manager.sh advanced' ---> Option 3 ---> youtube

If you want to learn something new and challenge the 'internet gods' it is worth a look !!!

End of sales pitch

So when does this comes out of the box with an installer script?

 

[chongnt]

OK... I think I was going down the wrong path in trying to get my DNS resolver to appear as my VPN exit IP... It seems I could only make this happen by setting my VPN "Accept DNS Configuration" as "exclusive". But after doing a bit more analysis with DNSMON, it seems that it overrides even Unbound, and makes the NordVPN DNS servers the source, almost like in a forwarder type of scenario. I'm not quite sure why.

So, now I'm back to setting "Accept DNS Configuration" as "disabled". This again is now showing that my DNS resolver is appearing as my WAN IP... but if that's as good as it's gonna get, then so be it.

Now for the other weirdness... I would like to see how you interpret these DNSMON results...

The Sender is my VPN internal IP, and it's presumably sending DNS queries to authoritative servers across my VPN tunnel based on that info. The recipient data is what I'm questioning, as the source is the authoritative server (for the reply back), but its destination is my WAN IP. So the question here is: Why does it seem like plaintext port 53 traffic is being sent directly from the authoritative server back to my WAN IP, instead of traversing back over the VPN?

So is this Unbound feature "outgoing-interface: <VPN IP>" only a 1-way push? In that case, the ISP would be able to snoop on all this plaintext port 53 results coming back to me, and essentially making unbound useless in this supposed "more secure" scenario using a VPN tunnel. If so, it probably makes sense to go with a more secure DoT/DNSSEC setup with a security/privacy-conscious DNS provider like Quad9 than it does leaking all this plaintext port 53 Unbound data for ISPs to feast on. Does anyone have any deeper knowledge about how this all supposedly works?

View attachment 49842

@Twiglets ... do you have any input or answers to this? Also, you run DNSCrypt-proxy on another device... is there any way to run both DNSCrypt-proxy and Unbound on the same box?

Have you try the script by @Martineau in this post? I have been using this with no issue.

Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

Dumb question but how do u add it this list? From diversion -> b (blocking list) -> 1 (change composition custom) -> 2 (customize hosts list) -> 1 (Add hosts list) -> paste new hosts link link here -> e (exit) -> 1 (yes to update list now). It will take some time to update the lists.

www.snbforums.com

I set the outgoing-interface to my router IP 192.168.1.1. DNS monitor show this as sender source ip.
I remember at one time I leave it blank, and the dns monitor tool show the sender source as my WAN IP. So the entries are shown in red. If I remember correctly, tcpdump still show the dns query is send through vpn tunnel.

The best way to verify is to do a tcpdump on the vpn interface, for example ovpnc1:

tcpdump -i tun11 -p port 53

or use any interface and see which interface is used.

 tcpdump -i any -p port 53

 

[Twiglets]

So when does this comes out of the box with an installer script?

No no no no no !!!
Do not wish that on the world ..... ever.
(Remember Pandora and her problems with a certain box !!!)

I can 'hack' anything that has been well written ('standing on the shoulders of giants') but starting from scratch usually is not very good !!!

I can live with my hacks but they are not 'safe' for automagic use ..... i.e. If things fail there is usually not a 'Press this button to fix' answer !!!

 

[heysoundude]

It's clear to say, I have no clue what I'm doing...

once you've a handle on this, wade on into WireGuard

 

[Viktor Jaep]

Have you try the script by @Martineau in this post? I have been using this with no issue.

Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

Dumb question but how do u add it this list? From diversion -> b (blocking list) -> 1 (change composition custom) -> 2 (customize hosts list) -> 1 (Add hosts list) -> paste new hosts link link here -> e (exit) -> 1 (yes to update list now). It will take some time to update the lists.

www.snbforums.com

I set the outgoing-interface to my router IP 192.168.1.1. DNS monitor show this as sender source ip.
I remember at one time I leave it blank, and the dns monitor tool show the sender source as my WAN IP. So the entries are shown in red. If I remember correctly, tcpdump still show the dns query is send through vpn tunnel.

OK, this is interesting. Can you explain a little how this works, and what you're seeing behavior-wise from your end? When I call the "unbound_manager vpn=3", it will change the "outgoing-interface:" dynamically to the internal VPN IP, usually in the form of an address, like: 10.0.8.3...

Are you saying you change the outgoing interface to 192.168.1.1 (or internal router br0 IP), and use this script to facilitate setting the rules for unbound to traverse over the VPN in this case?

The best way to verify is to do a tcpdump on the vpn interface, for example ovpnc1:

tcpdump -i tun11 -p port 53

or use any interface and see which interface is used.

 tcpdump -i any -p port 53

I think I'll spend some time looking at this in more detail in the interim - thanks for your advice!

 

[Gary_Dexter]

So, now I'm back to setting "Accept DNS Configuration" as "disabled". This again is now showing that my DNS resolver is appearing as my WAN IP... but if that's as good as it's gonna get, then so be it.

That’s how Unbound works as YOU become the DNS Resolver. So your WAN becomes the DNS server/IP.

 

[Viktor Jaep]

The best way to verify is to do a tcpdump on the vpn interface, for example ovpnc1:

tcpdump -i tun11 -p port 53

or use any interface and see which interface is used.

 tcpdump -i any -p port 53

So really weird... DNSMON is showing that queries are initiating from my tun14 interface (IP is 10.8.1.2)... yet, when I run the command:

tcpdump -i tun14 -p port 53

...it doesn't report any traffic whatsoever. And the mystery continues...

 

[Viktor Jaep]

That’s how Unbound works as YOU become the DNS Resolver. So your WAN becomes the DNS server/IP.

Right... but as was stated before... if you run the command "unbound_manager vpn=4", unbound would then send all queries out over your VPN interface to prevent the ISP from snooping on that traffic, and your public VPN IP then would indicate as the DNS resolver -- I have not been able to make that happen as of yet... My question is, is this really happening, and why does the DNSMON tool show that outbound traffic looks like it's going out over the VPN, but the recipient of return traffic is coming back to the WAN interface.