What's new

Unbound Understanding Unbound...

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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. ;)
 
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.
 
I think the two lines can be consolidated into a single line:

Code:
[ "${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:
Code:
[ "${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 think the two lines can be consolidated into a single line:

Code:
[ "${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:
Code:
[ "${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... ;)
 
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.
1687495573534.png
 
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) :p

But experiment freely! Let us know what your experience is... we're dying to find out!
 
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) :p

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.
 
Interesting thread, so is there any performance analysis/report that actually shows any optimization in performance/response to queries with that setup?
 
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:

 
Wonder why my results are different from @Viktor Jaep , mine is also standard installation of unbound using root servers only.
1689733743218.png
 
Last edited:
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?

1689768126407.png
 
Last edited:
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.
 
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.
 

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top