https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md - this page is designed for DNS OVER TLS with DNSMASQ but it still is useful and informative .
Stubby dns over tls using dnsmasq-full for dnssec & caching

UPDATED GUIDE FOR Getdns 1.4.2-2 stubby 0.2.3-3 and unbound 1.8.1-2

Why I am so damn serious about DNS Privacy ( just watch these when you have time - all at once or in intervals - very educational ):
https://www.youtube.com/watch?v=JnxE5RPnyiE https://www.youtube.com/watch?v=2JeYIecfwdc

If you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router.
For partitioning USB external flash drives I personally prefer GParted Live and / or MiniTool Partition Wizard 9.1 Boot Iso and both work great - found here: https://gparted.org/download.php and here respectively https://www.chip.de/downloads/Partition-Wizard-Bootable-CD_38297298.html

Active work is also underway at the IETF on DNS-over-HTTP (DOH) but today the only method standardized by the IETF is DNS-over-TLS. In the world of encryption, it's always safer to go with standardized protocols that have gone through a rigorous review process. Unfortunately DNSCrypt has not been standardized yet, and some of the ways it uses cryptography are unusual.

For all of those who are using UNBOUND with tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" # For OpenWrt option: found here Proper Setup For New Native Unbound DNS-Over-TLS Feature Starting With UNBOUND 1.7.1
This will have to wait until OpenSSL 1.1.x. From Unbound Recursive DNS Server with UCI found here: https://github.com/openwrt/packages/blob/master/net/unbound/files/README.md And Look for section at the bottom entitled HOW TO: TLS Over DNS read this:
NOTICE: Unbound requires openssl-1.1.0 to verify host certificates. OpenWrt at present is configured with openssl-1.0.2. Connections will be over TLS, but theoretically, certificates may not be from a trusted source. See report https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658. When this is resolved, it will be recommended again to install ca-bundle, maintain it, and be sure to include the TLS certificate domain index with the host addresses.

For all the doubters and naysayers concerning GETDNS and STUBBY - they are developed by NLnet Labs - the same folks who bring us Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ) see here: https://www.nlnetlabs.nl/ https://www.nlnetlabs.nl/projects/getdns/

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."
This is why I put this all together using Unbound DNS Caching Server. Use Localhost along with Tenta nameservers and for your OpenWrt Router. Tenta DNS is a full-fledged DNS solution, including DNSSEC and DNS-over-TLS. These are the folks that developed and support the Tenta Browser see here: https://github.com/tenta-browser/tenta-dns and read About Tenta section at the very bottom of the page.

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 have 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.

What I give you here is the absolute best method of implementation and deployment of DNS OVER TLS. For any and all who may be wondering why DNS OVER TLS is all the rage - read this:
https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt So here we go.
Yes I run GETDNS and STUBBY. For those who wish to explore GETDNS and STUBBY - this method is the one recommended by DNSPRIVACY - see here :

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#DNSPrivacyClients-Unbound - please read this carefully - you will note that it indicates :

Unbound As A DNS TLS Client Features:
Unbound can be run as a local caching forwarder, configured to use SSL upstream, however it cannot yet authenticate upstreams, re-use TCP/TLS connections, be configured for Opportunistic mode or send several of the privacy related options (padding, ECS privacy) etc. Some users combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as a fully featured TLS forwarder).

I have read here: https://www.monperrus.net/martin/randomization-encryption-dns-requests that Also, it is good to set up some servers that listens on port 443 and others on port 853, so as to be resilient if you are on a network with blocked ports. You can also blend IPv4 and IPv6 addresses.
These are the reasons I choose to use GETDNS and STUBBY with Unbound. Those reasons being so that I can take full advantage of all of the most secure privacy features available when running DNS OVER TLS.

This method combines Unbound (as a caching proxy) and Stubby (as fully featured TLS forwarder).
I run GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. Read here:
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:
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 . Here is a basic guide as to how to do it -


However a few modifications are necessary in order to to have GetDns and Stubby up and running and successfully integrated with Unbound DNS and Dnsmasq for DHCP. I will write up a guide here - but don’t give me a hard time later on. Directly From DNS Privacy Website: Stubby is an experimental implementation of a DNS Privacy enabled stub resolver. It is currently suitable for advanced/technical users - all feedback is welcome! Also see dnsprivacy.org for more information on DNS Privacy.
By the way I run Davidc502 LEDE Snapshots - Moderately Customized LEDE Development Builds for Linksys 1900ac v.1 and 1900ac v.2, 1900acs v.1 v.2, 3200acm, WRT32X and 1200ac v.1 v.2 series routers. These builds keep up to date package repositories.. GetDns and Stubby are included. Dave's Builds have many other pre-installed common packages as well.. Check out homepage and downloads here: https://davidc502sis.dynamic-dns.net/ and downloads here: https://davidc502sis.dynamic-dns.net/snapshots/ .In addition, there is a very informative, instructive and active thread ( forum ) for Dave's builds and discussion of many OpenWrt / Lede packages, features, and issues. In short great technical advice and assistance can be found here: Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds Dave releases new updated builds every two weeks - near the middle and first of each month. - Latest Stable Version of OpenWrt / Lede 18.06.1 includes up to date Unbound, GETDNS and STUBBY: ( download and do fresh install of squashfs-factory.img on your device for best performance ) https://downloads.openwrt.org/releases/18.06.1/targets/ as do OpenWrt/LEDE Development Snapshots here: https://downloads.openwrt.org/snapshots/targets/

You can add these packages by adding package url repository URL under your " Custom Feeds " if for any reason you need to do so. Custom feed needs to match must match your router's architecture.This feed : src/gz OpenWrt_packages https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9_vfpv3/packages/ for WRT1900ACS - You can find router's architecture here: https://openwrt.org/toh/start and then look on Device Page and / or Device Techdata.
Remember to remove custom feed url after installing your GETDNS and SUBBY packages in order to avoid software package conflicts.

As always - opkg update
first and foremost

You have a ca cert bundle installed on your router.
You can do this by running the following

opkg install ca-certificates

Now Let’s Move On

1 - opkg install unbound odhcpd unbound-control unbound-control-setup luci-app-unbound unbound-anchor
2 - opkg install getdns stubby

3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf
( Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's )
You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on-
see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/

( Simply Copy and Paste Into Your SSH Session and Hit Enter )
cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF
# use all CPUs
num-threads: 2

# power of 2 close to num-threads
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4

# more cache memory, rrset=msg*2
rrset-cache-size: 256m
msg-cache-size: 128m

# more outgoing connections # make sure to install libevent
outgoing-range: 8192

# Larger socket buffer. OS may need config.
so-rcvbuf: 4m
so-sndbuf: 4m

cache-min-ttl: 600
cache-max-ttl: 14400
qname-minimisation: yes
qname-minimisation-strict: yes
hide-trustanchor: yes
infra-cache-numhosts: 100000
num-queries-per-thread: 4096
minimal-responses: yes
rrset-roundrobin: yes
do-tcp: yes
do-ip6: no
prefetch: yes
prefetch-key: yes
so-reuseport: yes
unwanted-reply-threshold: 10000000
interface-automatic: yes
max-udp-size: 2048
num-queries-per-thread: 4096
do-not-query-localhost: no
verbosity: 1
private-domain: "yourdomain.here"
harden-referral-path: yes

As per guide :# Don’t let each server know the next recursion
Enter via SSH command line:
uci set ‘unbound.@unbound[0].query_minimize=1’

4 - My WORKING CONFIG /etc/stubby/stubby.yml
I prefer to run these DNS TLS SERVERS as they tend to be stable most all of the time. The mix of dns.cmrg.net, DNSPRIVACY.at and getdnsapi.net Servers work in an optimal fashion on OpnSense. However, if for any reason you lose internet while running Stubby- chances are it is due to one or more of the servers you are running being down. I told you and it is mentioned on DNSPRIVACY website that all of this ( for the time being ) is experimental. However, even if you run ssl-upstream with Unbound you still will need to monitor real time status of DNS Privacy Test Servers. So, Stubby is still the full featured way to go. See all DNS TLS SERVERS here if you choose to run others:
Read here if problems reading due to edit format issues:
Here is a list of all DNS Privacy Servers in the raw. Add ( tls_port: 853 ) after ( - address_data: ) entry:
( follow sample file for proper configuration of Stubby yml )
You can and should also check real time status of DNS Privacy Servers as they are experimental and are not always stable - you can monitor DNS TLS Servers Real Time Status here below:
nano /etc/stubby/stubby.yml - replace contents of file with configuration below:
Proper Configuration Examples For Non- Readable Options:


See here for how to configure Stubby: https://github.com/getdnsapi/stubby





tls_query_padding_blocksize: 128

edns_client_subnet_private : 1

idle_timeout: 60000 # keep-alive for 1 min, for better performance



round_robin_upstreams: 1


  • address_data:
    tls_port: 853
    tls_auth_name: "getdnsapi.net"
    • digest: "sha256"
      value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
  • address_data:
    tls_auth_name: "kaitain.restena.lu"
    tls_port: 853
    • digest: "sha256"
      value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
  • address_data:
    tls_port: 853
    tls_auth_name: "dnsovertls2.sinodun.com"
    • digest: "sha256"
      value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
  • address_data:
    tls_auth_name: "dot.securedns.eu"
    tls_port: 443
    • digest: "sha256"
      value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
  • address_data:
    tls_port: 443
    tls_auth_name: "dns.cmrg.net"
    • digest: "sha256"
      value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
  • address_data:
    tls_port: 853
    tls_auth_name: "ns1.dnsprivacy.at"
    • digest: "sha256"
      value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
  • address_data:
    tls_port: 853
    tls_auth_name: "ns2.dnsprivacy.at"
    • digest: "sha256"
      value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=
  • address_data:
    tls_port: 443
    tls_auth_name: "dns.neutopia.org"
    • digest: "sha256"
      value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
  • address_data:
    tls_auth_name: "iana.tenta.io"
    tls_port: 853
    • digest: "sha256"
      value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=

All of these name servers listed above DO NOT log ! repeat DO NOT log ! your DNS queries. In full disclosure some name servers claim to log traffic volume only.See here for details : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under " Logging " column.

DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy -
Run Test After Completing Full Setup
These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. )
Use either of these two methods to verify QNAME Minimisation
A - You need to opkg install drill and - then run command : drill txt qnamemintest.internet.nl
and / or
B - opkg install bind-dig or opkg install bind-tools with command: dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl ( for more complete readout including DNSSEC results ).
AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)
The results in any of these scenarios will show either:
"HOORAY - QNAME minimisation is enabled on your resolver :)!”
or “NO - QNAME minimisation is NOT enabled on your resolver :(.”
Reference https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4
You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration.

Note: Starting with Unbound 1.7.2 qname minimisation is enabled by default.
However, I still add these settings manually.
These settings are entered in " /etc/unbound/unbound_srv.conf " file.
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes
See configuration above in Step # 3 .

5 - MY WORKING CONFIG /etc/unbound/unbound_ext.conf

( Simply Copy and Paste Into Your SSH Session and Hit Enter )

cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF
name: "." # Allow all DNS queries
forward-addr: # Forward Unbound To Stubby Address/Port

6 - From The Guide referred to in the link above - self explanatory: # Move dnsmasq to port 53535 where it will still serve local DNS from DHCP# Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535
Enter via SSH command line:
uci set ‘dhcp.@dnsmasq[0].port=53535’

uci add_list “dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)”
uci set ‘unbound.@unbound[0].dhcp_link=dnsmasq’

uci commit

/etc/init.d/unbound restart

7 - From https://github.com/openwrt/packages/tree/master/net/unbound/files HOW TO Integrate with DHCP

Parallel DNSMASQ /etc/config/dhcp
After Some Reflection and Observations - Fine Tuning Your DNS Resolver
After reading System Logs I realized that there is a need to amend DNSMASQ ( DHCP ) after implementing option noresolv ‘1’ in /etc/config/dhcp configuration file. This dawned on me from my years of running DNSCRYPT Proxy on OpenWrt. I referred to this guide:

Go to this section near bottom of page.
Use specific DNS server to lookup one or more host names


option noresolv ‘1’ is to prevent using any upstream DNS server other than those specified in this file # this file being: /etc/config/dhcp

Solution is as follows add these two lines to /etc/config/dhcp:

nano /etc/config/dhcp - enter these lines before / option domain ‘yourdomain’

list server '' # Stubby/Unbound Default Address/Port
option noresolv '1' ## Make sure to change this as indicated

After you complete all the steps in this tutorial and restart your Router Check Status > System Log - You will find an entry like the one below:
daemon.info dnsmasq[8532]: using nameserver - which indicates that your OpenWrt Router is using Unbound and Stubby for Encrypted DNS Resolution

I now only run ( Localhost ) configured as the only DNS SERVER on my WAN interface. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.

8 - Optionally, better DNS resolution follow the /etc/config/unbound file in this tutorial below ( where Lan and Wan are Unbound Triggers ) then add DNS resolvers as follows: A - Under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Servers in order, along with Tenta nameservers and - Your DNS will still resolve using the upstream name servers you selected in stubby.yml - Things Will Work Fine and as Intended. I have found that it is best to use Tenta DNS name servers as " custom DNS servers " on the Wan interface. I chose Tenta DNS because their name servers support both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. Tenta DNS also is the only AnyCast DOT service which includes built-in BGP integration, offering single engine convenience for DNS Anycasting with QNAME minimisation enabled on its' name servers by default. Main benefits of Tenta DNS as the backbone name servers on OpenWrt:

A - Stop ISPs from spying on your browser history. DNS-over-TLS adds a layer of encryption over your DNS requests, keeping your ISP from seeing which websites you visit.

B - Stay private online. Tenta DNS logs a counter instead of queries so your data stays private. No one, not even Tenta, has access to your browsing data.

9 - Working /etc/config/unbound file

nano /etc/config/unbound

config unbound
option dns64 '0'
option edns_size '4096'
option extended_luci '1'
option extended_stats '0'
option hide_binddata '1'
option domain 'yourdomain.here'
option domain_type 'static'
option enabled '1'
option listen_port '53'
option localservice '1'
option luci_expanded '1'
option manual_conf '0'
option query_min_strict '1'
option rebind_localhost '0'
option rebind_protection '1'
option recursion 'passive'
option resource 'small'
option root_age '9'
option ttl_min '120'
option unbound_control '2'
option validator '1'
option validator_ntp '1'
option query_minimize '1'
option dhcp_link 'dnsmasq'
option enabled '1'
option protocol 'ip4_only'
option prefetch_root '0'
list trigger_interface 'lan'
list trigger_interface 'wan'

Now run /etc/init.d/unbound restart one more time. When you do this you will see that your unbound root.key will be installed to /var/lib/unbound/root.key and also it will install root.key to /etc/unbound/root.key. This will automatically configure DNSSEC on your router. The function also lists your auto-trust anchor in your /var/lib/unbound/unbound.conf file.

You will now be running DNS OVER TLS with GETDNS and Stubby on LEDE / OpenWrt

Make sure to follow this guide precisely and it works GREAT!!!

Peace and God Bless - My Pleasure For You and The Entire Community -
You can install - opkg install bind-dig or opkg install bind-tools order to be able to issue dig commands in order to check DNS resolution if you opt to - as you test you will see that your cache is working also.
Bonus Setup Option ( Highly Recommended ) - Install WatchCat
http://www.ibuyopenwrt.com/index.php/2-uncategorised/224-watchcat-reboot-on-internet-drop I set "Reboot on Internet Connection Lost" option. I have WatchCat set to ping Fourth Estate DNS address - - every 20 minutes. This will keep your router up and running consistently.

Now all you need to do is run is a properly configured VPN Service. By doing so, running DNS over TLS with Stubby and GetDns will keep your VPN provider from spying on your encrypted DNS look ups - and also your DNS providers both the ISP ( replaced by encrypted Stubby ) and your Encrypted TLS DNS Service Provider will see your IP as the one from your encrypted tunneled VPN provider.
I am convinced this setup is the right strategy for both security and privacy. I think it to be the best practice for all those most serious about multi-layered cyber security.
Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of such service. Your results will render the DNS PRIVACY Name Servers which you selected in your stubby.yml configuration file. You are now running DNS OVER TLS with GETDNS plus STUBBY ( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares:
DoT servers
The following servers are experimental DNS-over-TLS servers.
Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified**.Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!**
For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There is are sure fire methods to make sure that you are using the correct value for any upstream nameserver ( aka tls_pubkey_pinset value ) - Go to https://blahdns.com/ and scroll down to the section to the yellow section entitled What is DNS OVER TLS click on it and it will open up.
When you do it will state some general information, but what you want to pay attention to is this section:
How to get SPKI
gnutls-cli --print-cert -p 853 - where you must opkg install gnutls-utils
echo | openssl s_client -connect '' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

There is also a third option. kdig -d @ +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig
This is my personal favorite as the readout from this command will list the certificate specifically like so:
;; DEBUG: #1, CN=getdnsapi.net
;; DEBUG: SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted.
Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable.
To use kdig certificate verification method on an alternate port example: kdig -d @ -p 443 +tls-ca +tls-host=dns.cmrg.net example.com

https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest
https://www.grc.com/dns/dns.htm http://www.vpninsights.com/dns-leak-test and last but not least

https://cmdns.dev.dns-oarc.net/ for a thorough in depth DNS Test https://bash.ws/dnsleak/test/

See the guide here for OpenVpn Setup With TorGuard VPN on OpenWrt / Lede :

or here for PIA OPENVPN:

And now you are cooking with plenty of Gas - c'est fini c'est manifique c'est ci bon

Proper Setup For New Native Unbound DNS-Over-TLS Feature Starting With UNBOUND 1.7.1
UPDATED GUIDE FOR Getdns 1.4.2-2 stubby 0.2.3-3 and unbound 1.8.1-2
Unbound is not forwarding to TLS DNS servers
Stubby dns over tls using dnsmasq-full for dnssec & caching
Implementing DNS-Over-TLS for novices - Which guide to follow?
Dns over tls absolute best configuration for stubby ipv4 and/or ipv6
Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds
Stubby dns over tls using dnsmasq-full for dnssec & caching
Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds
PIA OPENVPN on OpenWrt / Lede

Run Openwrt on Tplink wdr4300, old router so can you advise?


Dera Itachi,
Have a look here :slight_smile:
DrKK's recommend unbound.conf file for small installations:

  verbosity: 1
  statistics-interval: 3600
  statistics-cumulative: yes
#  outgoing-range: 800
  outgoing-range: 256
  num-threads: 1
  msg-cache-size: 1m
  msg-cache-slabs: 1
  num-queries-per-thread: 128
  rrset-cache-size: 2m
  rrset-cache-slabs: 1
  infra-cache-numhosts: 16
  infra-cache-slabs: 1


Thank you @directnupe.

I set everything up and it looks like its working because I can still browse ;D

One question:

When I check for dnsleak at https://www.dnsleaktest.com/,

I see my IP address as DNS.

Is that how it is supposed to work?

Can you try https://www.dnsleaktest.com/ and see?



If you mean your IP ADDRESS is displayed next to a BIG HELLO at the top of the page then
yes that it normal -

you have to click on Standard / And Or Extended Test situated directly beneath the picture Map

I find Grc Spoofability to be the best - either one of these -


https://www.grc.com/dns/customtest.htm There are two of them

read my friend - read the instructions - you can just type

dnsleak in google and try several results - you will get plenty

I told you in the tutorial that your servers should be:

Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of such service. You will see that your DNS results render WoodyNet ( Quad 9 ) and Cloudflare respectively if you followed this guide step by meticulous step.


Thanks again :slight_smile:

The problem was I copy and paste into putty from here and somehow
name: “.” turned into name ........

Rechecked everything and edited that and it works now.

Good tutorial :]


Can someone please explain to me this mess of a mess. Why use GetDns+Stubby+Unbound+Dnsmasq. This looks like a huge performance mess to me. Shouldnt unbound replace dnsmasq? Whats the meaning to use GetDns together with Stubby? Cant you just use stubby+dnsmasq? Why would this be better than dnsmasq+dnscrypt-proxy1.9 which is like 5 lines to configure? dnscrypt-proxy2 is mostly bad for Lede because of this nonsense script Go and it's size. But I wanted to try out cloudfare server and it doesnt work with dnscrypt-proxy1.9 it seems.



Is this important though?

"tls_pubkey_pinset" (Padding)

Wouldn't having that hide it from ISP and VPN too?

#Cloudflare DNS over TLS server

  • address_data:
    tls_auth_name: "cloudflare-dns.com"
    • digest: "sha256"
      value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
  • address_data:
    tls_auth_name: "cloudflare-dns.com"
    • digest: "sha256"
      value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

More: https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns/2/


Read here - you could stand to learn how to do some basic research and independent investigatory work


specifically these assertions from Cloudflare and Quad 9 THEMSELVES "

DNS-over-TLS (DOT)

Quad9 'secure' and Quad9 'insecure'

Quad9 do NOT publish or recommend use of SPKI pins with their servers.

and - same as Quad 9 for Cloudflare

Cloudflare do NOT publish or recommend use of SPKI pins with their servers.

so there you have it from the sources - The answer is " NO"

Read this for Quad 9 -

See https://quad9.net and their FAQ for details of privacy, logging and filtering policies on the main and alternative addresses(1).
UDP and TCP service are also available on these addresses.

and this for Cloudflare -

PRIVACY POLICY: https://developers.cloudflare.com/

And also see https://labs.apnic.net/?p=1127 for details of the APNIC/Cloudflare agreement as mentioned on the Register.

UDP and TCP service are also available on these addresses. DNS-over-HTTPS is also available!

NOTE: To use this service by name only (i.e resolve the IP from the name) use 1dot1dot1dot1.cloudflare-dns.com.

and looking to the future read mid page here :slight_smile:


The next release of Stubby (v0.3, getdns v1.5) is expected to support the following:
Configuration of servers using authentication name only

so DNSPRIVACY ( Developer of Stubby and GetDNS ) plans to get rid of padding pin in next release and use name only - so it must be secure at least in their view



Implementing "DNS Proxy" in Openwrt
Implementing DNS-Over-TLS for novices - Which guide to follow?


Thank you Max again :]

I have some more doubts so I can verify


These are the logs:

Unbound Statistics:


System log:

Wed May 16 05:39:10 2018 user.notice unbound: iterator will use built-in root hints
Wed May 16 05:39:16 2018 user.notice unbound: iterator will use built-in root hints
Wed May 16 05:39:17 2018 daemon.notice unbound: [1599:0] notice: init module 0: validator
Wed May 16 05:39:17 2018 daemon.notice unbound: [1599:0] notice: init module 1: iterator
Wed May 16 05:39:45 2018 daemon.info procd: Instance unbound::instance1 pid 1599 not stopped on SIGTERM, sending SIGKILL instead
Wed May 16 05:39:47 2018 daemon.notice unbound: [1912:0] notice: init module 0: validator
Wed May 16 05:39:47 2018 daemon.notice unbound: [1912:0] notice: init module 1: iterator
Wed May 16 05:39:52 2018 daemon.info unbound: [1912:0] info: start of service (unbound 1.7.1).
Wed May 16 05:39:54 2018 daemon.info unbound: [1912:0] info: generate keytag query _ta-4a5c-4f66. NULL IN

Is it working well?

2] When you advise in point 7 the following

nano /etc/config/dhcp

config dnsmasq
option domain ‘yourdomain’
option noresolv ‘1’ ## Make sure to change this as indicated
option resolvfile ‘/tmp/resolv.conf.auto’
option port ‘53535’

Does this mean I only have the above entries in config dnsmasq and remove all the extra below?

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'yourdomain'
        option noresolv '1'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option port '53535

3] How to edit this in /etc/config/dhcp

list server '' # Stubby/Unbound Default Address/Port
    list server '/pool.ntp.org/' ## DNS WATCH SECURE
    option noresolv '1'
    option allservers '1'

Does it look like

config dnsmasq
list server ''
list server '/pool.ntp.org/'
option allservers '1'
option domain ‘yourdomain’
option noresolv ‘1’ ## Make sure to change this as indicated
option resolvfile ‘/tmp/resolv.conf.auto’
option port ‘53535’

Thank you so much again ;]


First - Is it working well? Your Unbound Files look fine to me and if followed all the steps the guide I wrote the go to System > Recursive DNS > Status > Log - you can read on a more granular level what Unbound is doing
including cache hits

Second - yes you have /etc/config/dhcp set up correctly under - Does it look like ?
Lastly, do not change anything ( remove or add ) unless it was indicted in the tutorial
you only need to add four lines - DO NOT REMOVE ANYTHING - PERIOD EVER !
these four lines:


    list server ''
    list server '/pool.ntp.org/'
    option noresolv '1'
    option allservers '1'


Thank you :]


Thanks for your tutorial @directnupe !

It's working here but I'm getting a lot of Conn closed: TLS - Failure, is this normal?
Local DNS benchmark is not that good too.



One curious question:

By default, the setting on my router is

option domain ‘lan’

should I change it to

option domain ‘yourdomain’

'yourdomain' everywhere.


What's the performance penalty of unbound vs dnsmasq vs actual DNS forwarders?


Response time is dominated by Internet transit time and TLS setup time, not the software itself, at the scales (query rates) that most home users experience.


I dived in and replaced unbound with dnsmasq. Answering my own question:

  • dnsmasq or using public DNS directly (google, cloudflare) were all less than 100ms (20~80ms).
  • unbound's cold recursive lookup is anywhere between 400~900ms.
  • unbound's cold DNS over TLS lookup is 200~8000ms.


Just use stubby.




I also switched over to stubby.

Replacing dnsmasq completely by unbound is not that easy as i thought.
odhcpd doesn't work if the kernel has no ipv6 support.
So i have to use dnsmasq for dhcp.
If you want to link your dhcp to unbound you have to keep the dns part of dnsmasq enabled.
(so dont use port 0)
Also the dns resolution fails on the router if unbound is the main dns server.
I dunno why.

One advantage of unbound is it does query the root servers directly and then goes from there.
So you don't share dns query data with companies like google, opendns, cloudflare and so on.
But the dns traffic can still be analyzed, since there is no encryption.

I think best would be to get some cheap vps in a different country.
And host a dns server on your own.

Is it true cloudflare does share its data with the chinese apnic?


Are there reason for avoiding IPv6 because the Internet is moving towards that direction?

Do you have more information about this or was it about the recent BGP issue with