What's new

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

  • 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!

Stubby integration not working ? (latest ver. also on previous version )
As per item 5 in the Q&A the downside to Stubby-Integration is losing the ability to self-host the DNS service, where the only entity you need to trust is yourself and the router environment.

As the RMerlin firmware can very successfully/efficiently natively do dnsmasq+DoT+Stubby, configuring unbound+DoT+Stubby seems like wasted effort to achieve the same result?

Anyway, whilst I may eventually remove the unbound Stubby-Integration option, I haven't knowingly broken the option in the script.

NOTE: There was a pull-request in (v2.08) to support the legacy LTS Release, so was that when you observed it was broken?

Can you supply more details?
 
@L&LD I get my new router today. This one is pretty messed up. Time for a complete, manual from screenshots and memory, full setup from scratch on the new one. Looking forward to having a client list again and other nice features I lack right now. I'm going to format and reinstall all my scripts as well. ;)
I'm back, and unbound installed. I have a client list woohoo! :eek::D
 
The unbound.conf.add is working great. Thank you.
I noticed that the added parameters do not appear in the unbound config but they are working. [emoji106]

Sent from my Pixel 4 XL using Tapatalk
 
Just an observation of mine, is there a reason why we have 2 times : prefetch: yes and
prefetch-key: yes , one being under # tiny memory cache and the other under # prefetch ?
Is there a way we can merge all these settings together?
All good here, merged them all together no more double prefetch paramaters and it's working flawlessly.
 
Last edited:
As explained here after running the 'i' command (since v2.06) you have been asked

"Do you want to retain/keep your working current config?"
so you losing your current ACTIVE 'unbound.config' is by choice.

NOTE:As listed in the v2.10 release notes, you can now exploit the 'unbound.postconf' script to automatically re-apply your custom 'unbound.conf' tweaks every time you use the 'i' command. This gives you the best of both worlds, i.e. take advantage of any community proven tweaks added to the base unbound configuration, but allow you to seamlessly reject or merge your own requirements.

As for the cache, well now you understand you don't have to restart unbound for every script update - your wish has come true.

All understood - save that in my imperfect logic ... when you have chosen "i" and rerun through a series of config questions [which one assumes may contain fixes - why else would there be an instruction to run "i" after "u"?] ... it is counter intuitive to decide to "keep your working config".

To a non-coder like me - that suggests I will revert the config to the state it was BEFORE the latest fixes were applied.

Anyway - no need to debate here ... I PROPERLY enjoy unbound, was not being critical ... but wishful ... and I know & appreciate the work-arounds contributed by you and other skilled members of this great community. {Thumbs-Up}.
 
All understood - save that in my imperfect logic ... when you have chosen "i" and rerun through a series of config questions [which one assumes may contain fixes - why else would there be an instruction to run "i" after "u"?] ... it is counter intuitive to decide to "keep your working config".

To a non-coder like me - that suggests I will revert the config to the state it was BEFORE the latest fixes were applied.

Anyway - no need to debate here ... I PROPERLY enjoy unbound, was not being critical ... but wishful ... and I know & appreciate the work-arounds contributed by you and other skilled members of this great community. {Thumbs-Up}.

Those are the thoughts I face when I see that choice. I see the question and am unsure what to do for the best. It makes me think I’ve misunderstood what the file does because, if it did what I thought it did, the question would, instead, be something like, Do you want to revert your config file to default settings? Press y for Yes or Enter to skip. I’m also led that way because for most of the other questions I select Skip (except for the Firefox question). Or have I, indeed, got the wrong end of the stick?
 
Last edited:
All understood - save that in my imperfect logic ... when you have chosen "i" and rerun through a series of config questions [which one assumes may contain fixes - why else would there be an instruction to run "i" after "u"?] ... it is counter intuitive to decide to "keep your working config".

To a non-coder like me - that suggests I will revert the config to the state it was BEFORE the latest fixes were applied.

Anyway - no need to debate here ... I PROPERLY enjoy unbound, was not being critical ... but wishful ... and I know & appreciate the work-arounds contributed by you and other skilled members of this great community. {Thumbs-Up}.
As I've previously stated, the core unbound installation itself is (touch-wood superstitiously) considered stable/final, i.e. the script is now basically only adding (bloat :eek:?) features to the menu etc.

Managing the Entware packages is already conveniently handled via amtm, so the need to use 'i = Update unbound Installation' after the initial install is now probably zero for most adopters.

Here are the only reasons where the 'i' command is required
  1. Download a new 'unbound.conf' to take advantage of any new base configuration settings.
  2. Adding options such as 'CPU/Performance Tweaks' that were skipped during the initial install.
  3. Downloading a new kernel 'stuning' script related to the above'CPU/Performance Tweaks' .
  4. (Retrieve a new Ad Block configuration script 'gen_adblock.sh' containing updated blocklists) - no longer currently maintained :(

P.S: Thanks (and kudos) to @JSewell [post #481 I will add the ability to retain the cache across an unbound restart 'rs' (or even after an uninstall/reinstall combo 'z' + 'i' if this a feature that should be an option?)
 
Last edited:
As I've previously stated, the core unbound installation itself is (touch-wood superstitiously) considered stable/final, i.e. the script is now basically only adding (bloat :eek:?) features to the menu etc.

Managing the Entware packages is already conveniently handled via amtm, so the need to use 'i = Update unbound Installation' after the initial install is now probably zero for most adopters.

Here are the only reasons where the 'i' command is required
  1. Download a new 'unbound.conf' to take advantage of any new base configuration settings.
  2. Adding options such as 'CPU/Performance Tweaks' that were skipped during the initial install.
  3. Downloading a new kernel 'stuning' script related to the above'CPU/Performance Tweaks' .
  4. (Retrieve a new Ad Block configuration script 'gen_adblock.sh' containing updated blocklists)

P.S: Thanks (and kudos) to @JSewell [post #481 I will add the ability to retain the cache across an unbound restart 'rs' (or even after an uninstall/reinstall combo 'z' + 'i' if this a feature that should be an option?)

Rather than make it an option why not enable it silently and automatically? Is there any reason why you wouldnt want the ability to retain a cache across an unbound restart?
 
Rather than make it an option why not enable it silently and automatically? Is there any reason why you wouldnt want the ability to retain a cache across an unbound restart?
I intend to always silently retain the cache across a manually requested 'rs'

The option question is for the case where if you uninstall then reinstall, should the 'saved' cache file (if it exists) be restored even if it could be days or weeks old? - or should use of the uninstall 'z' command ensure the saved cache is truly erased (or perhaps explicitly adding a 'zz' option?)

So now we get into the need for menu options that should manage the cache status...i.e. should an auto (cron) save every hour be necessary, or an option to reset/flush the saved cache file etc.
 
Last edited:
I think I will leave that up to your expert opinion. Having to create the cache from scratch is not a huge impost for most of us so any option you add to enhance this ability - any which way you decide to code it - will be a plus anyways.
 
I speak even slower.

Note says ‘Use of the ‘i = Update unbound installation’ **REQUIRED**

That’s what I did.

Update.

My bad, apologies.
No problem. - thanks for keeping me 'honest'.

P.S. I have updated the v2.10 Release notes with appropriate rewording:

"For this release ONLY - After the standard 'u' command, use of the 'i = Update unbound Installation' **REQUIRED**"
Going forward, in future unbound_manager release notes I will try to remember to explicitly advise if the 'i' command is required.....but if omitted then assume that the 'i' command is not required.
 
Last edited:
As I've previously stated, the core unbound installation itself is (touch-wood superstitiously) considered stable/final, i.e. the script is now basically only adding (bloat :eek:?) features to the menu etc.

Managing the Entware packages is already conveniently handled via amtm, so the need to use 'i = Update unbound Installation' after the initial install is now probably zero for most adopters.

Here are the only reasons where the 'i' command is required
  1. Download a new 'unbound.conf' to take advantage of any new base configuration settings.
  2. Adding options such as 'CPU/Performance Tweaks' that were skipped during the initial install.
  3. Downloading a new kernel 'stuning' script related to the above'CPU/Performance Tweaks' .
  4. (Retrieve a new Ad Block configuration script 'gen_adblock.sh' containing updated blocklists) - no longer currently maintained :(

P.S: Thanks (and kudos) to @JSewell [post #481 I will add the ability to retain the cache across an unbound restart 'rs' (or even after an uninstall/reinstall combo 'z' + 'i' if this a feature that should be an option?)


Re the Ad Block, should it be removed as an option then?
If no longer maintained, perhaps redundant? Particularly with Diversion close at hand.:)
 
Last edited:
Re the Ad Block, should it be removed as an option then?
If no longer maintained, it’s presence is redundant? Particularly with Diversion close at hand.:)
If you opt to install Ad Block, then the daily update will retrieve both the StevenBlack Adlist and the DNSWarden domain list.

So assuming that the two lists are maintained you have approx. 50K valid entries in the daily Ad Block blocking list.

The original SME tinkered with the blocking lists, so that is what I meant by it's no longer maintained i.e. suppose @Asad Ali's list would be a good addition to the current Ad Block lists...who would update the script?
 
Last edited:
So now we get into the need for menu options that should manage the cache status...i.e. should an auto (cron) save every hour be necessary, or an option to reset/flush the saved cache file etc.

With cache reloading in unbound manager, I would suggest making "Reload cache after restart? (y/n)" a user prompt when performing an 'rs'. If they select "y", then the cache is preserved and reloaded; if 'n', then the cache is reset (I can see times when you might want the cache to be cleared at restart).

Another caveat to consider is that the cache gets saved as a plain text file, which may be a privacy concern. You could delete the cache file after it has done its purpose for the 'rs', but some may feel uneasy about the regular saving of a plain text cache via cron.
 
urrent Ad Block lists...who would update the script?
The Adblock script/Unbound provides a complete unbound experience. With less dependence on dnsmasq, there will be little compatibility issues with Merlin FW or Skynet. I don't have any of the connectivity issues reported here.
I suggest that you organize the adblock script, since it depends exclusively on the unbound.conf file so that it works efficiently. Due to his advanced knowledge in shell scripting and now knowledge in unbound, you can do magic.
As for the ip-ratelimit=100, it did its job correctly. I was happy to add it.
 
In my opinion a user should decide for himself which of the two ad-block scripts he wants to use. Competition and or at least alternatives are always good.

:)
 
Hi people, I'm having an issue when rebooting. Time not getting set during the early stages. It finally syncs time well after the gui is available. If I enable or set to yes: "Wan: Use local caching DNS server as system resolver (default: No) Yes" then time syncs no problem. Is there a fix for this? I added a dnsmasq.conf.add file with server=/time.nrc.ca/142.165.21.5 and this has no effect.
 
When I first visit, say, smh.com.au does Unbound send the request from my device to a DNS server then cache that site for the next time I access it? I'm just trying to understand how Unbound works.

Also, is it recommended enabling logging in Unbound Manager?
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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