Stubby dns over tls using dnsmasq-full for dnssec & caching

Installing and Using OpenWrt Network and Wireless Configuration
1 
This Tutorial / Guide Was Updated on Jan 19 2020
in order to keep you in step with changes on packages needed
for OpenWrt 19.07.0

For those who want to obtain full new updated upstream DOT Server List and Keys August 21 2020
see here below :
https://forums.torguard.net/index.php?/topic/1861-openwrt-new-and-improved-getdns-stubby-and-unbound-aka-dns-privacy/

See here for GETDNS AND STUBBY on OPENWRT / LEDE:
https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md

" The Intro " we would all have a better world if we remember to practice the concept that - NOW ! is the time for all of US ( A ) to GET UP & GET INVLOVED and act with SOUL POWER ! - lyrics to sing along : https://genius.com/James-brown-get-up-get-into-it-get-involved-lyrics plus https://genius.com/James-brown-soul-power-lyrics and video : https://www.youtube.com/watch?v=1pvIarW3xHg Bonus JB : https://www.youtube.com/watch?v=v8TvBPshngE

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

I was asked by a still skeptical devotee of DOH
" What makes this way better than just running the DNS-over-https-proxy ?
My answer was : Read this and make your
decisions and conclusions concerning DOH vs DOT .
Here is the article below :

Conclusion From Jan Schaumann - The Author of This Blog Entry :
For that, my current preference is quite clearly DNS-over-TLS:
I fear a bifurcation of DNS resolution by apps combined with the
push for using public resolvers with DoH will lead to a more complex
environment and threat model for many users.

Short Synopsis of DOH:
In other words , ( with DOH ) we gain the same
protections as with DoT for our web applications,
but leaves all other DNS traffic vulnerable.

Subsequently, as a matter of fact and in practice
with DNS OVER TLS ALL DNS traffic is invulnerable
and protected.This is why I run DOT and
eschew DOH on my OPNsense Router.

I run GETDNS STUBBY and DNSMASQ-FULL as
described here along with ( wait for it )
FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby
and naturally a properly configured and encrypted VPN -

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

2 - 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. The purpose of this tutorial is to demonstrate and eliminate potential errors during setup of STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING as the title asserts.

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

4 - 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 in step 5

5 - 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
Stubby github config: https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example
VERY IMPORTANT UPDATE:
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:

# All DNS Privacy Servers Below Tested and Updated On June 30 2020 With A+ Rating - 
# 100%  Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n 
# These servers support the most recent and secure TLS protocol version of TLS 1.3 **
# Good configuration - These server configurations support only 
# TLSv1.2 and TLSv1.3 protocols - current most secure encryption.
# see country code lists here :
# https://www.nationsonline.org/oneworld/country_code_list.htm and / or
# https://www.iban.com/country-codes
# Use as many or as few depending on your specific needs 

resolution_type: GETDNS_RESOLUTION_STUB
round_robin_upstreams: 1
appdata_dir: "/var/lib/stubby"
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 9000
listen_addresses:
  - 127.0.0.1@5453
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
tls_ca_path: "/etc/ssl/certs/"
upstream_recursive_servers:
### IPV4 Servers ###
### DNS Privacy DOT Test Servers ###
## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD )
  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## 2 - The Surfnet/Sinodun DNS TLS Server #3  A+ ( NLD )
  - address_data: 145.100.185.18
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## 3 - The dns.cmrg.net DNS TLS Server  A+ ( CAN )
  - address_data: 199.58.81.218
    tls_auth_name: "dns.cmrg.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
## 4 - The BlahDNS Japan DNS TLS Server  A+ ( JPN )
  - address_data: 45.32.55.94
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: gIoiNFxX1Nw+7/pVsmUKBU941bMBYjEYuB2T9drULOM=
## 5 - The BlahDNS German DNS TLS Server  A+ ( USA Hosted In DEU )
  - address_data: 159.69.198.101
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE=
## 6 - The BlahDNS Finland DNS TLS Server  A+ ( FIN )
  - address_data: 95.216.212.177
    tls_auth_name: "dot-fi.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc=
## 7 - The dns.neutopia.org  DNS TLS Server  A+ ( FRA )
  - address_data: 89.234.186.112
    tls_auth_name: "dns.neutopia.org"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
## 8 - The Foundation for Applied Privacy DNS TLS Server #1  A+ ( AUT )
  - address_data: 94.130.106.88
    tls_auth_name: "dot1.applied-privacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU=
## 9 - The Foundation for Applied Privacy DNS TLS Server #2  A+ ( AUT )
  - address_data: 93.177.65.183
    tls_auth_name: "dot1.applied-privacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU=
## 10 - The Secure DNS Project by PumpleX DNS TLS Server #1  A+ ( GBR )
  - address_data: 51.38.83.141
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: Bd5frvFVxtk4ru8L7JozLol7dn80YDTaP8b3yU06JB8=
## 11 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN )
  - address_data: 115.159.131.230
    tls_auth_name: "dns.rubyfish.cn"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=
## 12 - The Lorraine Data Network DNS TLS Server A+ ( FRA )
  - address_data: 80.67.188.188
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
## This certificate is currently expired which
## does not pose any concerns in SPKI mode
## (in practice with Stubby)
## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/
## 13 - The DNSPRIVACY.at TLS Server #1  A+ ( DEU )
  - address_data: 94.130.110.185
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: MjA0IXWNt3+LCmuKT9ewjX3PwJxNqs2RoTa/NmzPHwI=
## 14 - The DNSPRIVACY.at TLS Server #2  A+ ( DEU ) - expired 2020-04-01
  - address_data: 94.130.110.178
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo=
# 15 - The ibksturm.synology.me DNS TLS Server  A+ ( CHE )
  - address_data: 85.5.93.230
    tls_auth_name: "ibksturm.synology.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: npNOnBcLbvZWZgdmcuFaEqYJbaGjBlHMf9DknDoIkgg=
## 16 - The dns.flatuslifir.is DNS TLS Server  A+ ( ISL )
  - address_data: 46.239.223.80
    tls_auth_name: "dns.flatuslifir.is"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3QPTZIcJdZFCx5t3tZiqdCBYpigUX+1Gwz+iQfLXrJE=
### Publicly Available DOT Test Servers ###
## 17 - The ContainerPI.com - CPI DNS TLS Server  A+ ( JPN )
  - address_data: 45.77.180.10
    tls_auth_name: "dns.containerpi.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs=
## 18 - The FEROZ SALAM DNS TLS Server  A+ ( GBR )
  - address_data: 46.101.66.244
    tls_auth_name: "doh.li"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: VEjC/umyfulb4CbLZ6mIyEqHPbwv0D6osfrUbi8Dm28=
## 19 - The Andrews & Arnold DNS TLS Server #1  A+ ( GBR )
  - address_data: 217.169.20.23
    tls_auth_name: "dns.aa.net.uk"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 41OknyzhvFDNZqlvTs4mFTWSkAXSPXWQ4wRgky5Qyzc=
## 20 - The Andrews & Arnold DNS TLS Server #2  A+ ( GBR )
  - address_data: 217.169.20.22
    tls_auth_name: "dns.aa.net.uk"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: I88W3UOUiCa+1KMukcoys2FtyL93GAKalO1EW7iOZJk=
## 21 - The dns.seby.io - Vultr DNS TLS Server  A+ ( AUS )
  - address_data: 45.76.113.31
    tls_auth_name: "dot.seby.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
## 22 - The dns.seby.io - OVH DNS TLS Server  A+ ( AUS )
  - address_data: 139.99.222.72
    tls_auth_name: "dot.seby.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw=
## 23 - The Digitale Gesellschaft DNS TLS Server #1  A+ ( CHE )
  - address_data: 185.95.218.43
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: S+DuqASQtCTm8qr4G9z53uLEy230lIDgbHl9AtId0Yw=
## 24 - The Digitale Gesellschaft DNS TLS Server #2  A+ ( CHE )
  - address_data: 185.95.218.42
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: bthpji8smy3f2lSvweu5hXpb/6hLrk3Txh6euWztF5Q=
## 25 - The Antoine Aflalo DNS TLS Server #1  A+ ( USA )
  - address_data: 168.235.81.167
    tls_auth_name: "dns-nyc.aaflalo.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: kjMUEH0kNEaZ4cDn3SQV/vANgycPm0qRPMU2yd4OlT0=
## 26 - The Privacy-First DNS TLS Server #1  A+ ( JPN )
  - address_data: 172.104.93.80
    tls_auth_name: "jp.tiar.app"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 6PiLZvmKVJKLekrweBWO1tjRmratPGWkadjsicFXAlU=
## 27 - The Privacy-First DNS TLS Server #2  A+ ( SGP Hosted In USA )
  - address_data: 174.138.29.175
    tls_auth_name: "dot.tiar.app"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5hG9dlXtWeLWdCfE4QdNWlalxlFITtt8c2YgZVaCNWQ=
## 28 - The ibuki.cgnat.net DNS TLS Server  A+ ( USA )
  - address_data: 35.198.2.76
    tls_auth_name: "ibuki.cgnat.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: C+ximOx14NAMAWq9TvgT1irRs2R37MnECtGBTO1OOYU=
## 29 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA )
  - address_data: 45.67.219.208
    tls_auth_name: "dot.westus.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: tfdCeUhPuPGyufMk1O1m8wMirCGpuS/chiAUyRCkBmY=
## 30 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA )
  - address_data: 185.213.26.187
    tls_auth_name: "dot.eastus.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: PDuAjVfbR5apthM4n0c1LzcmJH/aBd4SAqpnnt4Bmy4=
## 31 - The PI-DNS.COM Central Europe DNS TLS Server A+ ( DEU )
  - address_data: 88.198.91.187
    tls_auth_name: "dot.centraleu.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 9rEHDwaRyQf/NFX6OH2gyJOrPg6ZABeEQ2PIXgrgyyE=
## 32 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN )
  - address_data: 95.216.181.228
    tls_auth_name: "dot.northeu.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: gouwOSAsY4GvTHhm1aai15Xt8+L84199aAVN3CrWsiI=
## 33 - The PI-DNS.COM East Australia DNS TLS Server A+ ( AUS )
  - address_data: 45.63.30.163
    tls_auth_name: "dot.eastau.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: TFNiPxVz7a1gxDV5x8i6zY3gvEFL/o99zgmwc79KrTs=
## 34 - The PI-DNS.COM East Asia DNS TLS Server A+ ( USA )
  - address_data: 66.42.33.135
    tls_auth_name: "dot.eastas.pi-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: XDrRwtqxJgnvmBoWZrD9QE1QAjF74qPWnBv2UJ4Wkgg=
## 35 - The Snopyta DNS TLS Server A+ ( FIN )
  - address_data: 95.216.24.230
    tls_auth_name: "fi.dot.dns.snopyta.org"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE=
## 36 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" )
  - address_data: 209.141.34.95
    tls_auth_name: "uncensored.lv1.dns.nixnet.xyz"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: flpUestk4tYCQ1wB3WP5sIztvRIOiAPLKCtVqbM/SJ8=
## 37 - The NixNet Uncensored New York DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" )
  - address_data: 199.195.251.84
    tls_auth_name: "uncensored.ny1.dns.nixnet.xyz"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cXriM10X2+lW6V8NOrMZd2nssgC1TeW2DutGlmMn5fc=
## 38 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX )
## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" )
  - address_data: 104.244.78.231
    tls_auth_name: "uncensored.lux1.dns.nixnet.xyz"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 7cOZUgpjYw3Qy5K97ww3APnMau8zHrIEbC0znGgEGyw=
## 39 - The Lelux.fi DNS TLS Server  A+ ( FRA Hosted In GBR )
  - address_data: 51.158.147.50
    tls_auth_name: "resolver-eu.lelux.fi"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 77zOtPEiiEnIEliuHySTchfWbyfCV+nfHeejrN0gzpM=
## 40 - The Lightning Wire Labs DNS TLS Server  A+ ( DEU )
  - address_data: 81.3.27.54
    tls_auth_name: "recursor01.dns.lightningwirelabs.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: jVdEaKPP27O6wPq6wbvXrTtDsDEiOoVdyTY9uUHXDJ0=
## 41 - The Hostux DNS TLS Server  A+ ( LUX )
  - address_data: 185.26.126.37
    tls_auth_name: "dns.hostux.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE=
## 42 - The dnsforge.de DNS TLS Server #1  A+ ( DEU )
  - address_data: 176.9.1.117
    tls_auth_name: "dnsforge.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
## 43 - The dnsforge.de DNS TLS Server #2  A+ ( DEU )
  - address_data: 176.9.93.198
    tls_auth_name: "dnsforge.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
# 44 - The Freifunk München DNS TLS Server  A+ ( DEU )
  - address_data: 195.30.94.28
    tls_auth_name: "doh.ffmuc.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 1swf1Y7mDE9KBYARlBG00o5sQ7zZjOGSb0ahWpaKV5M=
# 45 - The doh.defaultroutes.de DNS TLS Server  A+ ( DEU )
  - address_data: 5.45.107.88
    tls_auth_name: "doh.defaultroutes.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0=
## 46 - The CIRA Canadian Shield DNS TLS Servers  A+ ( CAN )
  - address_data: 149.112.121.10
    tls_auth_name: "private.canadianshield.cira.ca"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
  - address_data: 149.112.122.10
    tls_auth_name: "private.canadianshield.cira.ca"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
# 47 - The dns.dnshome.de DNS TLS Server #1  A+ ( DEU )
  - address_data: 185.233.106.232
    tls_auth_name: "dns.dnshome.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
  - address_data: 185.233.107.4
    tls_auth_name: "dns.dnshome.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
## 48 - The Usable Privacy DNS TLS Server  A+ ( DEU / AUT )
  - address_data: 149.154.153.153
    tls_auth_name: "adfree.usableprivacy.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: VEmtR6+zgZ2mcyEI0NvpDCFhijAoawwKbStKYTj+774=
## 49 - The DeCloudUs DNS TLS Server  A+ ( DEU )
  - address_data: 176.9.199.152
    tls_auth_name: "dot.decloudus.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: L/QUBSkq/goTWjGgW7DjC29IoSdaqrVYGG5ME7lJYMo=
## 50 - The Hurricane Electric DNS TLS Server A+ ( USA )
  - address_data: 74.82.42.42
    tls_auth_name: "ordns.he.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: G9pQNrYB98Wll0AmBF/GsMMn6gaDbXDnInV1je1MaPo=
### Anycast Publicly Available DOT Test Servers ###
## 51 - The NixNet Uncensored Anycast DNS TLS Servers  ( Anycast )
  - address_data: 198.251.90.114
    tls_auth_name: "uncensored.any.dns.nixnet.xyz"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug=
  - address_data: 198.251.90.89
    tls_auth_name: "adblock.any.dns.nixnet.xyz"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug=
## 52 - The DNSlify DNS TLS Servers  A+ ( Anycast )
  - address_data: 185.235.81.1
    tls_auth_name: "doh.dnslify.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=
  - address_data: 185.235.81.2
    tls_auth_name: "doh.dnslify.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=

# 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"
# 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_3
# 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


In order for TLSv1.3 protocol to work properly ( read at all ) in your Stubby 
instance, OpenWrt must have OpenSSL 1.1.1 active and configured in the kernel.
Any OpenWrt 18.06 Build does not offer OpenSSL 1.1.1 in any shape, form or fashion.
OpenWrt 19.07.0 Release Candidates and Snapshots do provide OpenSSL 1.1.1 support.
As I have mentioned, I run Davidc502 OpenWrt Snapshots - moderately customized
Builds for Linksys wrt1200ac wrt1900acx wrt3200acm wrt32x Routers found here:
https://dc502wrt.org/  - These Builds come out approximately every two weeks with
the latest Linux Kernels, software packages and other bleeding edge features including
OpenSSL 1.1.1 with TLSv1.3 support. Once you have OpenSSL 1.1.1 with TLSv1.3 simply
follow the guide above in order to set Stubby to implement TLS1.3.
The operative lines necessary are these two specifically found at the bottom
of the stubby.yml file above:

tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
tls_min_version: GETDNS_TLS1_3


See below for TLS1.3 Support Check SSH Commands -

openssl s_client 168.235.81.167:853

OR :

openssl s_client 159.69.198.101:443

Read Out Will Be Verified By These Lines Below:

Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_CHACHA20_POLY1305_SHA256

OR :

Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Depending on Configuration on Tested DOT Server

PS - Lastly, you can and should take advantage of this new DNS OVER TLS provider.
You need to sign up and use configured settings in order to use it.
NextDNS is a free service - ANYCAST and pretty much cutting edge.
ANYCAST speeds up your DNS - Here it is:
NextDNS https://my.nextdns.io/signup

or feel free to use and test
NextDNS " Try it now for free " Feature
go to : https://nextdns.io/

I also strongly encourage you to subscribe to blockerDNS found here : https://blockerdns.com/
This new DOH / DNS OVER TLS provider is the fastest I have run across. blockerDNS is run by
Tambe Barsbay a seasoned, thorough and extremely proficient tech practitioner.
blockerDNS is based in the U.S. and its infrastructure is hosted on Google Cloud Platform
and DigitalOcean. You can view blockerDNS subscription options here : https://blockerdns.com/tryit -
Most significantly, Tambe stands by his claim that he offers " Instant support by phone or email ".
Overall blockerDNS is a great DNSPRIVACY DNS Service. Tip : The Mobile $0.99 per month option should suffice for most home users. Links : https://tambeb.com/ https://blockerdns.com/blog
https://blockerdns.com/support https://blockerdns.com/overview

6 - Integration of STUBBY with DNSMASQ
A - Set DNSMASQ to send DNS requests to STUBBY - this is done to allow Localhost ( 127.0.0.1 ) 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 127.0.0.1#5453 .
There are two methods to do this:

uci add_list dhcp.@dnsmasq[-1].server='127.0.0.1#5453'
uci set dhcp.@dnsmasq[-1].noresolv=1
uci commit

Or edit the /etc/config/dhcp file

nano /etc/config/dhcp
list server '127.0.0.1@5453'
option noresolv '1'

7 - Disable Sending DNS Requests to ISP Provided DNS Servers

uci set network.wan.peerdns='0'
uci set network.wan.dns='127.0.0.1'
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

Or

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

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

9 - 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 - In the version 18 and later builds of OpenWRT this step has been modified as follows to keep from having two IPv6 DHCP servers running:

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

10 - 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 dhcp.@dnsmasq[-1].dnssec=1
uci set dhcp.@dnsmasq[-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 !

11 - 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 dhcp.@dnsmasq[0].cachesize=1000
uci commit dhcp

Or edit the /etc/config/dhcp file

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

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

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

13 - 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 within. 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 @anon85512524
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.

VERY IMPORTANT TIP:
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 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

Most Simple and Direct Method:
gnutls-cli --print-cert -p 853 159.69.198.101 | grep "pin-sha256" | head -1 
       And / Or With Adjustment For SSL Port and Address Being Tested
gnutls-cli --print-cert -p 443 159.69.198.101 | grep "pin-sha256" | head -1 - where you must opkg install gnutls

OR
echo | openssl s_client -connect '185.49.141.37:853' 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 @185.49.141.37 +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 @199.58.81.218 -p 443 +tls-ca +tls-host=dns.cmrg.net example.com

Peace Unto All,

directnupe

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

5 Likes
2

@directnupe
Many thanks for posting this very useful guide!
I managed to follow it, and have set up my router using stubby.
A few questions:

  1. Any reason you set padding size to 256? (dnsprivacy.org seem to recommend 128).
  2. Does using stubby for DNSSEC require dnsmasq-full or is dnsmasq sufficient?
  3. Is there any way to check and /or validate that any of this is working as intended? My setup seems to be working, but I have no way of knowing if e.g. the DNSSEC bit is working. If you could add something to your guide about logging and /or how to check whether things are working it would be much appreciated!
    Thanks to everyone (including yourself) who is working towards dns privacy!
3

Hello Caveat, I'm not directnupe but since this is based on my guide I think I can answer 2 and 3 better.

But first I should inform that directnupe forgot an essential seeting for DNSSEC to work, he forgot to copy it from my guide: [Tutorial] DNS-over-TLS with dnsmasq and stubby (no need for unbound)

You need this line in stubby.yml:

dnssec_return_status: GETDNS_EXTENSION_TRUE

DNSSEC validation is being done by stubby, dnsmasq is just proxying the DNSSEC information ('proxy-dnssec').
There are a bunch of sites to test DNSSEC on that you can find by just googling 'DNSSEC Test', here's a couple of them, the second one tests many other things related to DNS also:

https://dnssec.vs.uni-due.de/
https://cmdns.dev.dns-oarc.net/

4

@directnupe

You forgot to copy this line from my guide:

dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/tmp/stubby"

To stubby.yml, this is what enables stubby to do dnssec validation. the appdata_dir is optional, but I recommend it, by default the keys are stored in /root, moving them to /tmp moves them to the RAM only.

From my guide: [Tutorial] DNS-over-TLS with dnsmasq and stubby (no need for unbound)

Explanation:
dnssec_return_status: GETDNS_EXTENSION_TRUE : This line provides DNSSEC validation
appdata_dir: Where the keys for DNSSEC are stored

5

@Specimen many thanks for the very helpful reply, and also many thanks for the original guide! I actually came across your guide first, and I think I used it and directnupe's together. I had the dnssec_return_status line in my .yml file but not the appdata_dir. You say it is is optional and that by default keys are stored in /root but my /root directory remains empty at all times.
Also many thanks for the DNSSEC test sites. Both test sites say that DNSSEC is not working!
I've added the appdata line and rebooted. It's created the /tmp/stubby directory but the directory itself is empty. Also DNSSEC still not working. Any ideas?

6

Is it really empty? By default the dir the keys are stored in is hidden (starts with a .), use 'ls -a' command to show these 'hidden' files and folders.

If stubby's DNSSEC validation is working you should see these files:

-rw-------    1 root     root        4.0K Aug 18 10:08 root-anchors.p7s
-rw-------    1 root     root         651 Aug 18 10:08 root-anchors.xml
-rw-------    1 root     root        1.6K Aug 19 19:34 root.key

In whatever is the dir assigned in appdata_dir or in the /root/.<I don't remenber the name> :slight_smile:

As for ideas to why it's not working, recheck all your setup, first you have to guarantee that all the dns requests from clients are going through stubby and that all the DNS servers in stubby support DNSSEC, recheck all settings.

7

If the dir is empty than it's likely the DNS servers you have in your config do not support DNSSEC, try with just Cloudflare to start with.

You have also to make sure TLS authentication is working, try running stubby manually on the router with the fla '-v6' (verbose mode level 6) it will spit out in the console what is doing if TLS handshakes succeed or not.

8

You have to manually create a root.key file containing the keys for DNSSEC to work properly. Create such file (i.e., "root.key") in /etc/stubby and include the following lines in it:

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Then, in the configuration file stubby.yml, include the following line:

dnssec_trust_anchors: "/etc/stubby/root.key"

That should solve it.

Cheers.

9

No, you don't need to do this!

If stubby is working properly it creates those by itself, downloads the trust anchors.

1 Like
10

Both directories /root and /tmp/stubby are empty (ls -a).
Just for sake of sanity I'm posting my stubby.yml file in case anything is amiss:

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1@5453
  -  0::1@5453
# To enable DNSSEC validation when using Stubby:
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/tmp/stubby"

upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853

  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853

Running stubby -v6 I get the following output:

[20:23:25.393209] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=    19, Timeouts  =     0, Best_auth =Success
[20:23:25.393405] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0
[20:23:25.401388] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=    19, Timeouts  =     0, Best_auth =Success
[20:23:25.401579] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0
[20:23:40.542556] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=    60, Timeouts  =     0, Best_auth =Success

Does this mean TLS authentication is working?

11

I know that is not the best way to do it but stubby for whatever reason is not creating the keys itself. And these keys, by the way, are not a secret, they are widely available in the internet as you can see here: https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

1 Like
12

Yes, then it's better to post the link instead.

13

TLS is working. The config seems fine.

You're both reporting that Stubby is not downloading the keys, I can't understand immediately why this is happening.

Maybe related to the getdns version?
source: https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby

DNSSEC

To enable DNSSEC validation when using Stubby add the following option to the configuration file

dnssec_return_status: GETDNS_EXTENSION_TRUE

A trust anchor is also required for DNSSEC validation.

getdns version 1.2 and later include support for automatic trust anchor management - which will automatically fetch a trust anchor if none is present on the system. See 'Zero configuration DNSSEC' (and below) for the specific details of key management for DNSSEC for this case.

If using a version of getdns earlier than 1.2 then a trust anchor must be manually installed and managed on the system. We recommend using unbound-anchor .

For my architecture, on 18.06.1, getdns is version: 1.4.2

14

I've just made it work with automatic installation of the keys. Use the following line in the config file stubby.yml:

appdata_dir: "/tmp"
15

ok many thanks @Specimen for the confirmation that TLS authentication is working at least!
My architecture is 18.06.0, and getdns version like you is 1.4.2
Are you running your "install to ram" method or your "permanent install"? I ask because the big difference is that in your "install to ram" method you use ca-bundle where as in the permanent you use ca-certificates. Could that possibly be the issue here? I installed ca-certificates.

16

If TLS is working than the certificates are working.
I explain in a post in my tutorial the difference between ca-bundle and ca-certificates and why they are used differently.

We can safely assume that TLS (and certs) is not the problem, it's just DNSSEC.

1 Like
17

Ok I think I've manage to resolve the issue!
As you see from my stubby.yml file posted above I was using tls_auth_name method and not tls_pubkey_pinset for my cloudfare servers. I had tried adding the pubkeys before but I had gotten the formatting wrong (yaml is very picky!) and it wouldn't work, so I'd just left them out thinking they were not necessary.
But it seems they are necessary for DNSSEC to work, at least on my setup. If I have either:

  1. just the tls_pubkey_pinset, or
  2. both tls_pubkey_pinset and the tls_auth_name
    then DNSSEC validates, but if I have
  3. just the tls_auth_name then DNSSEC fails

Also the 3 files:
root-anchors.p7s root-anchors.xml root.key
are now in the /tmp/stubby directory where they should be!

Many thanks for your help in resolving this issue @Specimen. Much appreciated!

1 Like
18

I'm glad you got it sorted... But...

It's interesting that you need pubkeys for Cloudflare, in my setup (working) I'm just using the tis_auth_name method.
Also, from your output of running stubby with -v6 the TLS auth was working ("Best_auth =Success"), so I don't quite see how the pubkeys can be related to DNSSEC.

Pairing that with rog's 'solution', of using /tmp instead of /tmp/stubby (it shouldn't make ANY difference, if that's what you actually meant, @rog , if you weren't setting the appdir in the first it means you didn't read my recommendation), I think the problem was just a temporary unavailability of the server it downloads the keys from rather than a specific setup setting.

19

@Specimen, you may be right. I've removed the keys (so just using tls_auth_name) and DNSSEC is still working. Temporary unavailability of the server it downloads keys from seems like a good explanation.

1 Like
21

Also the fact that if the keys are already there (if you didn't delete them or rebooted the router) then it just reuses them when it starts.