Jump to content
Sign in to follow this  


Rate this topic

Recommended Posts




I have written tutorials where DNS OVER TLS setup is focused on deploying UNBOUND STUBBY and GETDNS along with DNSMASQ for DHCP on OPENWRT/LEDE. Thanks to my good friend Specimen ( see his tutorial / guide here : https://forum.openwrt.org/t/tutorial-dns-over-tls-with-dnsmasq-and-stubby-no-need-for-unbound/18663 - I was able to realize that we can eliminate UNBOUND all together for those who wish to do so for any number of reasons. For those of you who that may have limited memory or storage available on your router and 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 -Specimen's tutorial features a method to install STUBBY and GETDNS to RAM very smartly and efficiently as well - that will not be covered here as I have found that DNSMASQ-FULL is a better solution in my opinion.

So - let's get started with no further ado:
2 -
A - opkg update
B - opkg install ca-certificates
C - opkg install stubby ( GETDNS and LIBYAML will be installed as dependencies )

3 - This guide aforementioned at the top of this page: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md is the one I followed. However, the only issue is that the guide gives one several options as to how to deploy STUBBY and GETDNS with DNSMSQ and / or DNSMSQ-FULL. With the availability of options just may come confusion and mistakes. So, the purpose of this tutorial is to demonstrate how to eliminate potential errors during setup of  STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING as the title asserts.

4 - I chose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration.

5 - To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows:

6 - The next step is to configure /etc/stubby/stubby.yml file in the standard fashion. Note that DNSSEC is not configured in STUBBY as DNSMASQ-FULL
will be configured to implement this feature later on in this process. Here is my /etc/stubby/stubby.yml file nano /etc/stubby/stubby.yml :

After checking, rechecking and the triple checking on this website mentioned above : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 I have made some very serious discoveries regarding which DNS Privacy Test Servers to use. The bottom line that I strongly suggest you only choose to deploy servers which support the TLSv1.3 protocol.See here for information and importance of TLSv1.3 : https://kinsta.com/blog/tls-1-3/ 1
I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is:

## Tested On https://cmdns.dev.dns-oarc.net/ August 4 2019 A+ 100% Rating - Perfecto Configuration

# Note: by default on OpenWRT stubby configuration is handled via
# the UCI system and the file /etc/config/stubby. If you want to
# use this file to configure stubby, then set "option manual '1'"
# in /etc/config/stubby.
round_robin_upstreams: 1
appdata_dir: "/var/lib/stubby"
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 60000
  - [email protected]
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
tls_ca_path: "/etc/ssl/certs/"

# IPV4 Servers
### DNS Privacy Test Servers ###
#The DNS Warden DNS TLS Primary Server   uncensored-dot.dnswarden.com   A+
  - address_data:
    tls_auth_name: "uncensored-dot.dnswarden.com"
    tls_port: 443
      - digest: "sha256"
        value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
#The DNS Warden DNS TLS Secondary Server  adblock-dot.dnswarden.com    A+
  - address_data:
    tls_auth_name: "uncensored-dot.dnswarden.com"
    tls_port: 443
      - digest: "sha256"
        value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
### Test servers ###
#The BlahDNS German DNS TLS Server    A+
  - address_data:
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
      - digest: "sha256"
        value: sYrnkH4aRY6M9eP1Uut38GNTXK0xg7wD+Euy/xdW9xc=
#The BlahDNS Japan DNS TLS Server    A+
  - address_data:
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
      - digest: "sha256"
        value: 427fIEGdHRXL9C6i+PzEk+CstsrmNGXJaAnu9ECu+Hk=
## The Surfnet/Sinodun DNS TLS Server    A+
  - address_data:
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
# The securedns.eu DNS TLS Server  dot.securedns.eu   ads-dot.securedns.eu  A+
  - address_data:
    tls_auth_name: "dot.securedns.eu"
    tls_port: 853
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
#The dns.seby.io - Vultr DNS TLS Server     A+
  - address_data:
    tls_auth_name: "dot.seby.io"
    tls_port: 853
      - digest: "sha256"
        value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw=
#The Primary appliedprivacy.net DNS TLS Server      A+
  - address_data:
    tls_auth_name: "dot1.appliedprivacy.net"
    tls_port: 443
      - digest: "sha256"
        value: MXKR+t7INx/SPe6RgmkIzRA2FvX+EDqTzTbhZcSBjas=
#The Secure DNS Project by PumpleX DNS TLS Server     A+
  - address_data:
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
      - digest: "sha256"
        value: yevnTQfRqEOU1W8rUBABZRgToMgAwRn0eH7zJeBcq0s=
#The ibksturm DNS TLS Server      A+
  - address_data:
    tls_auth_name: "ibksturm.synology.me"
    tls_port: 853
      - digest: "sha256"
        value: TjpalBJr0Ir27Dr59lXky4PXN0yTAoW92ddF8lBxYBQ=
#The dot.tiar.app DNS TLS Server     A+
  - address_data:
    tls_auth_name: "dot.tiar.app"
    tls_port: 853
      - digest: "sha256"
        value: s5xofhW7O9egEANpOxvH7vRYndoDZOvNeq4i/91uopE=
#The dns-nyc.aaflalo.me DNS TLS Server             A+
  - address_data:
    tls_auth_name: "dns-nyc.aaflalo.me"
    tls_port: 853
      - digest: "sha256"
        value: KqzeDRgYePfKuZrKttwXM8I2Ej4kD6Sayh0kp4NWaJw=
#The dns.aaflalo.me DNS TLS Server             A+
  - address_data:
    tls_auth_name: "dns.aaflalo.me"
    tls_port: 853
      - digest: "sha256"
        value: 50wqzG07SGqYwAO3NfzyrVq99wJZbhCWk0pu5VTc9n8=

# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_min_version: GETDNS_TLS1_2
## For Version OpenSSL 1.1.1  TLSv1.3 and above
# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_max_version: GETDNS_TLS1_3
# Set the acceptable ciphers for DNS over TLS.  With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
#tls_ciphersuites option. This option can also be given per upstream.
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"


7 - Integration of STUBBY with DNSMASQ
A - Set DNSMASQ to send DNS requests to STUBBY - this is done to allow Localhost ( ) on port 5453 to be the sole resolver used by your router. This forces router to use DNS OVER TLS as STUBBY listens on the default address / port .
There are two methods to do this:

uci add_list [email protected][-1].server=''
uci set [email protected][-1].noresolv=1
uci commit

Or  edit the /etc/config/dhcp file

nano /etc/config/dhcp
        list server '[email protected]'
        option noresolv '1'

8 - Disable Sending DNS Requests to ISP Provided DNS Servers

uci set network.wan.peerdns='0'
uci set network.wan.dns=''

uci set network.wan6.peerdns='0'  # If you use STUBBY for IPV6
uci set network.wan6.dns='0::1'       # If you use STUBBY for IPV6
uci commit


In the Luci Web interface under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server  -

9 - Now restart DNSMASQ and enable, start and restart STUBBY just to make sure everything is up and running before you proceed. Run the following commands:

/etc/init.d/dnsmasq restart
/etc/init.d/stubby enable
/etc/init.d/stubby start
/etc/init.d/stubby restart

10 - Enabling DNSSEC - We are going to use DNSMASQ-FULL in order to enable this feature. This one command removes DNSMASQ and installs DNSMASQ-FULL. In order to achieve this end, enter this as one command:

A - opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk

11 - We are now going to configure STUBBY not to perform DNSSEC validation and configure DNSMASQ-FULL to require DNSSEC validation. We do so by entering the following commands via UCI:

uci set [email protected][-1].dnssec=1
uci set [email protected][-1].dnsseccheckunsigned=1
uci commit

Or  edit the /etc/config/dhcp file

nano /etc/config/dhcp
        option dnssec '1'
        option dnsseccheckunsigned '1'

To verify DNSSEC trust-anchors, this is how to do it ( 1 ) trust-anchors are here: TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf"
so in SSH shell issue command : cat /usr/share/dnsmasq/trust-anchors.conf  - and Voila' - Whoop There It Is !

12 - Now I am used to running UNBOUND so I accustomed its' caching feature. To increase DNSMASQ-FULL cache use one of these two methods:

A - Via UCI (Unified Configuration Interface) - in shell
uci set [email protected][0].cachesize=1000
uci commit dhcp

Or  edit the /etc/config/dhcp file

nano /etc/config/dhcp
        option cachesize '1000'

Now restart DNSMASQ and restart STUBBY once again:
/etc/init.d/dnsmasq restart
/etc/init.d/stubby restart

13 - I have found that for whatever reasons it is best to make these entries in startup in order for STUBBY and DNSMASQ-FULL to fire up after a reboot. On boot, in case GETDNS and STUBBY fails to start. This is very likely due to Internet connection not available yet at time of starting DNSMASQ-FULL GETDNS and STUBBY. In such a case, the workaround is to wait for Internet connection to be available before restarting DNSMASQ-FULL GETDNS and STUBBY. The solution is to add the following lines into /etc/rc.local:
You may also enter these additions via Luci menu  Startup > Local Startup
nano /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# Wait until Internet connection is available
for i in {1..60}; do ping -c1 -W1 &> /dev/null && break; done
# Restart DNS Privacy Daemon - Stubby as it requires a successful
#time sync for its encryption to work/
/etc/init.d/dnsmasq restart
/etc/init.d/stubby restart
/etc/init.d/openvpn restart #If you run VPN as you should

exit 0

Reboot your router just to make sure everything is running as designed.

14 - Two quick command line tests for you to conduct after rebooting your router:  

A - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy. The name servers listed I use help to consistently ensure QNAME Minimisation functions as designed. The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. You need to opkg install bind-tools or opkg install bind-dig
command : dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl
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.

B - DNSSEC TEST -  command : dig dnssectest.sidn.nl +dnssec +multi @
Look at the flags section. You should see : ;; flags: qr rd ra ad; As long as you get ad flag as you should, you now have verified DNSSEC as well.

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


Peace Unto All,


Parting Thoughts:
I really like this deployment and implementation of DNS OVER TLS. It seems to be very snappy in resolving DNS queries - even a bit more responsive than UNBOUND. It is pretty simple and straight forward to set up and the documentation is very easily understood. Moreover, DNSMASQ is the native resolver for OpenWRT, so this set up minimizes any other components which may bog down your router. In essence, this setup is most clean and elegant in my estimation. Also, DNSMASQ-FULL allows you a more robust resolver than the native install standard DNSMASQ version. DNSMASQ-FULL allows for DNSSEC and QNAME Minimisation. I am using this setup now and I will report back later on; however, for now it is working beautifully.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this