Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)

[Lurkmaster]

@Kingp1n, then it's by using the router...

And what shows when using a client device on that unbound network?

Setting "Use local caching DNS server as system resolver" to Yes only changes what happens on the router, not on the clients. When set to Yes, from the router command line or the tools gui, an nslookup will use the router's local resolver at 127.0.0.1. Nothing changes for the clients which continue to use 192.168.X.1 (or whatever). The odd thing for me is that the amtm resolution errors I saw happened when this was set to No, and the router is then using 9.9.9.9 or 1.1.1.1 (per my settings) to resolve locally on the router. When set to Yes the unbound log shows the resolver as 127.0.0.1 (when resolving locally) and no amtm resolution errors occur. All the clients still operate as usual. I don't pretend to understand it, just reporting observations.

EDIT:
The reason I enabled this setting was to try to find what was causing amtm to fall over. @thelonelycoder suggested I was having a resolution problem so this is why I went looking in this direction. See his suggestion here:
https://www.snbforums.com/threads/amtm-upd-err-using-fallback-server-diversion-ch.61857/#post-551938

 

[Treadler]

Out of curiosity, I was testing, with unbound enabled, the response times of the root servers (a.root-servers.net - m.root-servers.net) from my location. I found that, just like any DNS server, the responses vary wildly.

Does anyone know if unbound takes note of the fastest server(s) and uses those? Is this a relevant method to test unbound?

Depends on their physical location I guess?
There are only two root servers near me, the others are hundreds/thousands of km away.

 

[Ubimo]

Why is it mandatory to set "WAN: Use local caching DNS server as system resolver=NO"?
After installation I've set it to YES. Is this unsafe/stupid? Why?

 

[Treadler]

Why is it mandatory to set "WAN: Use local caching DNS server as system resolver=NO"?
After installation I've set it to YES. Is this unsafe/stupid? Why?

Recommended = “No”.
Personally, I’ve set mine to “yes”, no issues as yet. Time will tell!

I think “no”gives the router an external dns to refer to as a fall back, if for some reason internal dns functions don’t do the job. (At boot up, say).

Experiment.......

 

[Martineau]

Recommended = “No”.
Personally, I’ve set mine to “yes”

As per the GUI help....

So, having explicitly overridden the DEFAULT, would you care to name/describe which script you have that needs the 'YES' setting or is there another reason?

 

[Ubimo]

What/Which queries are done by the router itself?
What is the router queriing?

 

[Deleted member 62525]

As per the GUI help....

View attachment 21494

So, having explicitly overridden the DEFAULT, would you care to name/describe which script you have that needs the 'YES' setting or is there another reason?

My initial setup (Skynet->Unbound->Scribe with OpenVPN Client enabled on boot) was 100% according to recommended setting from Page 1.
Tools->Others-> WAN: Use local caching = No.
Automatically connect to DNS = No


With above config (Unbound default setting) and after few hours, I tried performing amtm update that was failing with "err" messages for all installed modules. Selecting Unboud from amtm was taking a very long time and hanging. However, the internet connections and GUI was fine. VPN working without issues.

At that time I searched for answers on this forum and found some people switching WAN: Use local caching to Yes fixed the issue.
I have done the same and so far 2 days and amtm is snappy and amtm->Unbound does not hang. Maybe there is something else that is causing it or maybe it was a coincident. But so far no issues with amtm updates or unbound menu.

 

[L&LD]

@Markster the correct 'fix' is here:

https://www.snbforums.com/threads/r...ecursive-dns-server.61669/page-30#post-553181

 

[Centrifuge]

the correct 'fix'

Anyway to make these queries encrypted instead of open like that, can't unbound be configured to use DoT? Something like this.

 

[L&LD]

@Centrifuge, @rgnldo and possibly @Martineau would be more qualified to answer that. But my guess is we don't have that option in our routers (yet).

For myself, the fact that 'I' am the authoritative DNS server is enough 'security' for now.

 

[Treadler]

Anyway to make these queries encrypted instead of open like that, can't unbound be configured to use DoT? Something like this.

IMHO, yes you probably could.
The Merlin firmware has a built in DoT function tailor made, ready for use though. Why not just use that if your priority is encryption?

 

[rgnldo]

@Centrifuge, @rgnldo and possibly @Martineau would be more qualified to answer that. But my guess is we don't have that option in our routers (yet).

For myself, the fact that 'I' am the authoritative DNS server is enough 'security' for now.

It is a matter of strategy. The unbound is connected in the authoritative recursive mode and with DNSSEC it is the appropriate and standard one. But there are other features that enhance the unbound and disadvantage of root server's recursion. Using Stubby (with OpenNIC servers) in conjunction with unbound is another good practice and only benefits. One is encrypted TCP traffic. It is a matter of strategy. In situations they are well organized when it comes to DNS server.

 

[Martineau]

Anyway to make these queries encrypted instead of open like that, can't unbound be configured to use DoT? Something like this.

see the Q&A

 

[rgnldo]

I noticed here the doubt of activating 'Tools->Others-> WAN: Use local caching = YES'. Leave it as NO. Thus, the FW will understand that the resolutions will be through the /etc/resolv.conf file, which is disabled by the option in dnsmasq.conf as NO-RESOLV. The 'Tools->Others-> WAN: Use local caching=NO" option avoids any problem of NTP communication with the internet on the WAN, necessary for the functioning of DNSSEC and certificates.

 

[rgnldo]

If you check, you can stop unbound and you won't have internet anymore. You don't even need to remove the dnsmasq.resolv option. There is no need to listen for DNS over the WAN, only for queries coming from the LAN. All tests must be done from the LAN

 

[bluepoint]

As per the GUI help....

View attachment 21494

So, having explicitly overridden the DEFAULT, would you care to name/describe which script you have that needs the 'YES' setting or is there another reason?

I will try to go back to the history of how "WAN: Use local caching DNS server as system resolver" come about.
Sometime before the introduction of DOT, this option's defaults to "yes" but was changed to "no" when many are having problem syncing their time with the NTP servers. Close accuracy time is very important for stubby, skynet, diversion and even now with unbound. Although, this is happening "not" all were affected by the NTP bug even up to now. This is the reason you'll see some including me choose to set the WAN option to leave it to "yes". You might ask why? Simply because NTP works even if I choose the option and when diagnosing routing problems the router uses the same resolver as the clients.

Lately, since 384.15, as of my observation my rt-ax88u starts the WAN connection very early in the boot process that makes NTP syncs very reliably before all entware addons starts. I'm sure RMerlin tweaked the WAN section for the bahaviour to act like this. Setting up my WAN DHCP query frequency to "aggressive mode" might have help to acquire WAN IP quicker at boot time but I doubt since I had that before firmware .15.

 

[L&LD]

@bluepoint, do @rgnldo's test in the post above yours and see if you still have internet though.

If unbound crashes, hiccups, coughs or worse, having no internet is not a fun place to be.

 

[bluepoint]

@bluepoint, do @rgnldo's test in the post above yours and see if you still have internet though.

If unbound crashes, hiccups, coughs or worse, having no internet is not a fun place to be.

Yes, I have internet for both options(yes/no). No difference except when you try system tools the resolver differs.

 

[rgnldo]

test in the post above yours and see if you still have internet though.

Queries over the WAN are unnecessary. The prudent and correct is NO. This makes any configuration on the FW compatible, with no connectivity issues.

 

[L&LD]

Yes, I have internet for both options(yes/no). No difference except when you try system tools the resolver differs.

I don't think you understood me, specifically? With the option set to 'Yes' and with unbound 'stopped/paused', do you still have internet then?

I think the answer will be 'no'.