Unbound Understanding Unbound...

[Viktor Jaep]

Glad that it works. But with a little caveat. If you only have one ovpn client then it works fine. If someone has more that one ovpn client, then it may not work very well. For example, the last one that come up will have unbound bind over it; or any one ovpn client went down, it may cause unbound route back on WAN etc. We don't have the flexibility of the individual route-up/route-pre-down script offers.

Yeah that seems to be a whole other hurdle to overcome. Glad to only be using a single VPN.

 

[chongnt]

Yes, there was some debating about restoring the cache. The main problem was determining how old the saved cache was. On a reboot - you know it’s fairly fresh. On the other hand, if you power off the router, reconfigure something, spend a few hours futzing around - on a fresh start - the cache could be quite old.
I wrote a script to timestamp the cache file on evey ubound-control dump-cache (via cron every 10 mins).
On a services-start if the time stamped cache was older than 30 mins, no reload.
I don’t recall now how @Martineau implemented it in unbound-manager. I did this script before it was added.

His take is in this post. Basically on start-up, it will run from post-mount script. cache is that older than 10 min will not get restored.

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

Sorry but I cannot see how to get the Advanced menu. from the Readme on Github

www.snbforums.com

 

[JGrana]

His take is in this post. Basically on start-up, it will run from post-mount script. cache is that older than 10 min will not get restored.

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

Sorry but I cannot see how to get the Advanced menu. from the Readme on Github

www.snbforums.com

10 mins - good, shorter than what I guessed.
I’m ditching my script and using his!

 

[chongnt]

I think the two lines can be consolidated into a single line:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && { [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start & || [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &; }

Or a bit more:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && { [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start & || /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &; }

 

[Viktor Jaep]

I think the two lines can be consolidated into a single line:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && { [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start & || [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &; }

Or a bit more:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && { [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start & || /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &; }

I appreciate the optimization, but I think I'll leave it as-is to allow people to have more understanding on how it works...

 

[iTyPsIDg]

Out of curiosity, was there a definitive answer on whether we can use 127.0.0.1 in the WAN DNS settings? That's the only thing still going over the WAN connection. As you can see in the screenshot, I'm using Nord's SmartDNS servers at present.

 

[Viktor Jaep]

Out of curiosity, was there a definitive answer on whether we can use 127.0.0.1 in the WAN DNS settings? That's the only thing still going over the WAN connection. As you can see in the screenshot, I'm using Nord's SmartDNS servers at present.View attachment 51246

I remember some older threads that spoke to this - I'm lazy and going to paraphrase, but I'm pretty sure that was a dangerous thing to do, especially on a reboot, where your router may not be able to get out to the internet to do some core functionality like getting info from time servers and such... which then cascades and borks things up (technical terms)

But experiment freely! Let us know what your experience is... we're dying to find out!

 

[iTyPsIDg]

I remember some older threads that spoke to this - I'm lazy and going to paraphrase, but I'm pretty sure that was a dangerous thing to do, especially on a reboot, where your router may not be able to get out to the internet to do some core functionality like getting info from time servers and such... which then cascades and borks things up (technical terms)

But experiment freely! Let us know what your experience is... we're dying to find out!

Haha, not after the issues last year. I don't want to rebuild the router again today.

 

[fearz]

Interesting thread, so is there any performance analysis/report that actually shows any optimization in performance/response to queries with that setup?

 

[SomeWhereOverTheRainBow]

Interesting thread, so is there any performance analysis/report that actually shows any optimization in performance/response to queries with that setup?

Yea I think most of the performance and optimization works were done in threads like this one:

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

ORIGINAL THREAD: https://www.snbforums.com/threads/unbound_manager-manager-installer-utility-for-unbound-recursive-dns-server.61669 I apologize for being so bold as to create a second "general" thread but it seems perhaps more logical than a million tiny ones...

www.snbforums.com

 

[Khadanja]

Wonder why my results are different from @Viktor Jaep , mine is also standard installation of unbound using root servers only.

 

[Viktor Jaep]

Wonder my results are different from @Viktor Jaep , mine is also standard installation of unbound using root servers only.
View attachment 51812

I get the same results... a few months ago, they would all say "pass"... so I'm not sure what changed on their end... perhaps this is the correct output, now showing that it's only connecting to the valid signatures?

 

[bluepoint]

I get the same results... a few months ago, they would all say "connected"... so I'm not sure what changed on their end... perhaps this is the correct output, now showing that it's only connecting to the valid signatures?

View attachment 51816

That's how I interpreted it, not connected if the signature is not valid(invalid,expired,missing) and showing green which means it correctly identified bad/good items.

 

[Gary_Dexter]

I get the same results... a few months ago, they would all say "connected"... so I'm not sure what changed on their end... perhaps this is the correct output, now showing that it's only connecting to the valid signatures?

View attachment 51816

So long as Correct Signature is Connected and the rest are Not Connected then you’re good

 

[SomeWhereOverTheRainBow]

Wonder why my results are different from @Viktor Jaep , mine is also standard installation of unbound using root servers only.
View attachment 51812

I get the same results... a few months ago, they would all say "connected"... so I'm not sure what changed on their end... perhaps this is the correct output, now showing that it's only connecting to the valid signatures?

View attachment 51816

That's how I interpreted it, not connected if the signature is not valid(invalid,expired,missing) and showing green which means it correctly identified bad/good items.

So long as Correct Signature is Connected and the rest are Not Connected then you’re good

Yea there has been some major fixes lately with pihole, dnsmasq, and adguardhome, regarding how they interpret certain parts of the dnssec data. For a while there were parts being miss read. That is part of the reason the test on this site (and other test sites) would give strange results when meshing unbound, and adguardhome (or pihole) dnssec readings together. This is the updated test that resolved that issue.

 

[Viktor Jaep]

Looks like they yet again changed their interface over at https://dnscheck.tools/ :

 

[SomeWhereOverTheRainBow]

Looks like they yet again changed their interface over at https://dnscheck.tools/ :

View attachment 51971

Yep, very very nice indeed.