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!

Brilliant! :) -thanks for the feedback.....although seemingly no one in your home is allowed to access YouTube if they are on that subnet? - seems a bit harsh:p
i'm just playing around with what's possible... No Peppa Pig Zone!........ Thats a guest network so lets say you might want to restrict guests from accessing certain domains, blocking the whole subdomain means you don't have to mess about trying to chase an IP dished out to guest machines by DHCP. The advantage is the view tree can be as complicated as you like but it wont affect your other IP ranges.
 
i'm just playing around with what's possible... No Peppa Pig Zone!........ Thats a guest network so lets say you might want to restrict guests from accessing certain domains, blocking the whole subdomain means you don't have to mess about trying to chase an IP dished out to guest machines by DHCP. The advantage is the view tree can be as complicated as you like but it wont affect your other IP ranges.
I'm pleased this useful feature can give you ample opportunities for tinkering. :p

I can't see an unbound-control command that would list the IP/subnets defined in the 'view:' but once I add the ability, I'll formally release v3.17

Again, many thanks for testing my impossible ideas! ;)
 
Just trying
Code:
# View: NoYouTube Clients

access-control-view: 10.11.12.0/24 "NoYouTube"
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube

# View: SomeDomain Clients
access-control-view: 10.11.12.125/32 "SomeDomain"
view:
    name: "SomeDomain"
    view-first: yes
    local-zone: "somedomain.com." refuse
# EndView: SomeDomain
makes unbound throw a wobbler with a syntax error for unbound.conf.views . But
Code:
# View: NoYouTube Clients
access-control-view: 10.11.12.0/24 "NoYouTube"
access-control-view: 10.11.12.125/32 "SomeDomain"
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube

# View: SomeDomain Clients
view:
    name: "SomeDomain"
    view-first: yes
    local-zone: "somedomain.com." refuse
# EndView: SomeDomain
works ok? .... can you reproduce i initially thought it was because the 2nd IP was a subset of the first IP range ... but i tried with a different subnet with same result.
 
Just trying
Code:
# View: NoYouTube Clients

access-control-view: 10.11.12.0/24 "NoYouTube"
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube

# View: SomeDomain Clients
access-control-view: 10.11.12.125/32 "SomeDomain"
view:
    name: "SomeDomain"
    view-first: yes
    local-zone: "somedomain.com." refuse
# EndView: SomeDomain
makes unbound throw a wobbler with a syntax error for unbound.conf.views . But
Code:
# View: NoYouTube Clients
access-control-view: 10.11.12.0/24 "NoYouTube"
access-control-view: 10.11.12.125/32 "SomeDomain"
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube

# View: SomeDomain Clients
view:
    name: "SomeDomain"
    view-first: yes
    local-zone: "somedomain.com." refuse
# EndView: SomeDomain
works ok? .... can you reproduce i initially thought it was because the 2nd IP was a subset of the first IP range ... but i tried with a different subnet with same result.
Whoops :oops::rolleyes::rolleyes:

I've uploaded v3.17bB to GitHub dev.

Unfortunately I have had to alter the view header markers so you will need to delete your current 'views:'
Code:
e  = Exit Script [?]

A:Option ==> views uninstall
then recreate them - sorry :oops:

I have updated the 'views view_name ?' detail query to now include the client list assigned to the 'view:'
Code:
e  = Exit Script [?]

A:Option ==> views NoTwitter ?

    unbound view: 'NoTwitter' Client entries

    access-control-view: 192.168.30.33/32 "NoTwitter"

    unbound view: 'NoTwitter' local-zones entries

twitter.com. refuse

    unbound view: 'NoTwitter' local-data entries
Also, if like me you find yourself creating a 'view:' called "uinstall" because of typos, this should now no longer be possible!.

Again, many thanks for your patience in testing my shoddy coding.
 
Last edited:
Whoops :oops::rolleyes::rolleyes:

I've uploaded v3.17bB to GitHub dev.

Unfortunately I have had to alter the view header markers so you will need to delete your current 'views:'
Code:
e  = Exit Script [?]

A:Option ==> views uninstall
then recreate them - sorry :oops:

I have updated the 'views view_name ?' detail query to now include the client list assigned to the 'view:'
Code:
e  = Exit Script [?]

A:Option ==> views NoTwitter ?

    unbound view: 'NoTwitter' Client entries

    access-control-view: 192.168.30.33/32 "NoTwitter"

    unbound view: 'NoTwitter' local-zones entries

twitter.com. refuse

    unbound view: 'NoTwitter' local-data entries
Also, if like me you find yourself creating a 'view:' called "uinstall" because of typos, this should now no longer be possible!.

Again, many thanks for your patience in testing my shoddy coding.
My pleasure to test for you ... i'm a shockingly bad coder so i feel that this is probably the best way i can contribute to the hard work you are putting in on this.

I note that when i tried to make an initial
Code:
views NoYouTube youtube.com 10.11.12.0/24
the view was created but not the access-control-view entry. Im assuming this was because i added the CIDR myself.
 
My pleasure to test for you ... i'm a shockingly bad coder so i feel that this is probably the best way i can contribute to the hard work you are putting in on this.

I note that when i tried to make an initial
Code:
views NoYouTube youtube.com 10.11.12.0/24
the view was created but not the access-control-view entry. Im assuming this was because i added the CIDR myself.
What does the following show?
Code:
head -n 3  /opt/share/unbound/configs/unbound.conf.views
 
What does the following show?
Code:
head -n 3  /opt/share/unbound/configs/unbound.conf.views
Code:
tOmsK@RT-AC68U-4690:/tmp/home/root# head -n 3  /opt/share/unbound/configs/unbound.conf.views
# View: Clients
access-control-view: 10.11.12.196/32 "NoGoogle"
access-control-view: 10.11.12.0/24 "NoYouTube"

After creating the view initially with
Code:
views NoYouTube youtube.com 10.11.12.0/24
the access-contol-view statement for NoYouTube was missing, so i added it with a 2nd run of
Code:
views NoYouTube 10.11.12.0/24
that was accepted and appeared in the views file. Adding a NoGoogle view for one client via
Code:
views NoGoogle google.com 10.11.12.196
worked perfectly ... view clause and access-control-view statement added in one action.
 
I tried a third time
Code:
views NoNextDNS NextDNS.io 10.11.12.0/24
as previously the view clause showed but not the access-control-view statement
Code:
# View: Clients
access-control-view: 10.11.12.196/32 "NoGoogle"
access-control-view: 10.11.12.0/24 "NoYouTube"
# EndView Clients


# View: NoYouTube
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube
# View: NoGoogle
view:
    name: "NoGoogle"
    view-first: yes
    local-zone: "google.com." refuse
# EndView: NoGoogle
# View: NoNextDNS
view:
    name: "NoNextDNS"
    view-first: yes
    local-zone: "nextdns.io." refuse
# EndView: NoNextDNS

however this time when i try to add the access-control-view statement i get
Code:
A:Option ==> views NoNextDNS 10.11.12.0/24


    ***ERROR unbound view: 'NoNextDNS' already contains '10.11.12.0/24'!
Code:
A:Option ==> views NoNextDNS ?

    unbound view: 'NoNextDNS' Client entries


    unbound view: 'NoNextDNS' local-zones entries

nextdns.io. refuse

    unbound view: 'NoNextDNS' local-data entries

Hope this might help nail it down?

not sure if adding multiple views to one access-control-view statement is ok (like access-control-tag) ie
Code:
access-control-view: 10.11.12.0/24 "NoYouTube NoNextDNS"
although in this case were i not just experimenting, the best would be to just add the nextDNS.io local zone to the NoYouTube view as its the same IP range
 
Last edited:
At the risk of exposing my lack of scripting skills (again) ... are we experiencing a curly bracket shortage here?.... or is it not required because its a local variable
line 4457/4458
Code:
 sed -i "/# View: Clients/aaccess-control-view: ${IP_ADDR}$CIDR \"$VIEWNAME\"" $FN
 echo -e $cBCYA"\n\tView: '$VIEWNAME' added "${IP_ADDR}$CIDR"\n"$cRESET 2>&1

should be?
Code:
 sed -i "/# View: Clients/aaccess-control-view: ${IP_ADDR}${CIDR} \"$VIEWNAME\"" $FN
 echo -e $cBCYA"\n\tView: '$VIEWNAME' added "${IP_ADDR}${CIDR}"\n"$cRESET 2>&1
line 4487
Code:
local TXT="for ${IP_ADDR}$CIDR"
# Can't use Smart_LineInsert
sed -i "/# View: Clients/aaccess-control-view: ${IP_ADDR}$CIDR \"$VIEWNAME\"" $FN

should be?
Code:
local TXT="for ${IP_ADDR}${CIDR}"
# Can't use Smart_LineInsert
sed -i "/# View: Clients/aaccess-control-view: ${IP_ADDR}${CIDR} \"$VIEWNAME\"" $FN

I tried editing the script with the brackets but it didn't seem to make any difference anyway ...just curious
For most purposes
Code:
$var
is the same as
Code:
${var}
but technically the ${} denotes Bash "Shell Parameter Substitution" which annoys the POSIX zealots.

e.g. Quickly and succinctly set a variable to be the length of an assigned variable without using any external utilities
Code:
STRING="Hello"

LEN=${#STRING}
rather than invoke two external utilities
Code:
STRING="Hello"

LEN=$(echo "$STRING" | wc -c)

or

LEN=$(echo "$STRING" | awk '{print length}')
However when concatenating strings the {} are significant

e.g. This won't produce the expected result
Code:
var="This is a"
echo "$varTEXT_STRING"
but this will
Code:
var="This is a"
echo "${var}TEXT_STRING"
However, using notepad++ to edit the scripts, for me personally, it is simply a colour-coded eye catcher so that I can usually spot typo errors when concatenating two variables...although I'm not consistent!

upload_2020-5-29_16-48-1.png
 
Last edited:
Greetings from another profane.

I am attracted to @Martineau 's work on Unbound integration (thank you) for, chiefly, its reported improved DNS resolution features. I also happen to use a commercial OpenVPN service for geoblock reasons, and I should be grateful if some knowledgeable member of this forum could explain -in layman's terms- the pros and cons of using those concurrently, along with any recommended GUI (sic) tweaks.
Must say I am quite happy for the OpenVPN clients not to rely on Unbound for their queries.
Currently in the process of 'RTFM', I've gone through posts (in the #1 to #350 range, and counting) touching on the subject, though it seemed to me the jury was still out.
I'll keep reading, but as this thread is fast approaching 2.5K post, there's a chance I pass away before my router, hence my call to help.

Thank you people.
 
I tried a third time
Code:
views NoNextDNS NextDNS.io 10.11.12.0/24
as previously the view clause showed but not the access-control-view statement
Code:
# View: Clients
access-control-view: 10.11.12.196/32 "NoGoogle"
access-control-view: 10.11.12.0/24 "NoYouTube"
# EndView Clients


# View: NoYouTube
view:
    name: "NoYouTube"
    view-first: yes
    local-zone: "youtube.com." refuse
# EndView: NoYouTube
# View: NoGoogle
view:
    name: "NoGoogle"
    view-first: yes
    local-zone: "google.com." refuse
# EndView: NoGoogle
# View: NoNextDNS
view:
    name: "NoNextDNS"
    view-first: yes
    local-zone: "nextdns.io." refuse
# EndView: NoNextDNS

however this time when i try to add the access-control-view statement i get
Code:
A:Option ==> views NoNextDNS 10.11.12.0/24


    ***ERROR unbound view: 'NoNextDNS' already contains '10.11.12.0/24'!
Code:
A:Option ==> views NoNextDNS ?

    unbound view: 'NoNextDNS' Client entries


    unbound view: 'NoNextDNS' local-zones entries

nextdns.io. refuse

    unbound view: 'NoNextDNS' local-data entries

Hope this might help nail it down?

not sure if adding multiple views to one access-control-view statement is ok (like access-control-tag) ie
Code:
access-control-view: 10.11.12.0/24 "NoYouTube NoNextDNS"
although in this case were i not just experimenting, the best would be to just add the nextDNS.io local zone to the NoYouTube view as its the same IP range
My pleasure to test for you ... i'm a shockingly bad coder
I've got a limited exclusive Platinum Fellows' membership and personal permanent reserved parking spot in the Bad-Coders club!:D:cool:

Fixing the original code was trivial ( although didn't involve {} ) but second guessing what the user intended and also validating the input combinations / removal scenarios etc. was inconsistent.

A design review was necessary but simple 'views:' should now correctly work, but for more advanced 'views:' (i.e not just 'refuse' action) the use of the 'viewsx' command or more likely the native 'unbound-control' 'view_*' commands to manage/manipulate the 'views:' will be deemed more appropriate.

However I have rewritten the code to also conveniently allow specification of multiple domains/IP Addresses on the initial creation of the 'view:'

e.g. rather than have each domain in its own 'view:' such as 'NoYouTube youtube.com'
Code:
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>
Code:
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-zones entries

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

    unbound view: name: "NoSocial" local-data entries
Code:
e  = Exit Script [?]

A:Option ==> viewsv

  GNU nano 4.9.2

# View: Clients
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"
# EndView Clients
# View: NoSocial
view:
    name: "NoSocial"
    view-first: yes
    local-zone: "facebook.com." refuse          # "NoSocial"
    local-zone: "tiktok.com." refuse            # "NoSocial"
    local-zone: "tumblr.com." refuse            # "NoSocial"
    local-zone: "instagram.com." refuse         # "NoSocial"
# EndView: NoSocial
So effectively the syntax has slightly changed
Code:
[ ['?'] | [ {view_name '?'} ] | { view_name domain_name [domain_name... | IP_address...] } | { view_name IP_address ['del'] ]
I have uploaded a new Beta in Github dev if you wish to test the rewrite, although new bugs may have been introduced!
 
Last edited:
Playing with the views again today, i got a long list when i tried to look at my test NoYouTube view
Code:
A:Option ==> views NoYouTube ?

    unbound view: 'NoYouTube' Client entries

    access-control-view: 10.10.11.0/24 "NoYouTube"
    access-control-view: 10.11.12.186/32 "NoYouTube"
    access-control-view: 10.11.12.0/24 NoYouTube

    unbound view: 'NoYouTube' local-zones entries

my.nextdns.io. refuse
youtube.com. refuse
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. static
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. static
8.b.d.0.1.0.0.2.ip6.arpa. static
d.f.ip6.arpa. static
8.e.f.ip6.arpa. static
9.e.f.ip6.arpa. static
a.e.f.ip6.arpa. static
b.e.f.ip6.arpa. static
0.in-addr.arpa. static
10.in-addr.arpa. static
64.100.in-addr.arpa. static
etc...etc.. (shortened due character limitation)
255.255.255.255.in-addr.arpa. static
test. static
onion. static
invalid. static
localhost. redirect

    unbound view: 'NoYouTube' local-data entries

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    NS    localhost.

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    PTR    localhost.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    NS    localhost.

8.b.d.0.1.0.0.2.ip6.arpa.    10800    IN    NS    localhost.

8.b.d.0.1.0.0.2.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

d.f.ip6.arpa.    10800    IN    NS    localhost.

d.f.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

8.e.f.ip6.arpa.    10800    IN    NS    localhost.

8.e.f.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

9.e.f.ip6.arpa.    10800    IN    NS    localhost.

etc.. etc....

113.0.203.in-addr.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

255.255.255.255.in-addr.arpa.    10800    IN    NS    localhost.

255.255.255.255.in-addr.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

test.    10800    IN    NS    localhost.

test.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

onion.    10800    IN    NS    localhost.

onion.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

invalid.    10800    IN    NS    localhost.

invalid.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

localhost.    10800    IN    AAAA    ::1

localhost.    10800    IN    A    127.0.0.1

localhost.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

localhost.    10800    IN    NS    localhost.

I think its showing all the defaults added ... might be an idea to suppress those? ... or maybe
i added that "feature" inadvertently with my wild "curly bracketery" spree
local-zone: <zone> <type>
Configure a local zone. The type determines the answer to give
if there is no match from local-data. The types are deny,
refuse, static, transparent, redirect, nodefault, typetranspar-
ent, inform, inform_deny, inform_redirect, always_transparent,
always_refuse, always_nxdomain, noview, and are explained below.
After that the default settings are listed. Use local-data: to
enter data into the local zone. Answers for local zones are
authoritative DNS answers. By default the zones are class IN.
 
Playing with the views again today, i got a long list when i tried to look at my test NoYouTube view
Code:
A:Option ==> views NoYouTube ?

    unbound view: 'NoYouTube' Client entries

    access-control-view: 10.10.11.0/24 "NoYouTube"
    access-control-view: 10.11.12.186/32 "NoYouTube"
    access-control-view: 10.11.12.0/24 NoYouTube

    unbound view: 'NoYouTube' local-zones entries

my.nextdns.io. refuse
youtube.com. refuse
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. static
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. static
8.b.d.0.1.0.0.2.ip6.arpa. static
d.f.ip6.arpa. static
8.e.f.ip6.arpa. static
9.e.f.ip6.arpa. static
a.e.f.ip6.arpa. static
b.e.f.ip6.arpa. static
0.in-addr.arpa. static
10.in-addr.arpa. static
64.100.in-addr.arpa. static
etc...etc.. (shortened due character limitation)
255.255.255.255.in-addr.arpa. static
test. static
onion. static
invalid. static
localhost. redirect

    unbound view: 'NoYouTube' local-data entries

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    NS    localhost.

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    PTR    localhost.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.    10800    IN    NS    localhost.

8.b.d.0.1.0.0.2.ip6.arpa.    10800    IN    NS    localhost.

8.b.d.0.1.0.0.2.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

d.f.ip6.arpa.    10800    IN    NS    localhost.

d.f.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

8.e.f.ip6.arpa.    10800    IN    NS    localhost.

8.e.f.ip6.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

9.e.f.ip6.arpa.    10800    IN    NS    localhost.

etc.. etc....

113.0.203.in-addr.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

255.255.255.255.in-addr.arpa.    10800    IN    NS    localhost.

255.255.255.255.in-addr.arpa.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

test.    10800    IN    NS    localhost.

test.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

onion.    10800    IN    NS    localhost.

onion.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

invalid.    10800    IN    NS    localhost.

invalid.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

localhost.    10800    IN    AAAA    ::1

localhost.    10800    IN    A    127.0.0.1

localhost.    10800    IN    SOA    localhost. nobody.invalid. 1 3600 1200 604800 10800

localhost.    10800    IN    NS    localhost.

I think its showing all the defaults added ... might be an idea to suppress those? ... or maybe
i added that "feature" inadvertently with my wild "curly bracketery" spree
Rather than blindly display what is defined in 'unbound.conf.views', the script diligently uses the appropriate 'unbound-control' commands to interrogate the required 'view:' tree

e.g.
Code:
unbound-control view_list_local_zones NoYouTube

and

unbound-control view_list_local_data NoYouTube
so there should be no extraneous/spurious data records to filter?

If you bounce unbound then execute the above commands manually, do they still appear?

If they do then that will need to be raised with 'NLnet Labs' as a potential bug, unless you can identify if/how you inadvertently added them?
 
My question is, is there a way to use Unbound manager to still be able to forward dns entries to a "smart DNS proxy" that I use to bypass some location restrictions.
I think you meant to ask

"is there a way to use unbound manager to still be able to forward dns".

Short answer: Yes

If you use unbound_manager to install unbound as the upstream DNS for dnsmasq, then nothing will change with respect to the 'Smart DNS proxy' as I recall to use the Smart DNS proxy you define the domain to use the Smart DNS proxy xxx.xxx.xxx.xxx

e.g. Force Netflix to use the Smart DNS proxy xxx.xxx.xxx.xxx
Code:
server=/netflix.com/xxx.xxx.xxx.xxx

If you opt to install unbound, and bypass dnsmasq, then the unbound_manager migration 'dnsmasq disable' command should migrate the relevant directives into unbound.
 
Greetings from another profane.

I am attracted to @Martineau 's work on Unbound integration (thank you) for, chiefly, its reported improved DNS resolution features. I also happen to use a commercial OpenVPN service for geoblock reasons, and I should be grateful if some knowledgeable member of this forum could explain -in layman's terms- the pros and cons of using those concurrently, along with any recommended GUI (sic) tweaks.
Must say I am quite happy for the OpenVPN clients not to rely on Unbound for their queries.
Currently in the process of 'RTFM', I've gone through posts (in the #1 to #350 range, and counting) touching on the subject, though it seemed to me the jury was still out.
I'll keep reading, but as this thread is fast approaching 2.5K post, there's a chance I pass away before my router, hence my call to help.

Thank you people.
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.
 
Rather than blindly display what is defined in 'unbound.conf.views', the script diligently uses the appropriate 'unbound-control' commands to interrogate the required 'view:' tree

e.g.
Code:
unbound-control view_list_local_zones NoYouTube

and

unbound-control view_list_local_data NoYouTube
so there should be no extraneous/spurious data records to filter?

If you bounce unbound then execute the above commands manually, do they still appear?

If they do then that will need to be raised with 'NLnet Labs' as a potential bug, unless you can identify if/how you inadvertently added them?
I bounced unbound and ran the command from the command line and i got the same results.
These entries aren't in the unbound.conf.views but i believe are added to the list by default. Seems like you have to specify the nodefault option to prevent that..... I found out what change causes it.... i had been playing with the first-view setting to see what difference it made ..... setting it to no makes the command regurgitate that whole long list.
.... i thought it was something to do with the modifications i made, but it behaves the same after i updated to the latest beta (v3.17bC) .... guess this is ... "works as advertised"
 
New views creation all working ok... one thing i noticed after adding a new url to a view was that it appeared outside the endview remarks and every local-zone line is tagged with the view name as well...
Code:
# View: MySuperView
view:
    name: "MySuperView"
    view-first: yes
    local-zone: "mysuperview.com." refuse        # "MySuperView"
# EndView: MySuperView
    local-zone: "anothersuperview.com." refuse        # "MySuperView"
 
New views creation all working ok... one thing i noticed after adding a new url to a view was that it appeared outside the endview remarks and every local-zone line is tagged with the view name as well...
Code:
# View: MySuperView
view:
    name: "MySuperView"
    view-first: yes
    local-zone: "mysuperview.com." refuse        # "MySuperView"
# EndView: MySuperView
    local-zone: "anothersuperview.com." refuse        # "MySuperView"
Yup, as stated previously, adding domains to a view after the initial creation request won't currently work - I might change my mind.

As part of the necessary design review. adding the additional comment qualifier means that you can now have the same domain in multiple 'views:' - otherwise the script would previously moan about duplicate domains! ;)
 
Yup, as stated previously, adding domains to a view after the initial creation request won't currently work - I might change my mind
What aspect of it doesn't work... to all intents and appearances the domain seems to be added to the view...
Code:
A:Option ==> views MySuperView ?

    unbound view: name: "MySuperView" Client entries

    access-control-view: 10.11.12.0/24 "MySuperView"

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

mysuperview.com. refuse
anothersuperview.com. refuse

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

small typo
Code:
A:Option ==> views

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

advanced menu ok
Code:
    views = [ { uninstall | viewname { ? | remove } ] | {viewname url [ ip_address] } | {viewname ip_address [del]} ]
 
Last edited:

Similar threads

Latest 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