Unbound - Authoritative Recursive Caching DNS Server

[rgnldo]

Older versions (Dec 20) automatically applied the changes without the complete unbound_installer comment. So the current script would not remove those lines.

As you are an experienced user, you can organize IPTABLES rules for your needs.

 

[Delusion]

Also check /jffs/scripts/firewall-start for the dns redirection.

Thank you. "/jffs/scripts/firewall-start" had entries which were not cleared. now it works fine

 

[rgnldo]

I have a quick question that has been talked about but that I don't see a specific answer to: If I do not have stubby installed (as a script) but am using DoT in Merlin, should I integrate stubby in the setup? Also, while I'm asking, since I'm using diversion, should I use/install ad/tracker blocking or leave that to diversion?

Thanks.

To get the most out of Unbound, disable DoT, DNSSEC, Diversion Adblock (if desired), DNS REBIND and launch the installer script.

 

[dave14305]

I have a quick question that has been talked about but that I don't see a specific answer to: If I do not have stubby installed (as a script) but am using DoT in Merlin, should I integrate stubby in the setup? Also, while I'm asking, since I'm using diversion, should I use/install ad/tracker blocking or leave that to diversion?

Thanks.

At the risk of “trolling” this thread, if you are happy with Diversion plus Pixelserv, and want your outgoing DNS requests to be encrypted, then you have no reason to pursue Unbound, in my opinion. dnsmasq with Stubby will do that well enough. If you want to be your own recursive resolver, then give Unbound a try. Using unbound as another forwarder is a waste of resources on the router (again my opinion).

 

[rgnldo]

Upgrade AsusWRT-Merlin 384.14_2

Device: AC86U & AC68R
Connectivity: PPPoE - IPV4/IPV6
Procedures:

Firefox with clean cache;
FW and JFFS Backup
Factory restore on previous firmware;
Firefox with clean cache;
Upgrade FW 384.14_2:
Firefox with clean cache;
Restore backup .conf and JFFS.

Although I didn't find any errors in the previous version, this release is even better. Unbound behaving very well. 100% functional.

 

[Stevens243]

At the risk of “trolling” this thread, if you are happy with Diversion plus Pixelserv, and want your outgoing DNS requests to be encrypted, then you have no reason to pursue Unbound, in my opinion. dnsmasq with Stubby will do that well enough. If you want to be your own recursive resolver, then give Unbound a try. Using unbound as another forwarder is a waste of resources on the router (again my opinion).

With the answers to my questions, I think that I agree. Thanks for the input.

 

[rgnldo]

dnsmasq with Stubby

Be reasonable, stubby+unbound is optional in the script. For those choosing unbound + stubby, this is documented in the dnsprivacy.org community, as well as other TCP/TLS solutions.

 

[rgnldo]

Although I understand the questions, no one is questioning stubby+dnsmasq as a waste of resources.
My CPU and memory have never worked so little. The only memory-intensive process is Skynet.

This makes it difficult to organize other solutions for this project.

 

[elorimer]

At the risk of “trolling” this thread, if you are happy with Diversion plus Pixelserv, and want your outgoing DNS requests to be encrypted, then you have no reason to pursue Unbound, in my opinion. dnsmasq with Stubby will do that well enough. If you want to be your own recursive resolver, then give Unbound a try. Using unbound as another forwarder is a waste of resources on the router (again my opinion).

Kinda waiting to see if @kvic will surface with his REDIR module for unbound, which sounded like it could be a treat.

I've been following this thread as an exercise in humility.

 

[rgnldo]

REDIR module for unbound

https://kazoo.ga/redir-unbound-dns-adblock

I was following this project. But soon the Unbound development team improved the adblock feature. Currently it is possible to use options like static, refuse etc. You can customize the lockback response. The adblock script that is built into the script-installer is already well customized for memory usage.

 

[rgnldo]

After detecting the dnsmasq initiation interval, Unbound for FreshTomato fully functional. Trying to adapt P2Partisan to Unbound.

#!/bin/sh
# shellcheck disable=SC1083,SC2086,SC2002,SC2009,SC2003,SC2012,SC2004,SC2126,SC2236,SC2059,SC2031,SC2030,SC2039
#
# p2partisan v6.09 (2019/01/26)
#
# Official page - http://www.linksysinfo.org/index.php?posts/235301/
#
# <CONFIGURATION> ###########################################
# Adjust location where the files are kept
P2Partisandir=/opt/P2Partisan
#
# Enable logging? Use only for troubleshooting. 0=off 1=on
syslogs=1
# Maximum number of logs to be recorded in a given 60 min
# Consider set this very low (like 3 or 6) once your are
# happy with the installation. To troubleshoot blocked
# connection close all the secondary traffic e.g. p2p
# and try a connection to the blocked site/port you should
# find a reference in the logs.
maxloghour=1
#
# Ports to be whitelisted. Whitelisted ports will never be
# blocked no matter what the source/destination IP is.
# This is very important if you're running a service like
# e.g. SMTP/HTTP/IMAP/else. Separate value in the list below
# with commas - NOTE: It is suggested to leave the following ports
# always on as a minimum:
# tcp:43,80,443
# udp:53,123,1194:1196
# you might want to append remote admin and VPN ports, and
# anything else you think it's relevant.
# Standard iptables syntax, individual ports divided by "," and ":" to
# define a range e.g. 80,443,2100:2130. Do not whitelist you P2P client!
whiteports_tcp=43,80,443
whiteports_udp=53,123
#
# Greyports are port/s you absolutely want to filter against lists.
# Think of an Internet host that has its P2P client set on port 53 UDP.
# If you have the DNS port is in the whiteports_udp then P2Partisan would
# be completely bypassed. Internet-client:53 -> your-client:"P2Pport""
# greyport is in a nutshell a list of port/s used by your LAN P2Pclient/s.
# It's suggested you disable random port on your P2Pclient and add the
# client port/s here. NOTE:
# Accepted syntax: single port, multiple ports and ranges e.g.
# greyports=22008,6789
# the above would grey list 22008 and 6789. Don't know your client port?
# try ./p2partisan.sh detective
greyports_tcp=
greyports_udp=
#
# Greyline is the limit of connections per given "IP:port" above which
# Detective becomes suspicious. NOTE: This counts 1/2 of the sessions the
# router actually reports on because of the NAT implication. So this number
# represents the session as seen on the LAN client. Affects detective only.
greyline=100
#
# Schedule defines the allowed hours when P2Partisan tutor can update lists
# Use the syntax from 0 to 23. e.g. 1,6 allows updates from 1 to 6 am
scheduleupdates="1,6"
#
# Defines how many lists can be loaded concurrently at any given time. Default 2
maxconcurrentlistload=2
#
# Enable check on script availability to help autorun.
# If the ./partisan.sh is remote wait for the file to be available
# instead of quit with a file missing error
autorun_availability_check=1
#
# IP for testing Internet connectivity
testip=google.com
# </CONFIGURATION> ###########################################

#### Includes

 

[dave14305]

Be reasonable, stubby+unbound is optional in the script. For those choosing unbound + stubby, this is documented in the dnsprivacy.org community, as well as other TCP/TLS solutions.

Unbound + Stubby may be a documented solution when starting from nothing, but why does it make sense for ASUSWRT-Merlin users who already have dnsmasq and stubby built into the firmware? Unbound is merely a forwarder to Stubby, the same as dnsmasq. If you cannot eliminate dnsmasq due to DHCP and LAN hostname resolution, you would now have 3 forwarders on your router. For Unbound to succeed on Merlin, it must offer a unique feature not already available. That feature is recursive resolution.

I would love to see Unbound adopted in the Merlin firmware as the third DNS Privacy option:

1. DNS-over-TLS (i.e. Stubby)
   
2. DNS-over-HTTPS (e.g. NextDNS client)
3. Local recursive resolver (i.e. Unbound)

It's a level of privacy different than the first two, but just as important in this era of data aggregation and mining.

 

[rgnldo]

Unbound + Stubby may be a documented solution when starting from nothing, but why does it make sense for ASUSWRT-Merlin users who already have dnsmasq and stubby built into the firmware? Unbound is merely a forwarder to Stubby, the same as dnsmasq. If you cannot eliminate dnsmasq due to DHCP and LAN hostname resolution, you would now have 3 forwarders on your router. For Unbound to succeed on Merlin, it must offer a unique feature not already available. That feature is recursive resolution.

I would love to see Unbound adopted in the Merlin firmware as the third DNS Privacy option:

1. DNS-over-TLS (i.e. Stubby)
   
2. DNS-over-HTTPS (e.g. NextDNS client)
3. Local recursive resolver (i.e. Unbound)

It's a level of privacy different than the first two, but just as important in this era of data aggregation and mining.

First, it is not the purpose of this post to include stubby in unbound, it is optional. Second, the use of stubby is for the feasibility of the TCP/TLS feature while the unbound development team adds in the next release. The DoT tls-upstream forwarder option is now perfectly viable. https://dnsprivacy.org/wiki/display/DP/Using+Unbound+as+a+DNS+Privacy+server
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients

 

[rgnldo]

@Martineau in the tests here, when the installer chooses to completely remove Unbound, it should also remove the haveged and stubby packages, if installed and the other corresponding folders.

opkg remove haveged stubby --autoremove
rm -R /opt/etc/stubby
rm /opt/etc/init.d/S62stubby

 

[rgnldo]

If anyone is interested in testing, use this script that optimizes /proc tuning adjustments. Improving connectivity. I am getting excellent results. If we get results, we will add it to script-installer as an option.
Download from: https://raw.githubusercontent.com/rgnldo/Unbound-Asuswrt-Merlin/master/stuning

in the path /jffs/scripts

dos2unix /jffs/scripts/stuning 
chmod +x /jffs/scripts/stuning

add on /jffs/scripts/init-start

/jffs/scripts/stuning start

Reboot

 

[SolluxCaptor]

Although I understand the questions, no one is questioning stubby+dnsmasq as a waste of resources.
My CPU and memory have never worked so little. The only memory-intensive process is Skynet.

This makes it difficult to organize other solutions for this project.

Agreed. Same here, never seeing a single core (idle) going above ~1-3% usually at 0%. Running Diversion, PixelSrv-TLS, Skynet, AIProtect IPS, and Unbound (no stubby).

As a side-note, I noticed whenever my memory usage is high, I ran: free -m command. Most memory is just being used as read / write buffer as is standard with linux: https://www.linuxatemyram.com/ (sorry this website puts it so bluntly, lol). Anytime it reaches ~96% the buffer clears, and I am back down to about 63% RAM usage (at most).

 

[rgnldo]

FYI, David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY package for OpenWRT / LEDE assisted me in putting this all together. Dave strongly suggested using DNSMASQ for DHCP and UNBOUND and STUBBY for DNS OVER TLS. Dave's reason was that OpenWrt / Lede performs best when configured in this fashion.

Directly from David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY and I quote:
"I recommend running Unbound to utilize the caching. Sometimes the connections from stubby to the resolver can have a little but of lag, so caching + prefetch helps minimize the effects."

Unbound is a recursive caching DNS Resolver - which by design and definition speeds up your DNS RESOLUTION. DNS addresses are stored in the cache and called upon and directed to almost IMMEDIATELY ! ( Query time: 0 msec ) resolve dns addresses in subsequent DNS look ups after your first visit to cached objects. A small number has questioned DNS OVER TLS and the supposed complexity of this setup vis a’ vis DNSCrypt. DNSCrypt has always been suggested to best deployed when forwarded to Unbound as a Caching Server. In effect, this methodology simply drops Stubby and GetDns in place instead of DNSCrypt. The use of DNSMasq for DHCP is particular to OpenWRT / LEDE. However, it is a fairly simple and straightforward task to setup DNSMasq for purposes of DHCP and well described and referenced in this tutorial. Lastly, GetDns and Stubby do allow for TLS OVER Port 443 and I have amended this guide to reflect that option for those who may worry about being blocked behind a firewall while using TLS OVER Port 853.
https://www.nlnetlabs.nl/projects/unbound/about/

This method combines Unbound (as a caching proxy) and Stubby (as fully featured TLS forwarder). Stubby is essential - please read the following:

Stubby' is an application that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is developed by the getdns project. Stubby is essential - please read the following:
https://dnsprivacy.org/wiki/display/DP/About+Stubby
I run GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP .

https://forums.torguard.net/index.p...nwrtlede-featuring-unbound-getdns-and-stubby/

 

[rgnldo]

Running Diversion, PixelSrv-TLS, Skynet, AIProtect IPS, and Unbound (no stubby)

Would it be possible to test with Skynet and only Unbound and native adblock ?. After, Unbound + Stubby + Native Adblock. Wait.

 

[SolluxCaptor]

FYI, David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY package for OpenWRT / LEDE assisted me in putting this all together. Dave strongly suggested using DNSMASQ for DHCP and UNBOUND and STUBBY for DNS OVER TLS. Dave's reason was that OpenWrt / Lede performs best when configured in this fashion.

Directly from David Mora aka iamperson347 the developer and maintainer of GETDNS and STUBBY and I quote:
"I recommend running Unbound to utilize the caching. Sometimes the connections from stubby to the resolver can have a little but of lag, so caching + prefetch helps minimize the effects."

Unbound is a recursive caching DNS Resolver - which by design and definition speeds up your DNS RESOLUTION. DNS addresses are stored in the cache and called upon and directed to almost IMMEDIATELY ! ( Query time: 0 msec ) resolve dns addresses in subsequent DNS look ups after your first visit to cached objects. A small number has questioned DNS OVER TLS and the supposed complexity of this setup vis a’ vis DNSCrypt. DNSCrypt has always been suggested to best deployed when forwarded to Unbound as a Caching Server. In effect, this methodology simply drops Stubby and GetDns in place instead of DNSCrypt. The use of DNSMasq for DHCP is particular to OpenWRT / LEDE. However, it is a fairly simple and straightforward task to setup DNSMasq for purposes of DHCP and well described and referenced in this tutorial. Lastly, GetDns and Stubby do allow for TLS OVER Port 443 and I have amended this guide to reflect that option for those who may worry about being blocked behind a firewall while using TLS OVER Port 853.
https://www.nlnetlabs.nl/projects/unbound/about/

This method combines Unbound (as a caching proxy) and Stubby (as fully featured TLS forwarder). Stubby is essential - please read the following:

Stubby' is an application that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is developed by the getdns project. Stubby is essential - please read the following:
https://dnsprivacy.org/wiki/display/DP/About+Stubby
I run GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP .

https://forums.torguard.net/index.p...nwrtlede-featuring-unbound-getdns-and-stubby/

This is an awesome in-depth reason to use DoT with Unbound (& stubby). But I must ask, since root nameservers do not support DoT, we still rely on a 3rd party DNS rather than making our very own, yes? Unbound is great that you yourself can become the DNS resolver (not just a cache + forwarder). Caching is awesome, but I personally like my very own DNS server to avoid any widespread DNS poisoning as happened with Cloudflare + others.

 

[rgnldo]

This is an awesome in-depth reason to use DoT with Unbound (& stubby). But I must ask, since root nameservers do not support DoT, we still rely on a 3rd party DNS rather than making our very own. Unbound is great that you yourself can become the DNS resolver (not just a cache + forwarder). Caching is awesome, but I personally like my very own DNS server to avoid any widespread DNS poisoning as happened with Cloudflare + others.

Understand, all servers will forward queries to root servers: Unbound, Cloudflare, Quad etc. Stubby is a complete TCP / TLS transport solution. With unbound this is completed. Just take the test. You can return to the previous easy setting.