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

[Martineau]

What aspect of it doesn't work... to all intents and appearances the domain seems to be added to the view... the view_local_zone command works but how the script deals with it needs work?

Try adding additional views, then try adding a domain to the first 'view:'

small typo

OK thanks.

I've uploaded a patched 3.17bD Beta to GitHub dev to address both issues.

 

[tomsk]

Try adding additional views, then try adding a domain to the first 'view:'

Ah yes i see it... the local-zone is still tacked on to the last view in the list ..... thanks!

Fixed in 3.17bD url ends up in the right view now but unbound directly restarted...didn't see any confirmation feedback text like before

 

[JemTheWire]

How do I enter the advanced menu? (advanced tools)

Type: unbound_manager advanced

 

[Mathieu]

It depends on what you wish to achieve/obfuscate.

Using the Firmware's inbuilt DNS DoT, then you can securely encrypt/hide ALL of your LAN Clients DNS queries irrespective if they use the VPN tunnel or WAN, i.e. neither your ISP or VPN provider should be able to see the DNS requests.

Installing unbound as your own recursive DNS, you can either force your VPN LAN clients to only use the VPN ISP's DNS servers (Accept DNS Configuration=EXCLUSIVE) or allow ANY LAN client to experience potentially faster DNS lookups via unbound.

NOTE: unbound DNS requests are secure but (currently pending ADoT) not encrypted, however with care, for basic obfuscation, you can configure unbound to send all of its Root DNS requests outbound via the VPN tunnel - but this will invariably be slower.

If you are concerned that either your ISP or VPN ISP can (based on your browsing habits) easily create a saleable advertisers target profile, then unbound is a good decision, but even if you do install unbound as your own private recursive DNS, then be aware, theoretically your ISP (using packet-sniffing) could still create a profitable advertisers profile.

YMMV.

Thank you.

My VPN ISP is rather fussy when it comes to config, so I will stick to the 'Accept DNS Configuration=EXCLUSIVE' you suggest.
I am using rules-based selective routing to only direct certain clients through the tunnel.
As I understand it, this takes precedence over the router's general DNS settings, which in turn I plan to configure to use Unbound. That way, the rest of my LAN clients should enjoy its benefits.

I appreciate the tradeoff between speed and privacy/encryption, and am willing to it a go.
Ah!... and obviously I shall keep an eye of any ADoT development

Again, thank you for responding and for the countless hours you put in this project.

 

[Martineau]

I've uploaded v3.17

Version=3.1
Github md5=f54b187ce58ed9e9416b0ec67a070008
​

use 'u' to update when prompted on screen

Use of the 'i = Update unbound Installation' ** not required **

FIX:     'unbound-control reload' can apparently cause unbound to (silently) terminate? so add a temporary work-around to simply restart unbound.
CHANGE:  Enhance diagnostics 'debug' command
ADD:     'views' command for use when in dnsmasq bypass mode. i.e. unbound 'views:' allow customising the DNS query response based on the source IP Address.

Options syntax: [ ['?' | ''uninstall'] | [ {view_name ['?' | 'remove']} ] | { view_name domain_name [domain_name[...] | IP_address[...] ['del'] }]

e,g. Set up a category/classification 'view:' named "NoSocial" that blocks access to the specified domains but is only applied to the specified source IP Addresses:

e  = Exit Script [?]

A:Option ==> views NoSocial facebook.com tiktok.com tumblr.com instagram.com 192.168.10.0/24 192.168.11.55 192.168.12.0/28

    unbound view: name: "NoSocial" created

    unbound view: name: "NoSocial" added facebook.com. refuse
    unbound view: name: "NoSocial" added tiktok.com. refuse
    unbound view: name: "NoSocial" added tumblr.com. refuse
    unbound view: name: "NoSocial" added instagram.com. refuse
    unbound view: name: "NoSocial" added 192.168.10.0/24
    unbound view: name: "NoSocial" added 192.168.11.55/32
    unbound view: name: "NoSocial" added 192.168.12.0/28

09:02:15 Checking 'unbound.conf' for syntax errors.....

<snip>

e  = Exit Script [?]

A:Option ==> ?

<snip>
 
    [✔] unbound Logging
    [✔] Ad and Tracker Blocking (No. of Adblock domains=95296,Blocked Hosts=3,Whitelist=19)
    [✔] unbound CPU/Memory Performance tweaks
    [✔] Firefox DNS-over-HTTPS (DoH) DISABLE/Blocker
    [✔] Router Graphical GUI statistics TAB installed
    [✔] unbound-control FAST response ENABLED
    [✔] YouTube Ad Blocking (Forcing to use YT IP 62.24.208.18, No. of YouTube Video Ad domains=35)
    [✔] unbound 'views:' ENABLED (2 views)

e  = Exit Script [?]

A:Option ==> views ?

    Current unbound 'views:'

    "NoSocial"
    "test3"

e  = Exit Script [?]

A:Option ==> views NoSocial ?

    unbound view: name: "NoSocial" Client entries

    access-control-view: 192.168.12.0/28 "NoSocial"
    access-control-view: 192.168.11.55/32 "NoSocial"
    access-control-view: 192.168.10.0/24 "NoSocial"

    unbound view: name: "NoSocial" local-data entries

    unbound view: name: "NoSocial" local-zones entries

tiktok.com. refuse
tumblr.com. refuse
facebook.com. refuse
instagram.com. refuse

 

[Martineau]

Ah yes i see it... the local-zone is still tacked on to the last view in the list ..... thanks!

Fixed in 3.17bD url ends up in the right view now but unbound directly restarted...didn't see any confirmation feedback text like before

Confirmation messages added in v3.17 - also using 'viewsx' you will now be prompted to confirm the unbound restart, just in case you are mid-way through bulk updating the 'unbound.conf.views' manually.

Similarly you can also create several 'views?' on the command line sequentially and only restart unbound when you are ready.

 

[tomsk]

Confirmation messages added in v3.17 - also using 'viewsx' you will now be prompted to confirm the unbound restart, just in case you are mid-way through bulk updating the 'unbound.conf.views' manually.

Similarly you can also create several 'views?' on the command line sequentially and only restart unbound when you are ready.

Superb!

Unlikely scenario... but if you use viewsx before creating a view on the command line there will be an MD5 error as file isn't there yet....

md5sum: can't open '/opt/share/unbound/configs/unbound.conf.views': No such file or directory

 

[Martineau]

Unlikely scenario... but if you use viewsx before creating a view on the command line there will be an MD5 error as file isn't there yet....

md5sum: can't open '/opt/share/unbound/configs/unbound.conf.views': No such file or directory

Many thanks for exposing/reporting this obscure error.

Hotfix

v3.17
Github md5=560ce0fd2836e0c31f0601890dcdbb34
​

The Hotfix also now includes revised logic to reduce the need to restart unbound every time you modify an existing 'view:'

P.S. If you have time can you see if unbound silently terminates on the console?

e.g. using 'unbound_manager' ensure unbound is running, then exit 'unbound_manager'

if you manually issue:

unbound-control reload

using 'unbound_manager', check if unbound still running? ......check Syslog

fatal error: Could not read config file: /unbound.conf.

- if not immediately 'rs'

 

[tomsk]

Many thanks for exposing/reporting this obscure error.

Hotfix

v3.17
Github md5=560ce0fd2836e0c31f0601890dcdbb34
​

The Hotfix also now includes revised logic to reduce the need to restart unbound every time you modify an existing 'view:'

P.S. If you have time can you see if unbound silently terminates on the console?

e.g. using 'unbound_manager' ensure unbound is running, then exit 'unbound_manager'

if you manually issue:

unbound-control reload

using 'unbound_manager', check if unbound still running? ......check Syslog

fatal error: Could not read config file: /unbound.conf.

- if not immediately 'rs'

I can confirm that issuing the unbound-control reload command kills unbound silently in the console, but for me ( tried twice) there is nothing in syslog, only the dnsmasq restart stuff as a consequence... i shouldn't have to dial up the logging level right?.... that pretty terminal

EDIT: Sorry its there in the unbound section rather than the system messages ( go syslogNG)!

unbound: [21586:0] fatal error: Could not read config file: /unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf

 

[Martineau]

I can confirm that issuing the unbound-control reload command kills unbound silently in the console, but for me ( tried twice) there is nothing in syslog, only the dnsmasq restart stuff as a consequence... i shouldn't have to dial up the logging level right?.... that pretty terminal

Thanks for testing/confirmation that you can replicate the issue.

NOTE: I use scribe, so the message was moved/filtered from Syslog

 

[tomsk]

Do you think it would be worth including a viewsh option with an example views.conf file?
You can really mess with the scripts views duplicates checking if you don't follow the format when editing manually.

 

[Martineau]

Do you think it would be worth including a viewsh option with an example views.conf file?
You can really mess with the scripts views duplicates checking if you don't follow the format when editing manually.

You mean something like

                              v  = View ('/opt/var/lib/unbound/') unbound Configuration (vx=Edit;vh=help)


e  = Exit Script [?]

A:Option ==> vh

 

[tomsk]

You mean something like

                              v  = View ('/opt/var/lib/unbound/') unbound Configuration (vx=Edit;vh=help)


e  = Exit Script [?]

A:Option ==> vh

View attachment 23853

Yes indeed... i knew we had the vh there for help with the unbound.conf file, so i was thinking something similar for the views... i found that if i do a manual edit of the views file, its important to follow the way that the script adds entries with the zones and access-control-view statements remarked, or when you try a subsequent entry through a views command, all kinds of havoc can break loose.

 

[Martineau]

Yes indeed... i knew we had the vh there for help with the unbound.conf file, so i was thinking something similar for the views..

Not sure I get your point?

'vh' shows useful examples of every possible unbound.conf configuration statement including a working sample 'view:' clause?

The 'local-data/local-zone/local-data-ptr' statements format remain unchanged when included in a 'view:', but simply have a different execution scope.

i found that if i do a manual edit of the views file, its important to follow the way that the script adds entries with the zones and access-control-view statements remarked, or when you try a subsequent entry through a views command, all kinds of havoc can break loose.

The "devil is always in the detail"

There are 'experts' who wish do do their own thing, so having read and hopfully actually comprehended the appropriate manual, it is their prerogative to manually edit the 'view:' template without resorting to my script.

Using the script's separate 'include:' files allows these 'templates' to be generated/referenced but I certainly don't expect my use of remarks/comments needs to be followed unless you wish to continue to use my script .

i.e. for the 'views xxxx remove' command and to prevent spurious '***ERROR duplicates' messages etc.

 

[tomsk]

The "devil is always in the detail"

There are 'experts' who wish do do their own thing, so having read and hopfully actually comprehended the appropriate manual, it is their prerogative to manually edit the 'view:' template without resorting to my script.

Using the script's separate 'include:' files allows these 'templates' to be generated/referenced but I certainly don't expect my use of remarks/comments needs to be followed unless you wish to continue to use my script .

i.e. for the 'views xxxx remove' command and to prevent spurious '***ERROR duplicates' messages etc.

It was this aspect i was alluding to ...the work you have done with the views script makes it very convenient and an absolute doddle to create and modify views albeit constrained to refuse local-zones. After doing some manual editing, depending on what you have 'expertly' done, its sometimes not so easy to go back to using the views within the script.... i'm even thinking maybe leaving the script generated views.conf alone and adding a separate custom views file with another include statement would be better for "freestyle" views

 

[Martineau]

It was this aspect i was alluding to ...the work you have done with the views script makes it very convenient and an absolute doddle to create and modify views albeit constrained to refuse local-zones. After doing some manual editing, depending on what you have 'expertly' done, its sometimes not so easy to go back to using the views within the script.... i'm even thinking maybe leaving the script generated views.conf alone and adding a separate custom views file with another include statement would be better for "freestyle" views

So I should add ALL of the possible types rather than limit the script to only type 'refuse' when removing the view?

local VIEW_TYPES="refuse"     <<< include 'redirect' etc.

for VIEW_TYPE in $VIEW_TYPES
   do
      unbound-control -q view_local_zone_remove $VIEWNAME $VIEW_TYPE
      unbound-control -q view_local_data_remove $VIEWNAME $VIEW_TYPE
   done

I'm not sure if you intend to use these elements in views....

local-data-ptr
response-ip
response-ip-data

but as long as you tag any of the above with the owner $VIEWNAME, then the script should tolerate any manual edits to 'unbound.conf.views' unless you have examples demonstrating why it doesn't?

 

[tomsk]

So I should add ALL of the possible types rather than limit the script to only type 'refuse' when removing the view?

local VIEW_TYPES="refuse" <<< include 'redirect' etc.

for VIEW_TYPE in $VIEW_TYPES
do
unbound-control -q view_local_zone_remove $VIEWNAME $VIEW_TYPE
unbound-control -q view_local_data_remove $VIEWNAME $VIEW_TYPE
done

I wasn't aware you had that level of control ... looking at the blurb it would appear that you can specify the view name and type when you add but when you want to remove it doesn't mention the type.....

view_list_local_zones    view    list local-zones in view
view_list_local_data    view    list local-data RRs in view
view_local_zone view name type      add local-zone in view
view_local_zone_remove view name      remove local-zone in view
view_local_data view RR...        add local-data in view
view_local_datas view         add list of local-data to view one entry per line read from stdin
view_local_data_remove view name      remove local-data in view
view_local_datas_remove view         remove list of local-data from view one entry per line read from stdin

but yes for me the possibility to remove any view regardless of type would be good.

I'm not sure if you intend to use these elements in views....

local-data-ptr
response-ip
response-ip-data

i understand the pointer but i didn't see the other two in NL Labs man pages for unbound.conf or unbound-control (maybe i'm blind).. so i did some looking on t'interweb

response-ip: <IP-netblock> <action>
If the IP address in an AAAA or A RR in the answer section of a response matches the specified IP-netblock, the specified action will apply. <action> has generally the same semantics as that for access-control-tag-action, but there are some exceptions (see below).

response-ip-data: <IP-netblock> <”resource record string”>
This specifies the action data for response-ip with action being redirect. “resource record string” is similar to that of access-control-tag-action, but it must be of either AAAA, A, or CNAME. If the IP-netblock is an IPv6/IPv4 prefix, the record must be AAAA/A, respectively unless it’s CNAME (which can be used for both versions of IP netblocks). If it’s CNAME, there must not be more than one response-ip-data for the same IP-netblock. Also, CNAME and other types of records must not coexist for the same IP-netblock. The textual domain name for the CNAME does not have to be explicitly terminated with a dot (.); the root name is assumed to be the origin for the name.

I can see some potentially interesting things to do with these.... i'll see how "script friendly" i can keep the unbound.views.conf ... as you say if i religiously tag the owner $VIEWNAME it shouldn't break.

Really thanks for stimulating my interest in this... its a fascinating subject.

 

[Martineau]

I can see some potentially interesting things to do with these.... i'll see how "script friendly" i can keep the unbound.views.conf ... as you say if i religiously tag the owner $VIEWNAME it shouldn't break.

@tomsk FYI, I've uploaded Hotfix v3.17

Version=3.1
Github md5=2a8a161364b530838f97eb35777fc771​

I've added support for the following 'local-zone' types in 'views:'

VALID_VIEW_TYPES="deny refuse static transparent redirect nodefault typetransparent inform inform_deny inform_redirect always_transparent always_refuse always_nxdomain noview"

e.g. specify the type before the domain (default type=refuse)

e  = Exit Script [?]

A:Option ==> views test www.refuse.com deny www.deny.com www.deny2.com noview www.noview.com

    unbound view: name: "test" created

    unbound view: name: "test" added domain "www.refuse.com" 'type=refuse'
    unbound view: name: "test" added domain "www.deny.com" 'type=deny'
    unbound view: name: "test" added domain "www.deny2.com" 'type=deny'
    unbound view: name: "test" added domain "www.noview.com" 'type=noview'

e  = Exit Script [?]

A:Option ==> views test

    unbound view: name: "test" Client entries

    unbound view: name: "test" local-data entries

    unbound view: name: "test" local-zones entries

www.deny.com. deny
www.deny2.com. deny
www.noview.com. noview
www.refuse.com. refuse

e  = Exit Script [?]

A:Option ==> views test remove

Removing unbound view: name: "test" 'types='deny noview refuse '; Please wait for up to 12 secs.....

 

[tomsk]

@tomsk FYI, I've uploaded Hotfix v3.17

Version=3.1
Github md5=2a8a161364b530838f97eb35777fc771​

I've added support for the following 'local-zone' types in 'views:'

VALID_VIEW_TYPES="deny refuse static transparent redirect nodefault typetransparent inform inform_deny inform_redirect always_transparent always_refuse always_nxdomain noview"

e.g. specify the type before the domain (default type=refuse)

e  = Exit Script [?]

A:Option ==> views test www.refuse.com deny www.deny.com www.deny2.com noview www.noview.com

    unbound view: name: "test" created

    unbound view: name: "test" added domain "www.refuse.com" 'type=refuse'
    unbound view: name: "test" added domain "www.deny.com" 'type=deny'
    unbound view: name: "test" added domain "www.deny2.com" 'type=deny'
    unbound view: name: "test" added domain "www.noview.com" 'type=noview'

e  = Exit Script [?]

A:Option ==> views test

    unbound view: name: "test" Client entries

    unbound view: name: "test" local-data entries

    unbound view: name: "test" local-zones entries

www.deny.com. deny
www.deny2.com. deny
www.noview.com. noview
www.refuse.com. refuse

e  = Exit Script [?]

A:Option ==> views test remove

Removing unbound view: name: "test" 'types='deny noview refuse '; Please wait for up to 12 secs.....

Very nice!! thanks for continuing to push the boundaries of what can be achieved with views from within the script.

Im assuming that putting the local zone type before the domain was a coding limitation or avoided having to re-write the whole thing.... Will you include the syntax in the menu as its out of the order you might natrually expect?

 

[ugandy]

would it make sense to edit post #1 with a quick example on the use of this new feature?