What's new

Unbound - Authoritative Recursive Caching 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!

Status
Not open for further replies.
I took the plunge and installed Unbound. Seems to be working. I did notice this error message in my log after rebooting the router that indicated a parsing error for cron. Any ideas?

Uninstall unbound, then upgrade to v1.21 and select install
 
Since @rgnldo's unbound.conf on Github allows all interfaces to listen, you have to limit the netstat output to the 127.0.0.1 lines. Plus my method assumes that S61unbound has a "service restart_dnsmasq" POSTCMD included. Which it doesn't anymore on Github. That way dnsmasq is only modified after unbound is successfully started.
Additionally, please take in account, if you use the UDP filter (-u switch), in some cases, due to UDP/netstat specifics, you will see the other "listening" ip+port combination.
When process via UPD after sending the request is waiting for the answer on request, it will be shown as a "listening" socket ....
To explain (in notation with # as port separator :), like it used for the environment variable):
  • unbound send DNS request to the external DNS server
    • Connection from OUTGOING_IP#RANDOM_PORT to EXT_DNS#53
    • will not be shown by your UNBOUNDLISTENADDR="$(netstat -nlup | awk '/unbound/ { print $4 } ' | tr ':' '#')" # unbound_installer
  • unbound is waiting for the answer form remote DNS
    • the answer will not be provided by previously established connection, it will be separate connection from external DNS to the unboud, so
    • unbound will start listen on OUTGOING_IP#RANDOM_PORT
    • and you can catch this IP+Port pair via "$(netstat -nlup | awk '/unbound/ { print $4 } ' | tr ':' '#')"
So, in case of configuring the unbound to work via both protocols (i.e. TCP and UDP), it make sense to use switch -t in "$(netstat -nltp | awk '/unbound/ { print $4 } ' | tr ':' '#')", to get only "real" listen IP+Ports ...
 
Uninstall unbound, then upgrade to v1.21 and select install

I really need to wait until after my first cup of coffee to do this stuff. Unfortunately, I tend to do router changes early in the morning to prevent interrupting my wife’s internet. Maybe I need to setup a different router for her only? :)
 
Return /etc/dnsmasq with line
Code:
server=127.0.0.1#953
0.0.0.0#53535
###53535
Yes, it's another point, why it required additional
grep -v '0.0.0.0', i.e.
$(netstat -nltp | grep -v '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#')

edit: wrong switch was proposed, it have be small one, instead capital in my initial version ...
 
Last edited:
Maybe I need to setup a different router for her only?
No. This error in cron does not interfere with the connection. Just schedule an update of root's server's. But it's quiet.
 
What is the difference if using Stubby or not? Right now I selected not to integrate with Stubby?
 
Also, for now I am not using the ad blocking services nor am I running Diversion.
 
Code:
server=
any error with direct run of the command ?
please run
netstat -nltp | grep -v '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
not from the script ... but from command prompt directly ?

Excuse me - use -v switch instead of -V
 
any error with direct run of the command ?
please run
netstat -nltp | grep -V '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
not from the script ... but from command prompt directly ?
Code:
netstat -nltp | grep -V '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
netstat: showing only processes with your user ID
 
Code:
netstat -nltp | grep -V '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
netstat: showing only processes with your user ID
Excuse me -
small one -v instead capital one -V in grep ...
i.e.
netstat -nltp | grep -v '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
 
Additionally, please take in account, if you use the UDP filter (-u switch), in some cases, due to UDP/netstat specifics, you will see the other "listening" ip+port combination.
When process via UPD after sending the request is waiting for the answer on request, it will be shown as a "listening" socket ....
To explain (in notation with # as port separator :), like it used for the environment variable):
  • unbound send DNS request to the external DNS server
    • Connection from OUTGOING_IP#RANDOM_PORT to EXT_DNS#53
    • will not be shown by your UNBOUNDLISTENADDR="$(netstat -nlup | awk '/unbound/ { print $4 } ' | tr ':' '#')" # unbound_installer
  • unbound is waiting for the answer form remote DNS
    • the answer will not be provided by previously established connection, it will be separate connection from external DNS to the unboud, so
    • unbound will start listen on OUTGOING_IP#RANDOM_PORT
    • and you can catch this IP+Port pair via "$(netstat -nlup | awk '/unbound/ { print $4 } ' | tr ':' '#')"
So, in case of configuring the unbound to work via both protocols (i.e. TCP and UDP), it make sense to use switch -t in "$(netstat -nltp | awk '/unbound/ { print $4 } ' | tr ':' '#')", to get only "real" listen IP+Ports ...
My own personal dnsmasq.conf contains a different command than adopted by the script. dnsmasq is only going to forward to a udp upstream port (I think), so I don't see the need to include tcp ports.
Code:
UNBOUNDLISTENADDR=$(netstat -nlup | grep "^udp.* 127\.0\..*\/unbound$" | head -1 | awk ' { print $4 } ' | tr ':' '#')
 
How much does this impact performance if any?
It depends, for me I was seeing over 300ms for initial lookups (before caching) with Stubby using Cloudflare DoH. But once cached, you will get 1ms DNS response as normal for Unbound.

For reference, without Stubby I see about 30ms (normally) to 268ms (with 268 being from another country) lookups without it. Running it this way (no Stubby) will have Unbound find the DNS queries itself rather than rely on someone like Cloudflare, Quad9, etc. That part is all up to personal preference!

As without Stubby, your lookups are in plaintext - but, they cannot be modified mid-stream either due to DNSSEC from root DNS servers being used in Unbound. It all comes down to who do you trust more? ISP, DNS proivder, or your private Unbound instance? Personally, to me, it doesn't matter because my ISP can see my outgoing IPs once DNS is used regardless of encryption. But again, all up to user preference! And Stubby is especially helpful if you live in a more..surveillance friendly country.

TL;DR: Stubby adds a layer of encryption, and also removes Unbound's use as a fully recursive DNS server (it instead becomes a cache / forwarder only to Stubby), which for me, increased DNS query latency about 10 fold (~300ms average). Upside is, your ISP (or snoopers) won't see Unbound going out and getting DNS answers itself. My take is, my ISP will see those IPs anyway once I get the encrypted query back..so it's up to you!

No stubby = faster performance, secure as long as you are comfortable with your ISP seeing Unbound traffic (but it is not possible to manipulate due to DNSSEC @ root). Or if you believe your ISP will track you either way through Deep Packet Inspection (DPI).

Stubby = more secure if you trust the DNS provider, no one can see your lookups, but your ISP will still see all of your (IP) internet traffic, and likely still be able to profile you (via DPI and the IPs you visit). If you don't want that, put your whole network on a VPN :p
 
Last edited:
Excuse me -
small one -v instead capital one -V in grep ...
i.e.
netstat -nltp | grep -v '0.0.0.0' | awk '/unbound/ { print $4 } ' | tr ':' '#'
My own personal dnsmasq.conf contains a different command than adopted by the script. dnsmasq is only going to forward to a udp upstream port (I think), so I don't see the need to include tcp ports.
The script uses the PID condition. This is enough for unbound operation and configuration. There is no need for demand for TCP or UDP. Both will be served.
Code:
if [ -n "$(pidof unbound)" ];then
 
I am getting better good adblock results with these options. Has anyone tested?
POST
 
Having to manually edit every time (or execute a script) to change "interface: 0.0.0.0" to "interface: 127.0.0.1" is getting on my nerves. How does it work for everyone but me? there have got to be a reason why 0.0.0.0 just won't work.
I am not running diversion . Only skynet
 
Status
Not open for further replies.

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!

Staff online

Top