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

READ ENTIRE GUIDE BEFORE YOU BEGIN

Tutorial / Guide Was Updated on Jan 15 2020
in order to keep you in step with changes on packages needed
for OpenWrt 19.07.0

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
Changes to DNS OVER TLS From The DNS Privacy Project.

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 :

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

Further, Personally, I run GETDNS STUBBY and UNBOUND 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 -

Specifically designed for GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. Here is a basic guide as to how to do it - Torsten's Thoughtcrimes
https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/
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.

As always - opkg update
first and foremost

Prerequisite
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 update ; opkg install unbound-daemon-heavy unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host unbound-checkconf odhcpd
2 - opkg update ; opkg install stubby getdns

As per Torsten's Thoughtcrimes Guide:

3- My WORKING CONFIGS /etc/unbound/unbound_srv.conf
( You Must Adjust For Your Router - I Run WRT1900ACS and WRT3200ACM So I Have Plenty Of Ram, Storage and 2 CPU's )

" Optimize Unbound " - 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/ for basic guide

cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF
server:
# 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
# depends on number of cores: 1024/cores - 50
outgoing-range: 8192

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

cache-min-ttl: 3600
cache-max-ttl: 86400
hide-identity: yes
hide-version: yes
hide-trustanchor: yes
harden-glue: yes
harden-dnssec-stripped: yes
infra-cache-numhosts: 100000
num-queries-per-thread: 4096
max-udp-size: 3072
minimal-responses: yes
rrset-roundrobin: yes
use-caps-for-id: no
do-ip6: no
do-ip4: yes
do-tcp: yes
do-udp: yes
prefetch: yes
prefetch-key: yes
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes
aggressive-nsec: yes
so-reuseport: yes
unwanted-reply-threshold: 10000000
interface-automatic: yes
verbosity: 1
private-domain: "your.domain" ## put your domain here
do-not-query-localhost: no
harden-referral-path: yes
target-fetch-policy: "0 0 0 0 0"
val-clean-additional: yes
ip-ratelimit: 300
ip-ratelimit-factor: 10
incoming-num-tcp: 100
edns-buffer-size: 1472
UNBOUND_SERVER_CONF

As per Torsten's Thoughtcrimes Guide : Don’t let each server know the next recursion
SSH command line:
uci set ‘unbound.@unbound[0].query_minimize=1’

4 - I believe that this change to UCI was made to allow for DNSMASQ handling DNS OVER TLS. However, if you are like me - I prefer to still use UNBOUND and this how to do it. See below which is at the top of the /etc/stubby/stubby.yml file - which used to be the only file to configure STUBBY:

5 - 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:
nano /etc/stubby/stubby.yml and change the file content to:

# All DNS Privacy Servers Below Tested and Updated On May 26 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 **
# Also I have added the Country Locations of These DNS PRIVACY Servers 
# using the Alpha 3 Code Format
# see country code lists here :
# 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:
## 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: 2x9bg3D2uUv/aR3P22pDS2OGyKRXxDQFY+EjY3u2o+w=
## 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: +qcX6xelJzGg5+0jn1j05vrssAueYej9XrnhL9+NKXo=
## 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: 1qxET6WIHQ/oEG4c8xgBWoVFA7JQMamvNCIP3hVg7Hw=
## 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: xctlty6R/YkqPxauSkA7cEBhbt1HwGhhpEEYMkiYOQE=
## 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: efsWik8+ERomZMrH3Ox/30saZWLWlmnH5Dk5wyjRWn4=
## 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: 7edzTURJQoFlhpbT1OMAj2ZYSx+bi5B1eyRjEFsXseI=
## 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 Antoine Aflalo DNS TLS Server #2  A+ ( NLD )
  - address_data: 176.56.236.175
    tls_auth_name: "dns.aaflalo.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: fzhsEjaCf5q3Csvpl+p6HB13A3pefqs79TXYzYEn+QI=
## 27 - 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: 7CcU1rk7OmdjZg+oz+c8N4fguYlYdnJuYcdNvM/I+/E=
## 28 - 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=
## 29 - 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: OcRaI3p/xMjnj5+LlSpXP1aCnEgtRs5g38QQi7PbIO8=
## 30 - 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: M+nrb/hd9eMJuPWeFht/k1dc1/jVc5BBfh+CYCliAJ4=
## 31 - 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: zxgnoyq2tM5LwFUFTmXFp8iHKen7hf0KcIHbRtanQAs=
## 32 - 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: ujlSlfFb2vMMwl3nCNHF2MJ36d2+3KGbSbuuAYH+N1U=
## 33 - 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: TFadmV6S2C1WerCF+NY+/cHBjDS2iWRHZpT7JqktSpk=
## 34 - 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: gLV9UKZ+FNO0AI+W5g3qvOkHqyX4wrJ70MWtioCNXM8=
## 35 - 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: Wd/+3VJW7Xu904nJC35EBocuVs9XQNAnIOPoda848NQ=
## 36 - 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: Zfbl1gzu2ziQ/rBw+zxBGsuoguapUfhEkQm7s8GwRiI=
## 37 - 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: fumOUAwTnToMZ4SBt1zmzZthDDwGAr25qr1b0Lgvuuo=
## 38 - 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: JXWEabtuBageRVNeJFedi4nhi7XCmS78N10NWQHA/eA=
## 39 - 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=
## 40 - 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=
## 41 - 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=
# 42 - 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=
# 43 - 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=
## 44 - 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=
# 45 - 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=
### Anycast Publicly Available DOT Test Servers ###
## 46 - 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=
## 47 - 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=
### DNS Privacy Anycast DOT Public Resolvers ###
## 48 - The DNS.SB DNS TLS Servers  A+ ( Anycast )
  - address_data: 185.222.222.222
    tls_auth_name: "dns.sb"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
  - address_data: 185.184.222.222
    tls_auth_name: "dns.sb"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
## 49 - The Tenta DNS OpenNIC TLS Servers  A+ ( Anycast )
  - address_data: 99.192.182.101
    tls_auth_name: "opennic.tenta.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: IWL0sIdCNA9qM+elnfSMN1arzEDeptcN4uHnsWhtQW8=
  - address_data: 99.192.182.100
    tls_auth_name: "opennic.tenta.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: IWL0sIdCNA9qM+elnfSMN1arzEDeptcN4uHnsWhtQW8=
# 50 Quad9 'secure' service - Filters, does DNSSEC, doesn't send ECS
## ( NOTE: recommend reducing idle_timeout to 9000 if using Quad9 )
  - address_data: 149.112.112.112
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg=
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg=

# 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

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
OpenWrt 19.07.0  does provide OpenSSL 1.1.1 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

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 - Now from the Torsten's Thoughtcrimes Guide again - My WORKING CONFIG /etc/unbound/unbound_ext.conf

cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF
forward-zone:
    name: "."    # Allow all DNS queries
    forward-addr: 127.0.0.1@5453
UNBOUND_FORWARD_CONF

7 - Once again follow the steps in Torsten's Thoughtcrimes Guide

Move dnsmasq to port 53535 where it will still serve local DNS from DHCP
Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535
uci set 'dhcp.@dnsmasq[0].port=53535'

Configure dnsmasq to send a DNS Server DHCP option with its LAN IP
since it does not do this by default when port is configured.
uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)"
uci set 'unbound.@unbound[0].dhcp_link=dnsmasq'

Save & Apply (will restart dnsmasq, DNS unreachable until unbound is up)
uci commit

Restart (or start) unbound (System -> Startup -> unbound -> Restart)
/etc/init.d/unbound restart

8 - From https://github.com/openwrt/packages/tree/master/net/unbound/files HOW TO Integrate with DHCP
Parallel DNSMASQ nano /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
https://www.leowkahman.com/2016/05/23/openwrt-encrypted-dns-lookup-using-multiple-dnscrypt-servers/
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:
or using UCI

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

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

or Via Uci

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

8A - 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 commit && reload_config 

9 - Now go to the default UNBOUND configuration file /etc/config/unbound and enter the following :

Open file by SSH nano /etc/config/unbound - then only replace the config unbound - leave the config zone entries as they are

nano /etc/config/unbound  

config unbound
        option add_extra_dns '0'
        option add_local_fqdn '1'
        option add_wan_fqdn '0'
        option dhcp4_slaac6 '0'
        option dns64 '0'
        option dns64_prefix '64:ff9b::/96'
        option domain "your.domain" ## put your domain here
        option domain_type 'static'
        option edns_size '1280'
        option extended_stats '1'
        option hide_binddata '1'
        option extended_luci '1'
        option luci_expanded '1'
        option listen_port '53'
        option localservice '1'
        option manual_conf '0'
        option protocol 'ip4_only'
        option query_min_strict '1'
        option rebind_localhost '0'
        option rebind_protection '1'
        option recursion 'default'
        option resource 'medium'
        option root_age '28'
        option ttl_min '120'
        option unbound_control '2'
        option validator '1'
        option validator_ntp '1'
        option verbosity '2'
        list trigger_interface 'lan'
        list trigger_interface 'wan'
        option query_minimize '1'
        option dhcp_link 'dnsmasq'

10 - For DNS OVER TLS resolution add Custom DNS resolver as follows:
using UCI

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

11 - VERY IMPORTANT STEP - after setting your DNS to 127.0.0.1 ( you need 127.0.01 as this is what both Stubby and Unbound use as their local resolver )
You must 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.

12 - 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 or both 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

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

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

Now all you need to do is run is a properly configured VPN Service.
Lastly, you can check your DNS at GRC Spoofability Test - DNS Leak - or any of such service.

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 here for TorGuard Open VPN Setup

See here for PIA VPN OPENVPN Setup

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

Peace and Grace Unto All,

directnupe

2 Likes

directnupe,

First, thank you for such an extremely well written guide. I currently use my VPN service (IVPN) provided DNS server. I'm considering switching to getdns-stubby-unbound per your written instruction set, however I am concerned that my DNS lookup times will be substantially worse than my current set-up. Would you comment on the DNS lookup performance implications associated with implementing the process you describe?

Thank you.

Dear slim0287,
Hello and thanks for the compliment - and I am a retired English Teacher - so I guess my writing reflects that experience.
As far as speed and resolution goes - I run a VPN - Torguard and my speeds are excellent. My opinion is that your DNS speeds will rely a great deal on the native speed of your tunneled connection which your VPN provider has - along with the speeds of your ISP provider. I have Verizon Fios - and with my Torguard VPN connected and running DNS OVER TLS ( as documented here ) - I get the same speeds as if I were hooked up to FIOS directly.
Also - read this again where I mention - that DNS OVER TLS is encrypted end to end DNS - so no one knows your lookups. And even if the DNS OVER TLS providers were to see my DNS queries - they are coming from my Torguard encrypted tunneled connection.
Give this a try and see how it works for you specifically speed wise. You can always go back to your current setup if things slow down considerably. Good luck and let me know how it works for you. By the way - notice that I use Tenta and Cloudflare as they are both AnyCast DNS providers with DNS OVER TLS and QNAME minimisation enabled. Anycast means there are servers near you - as they have servers worldwide. If you read carefully I have chosen to ONLY use DNS TLS SERVERS which provide QNAME minimisation - this feature speeds up UNBOUND and ensures privacy by limiting the data sent between UNBOUND ( and STUBBY ) to the upstream servers. In other words, the setup is extremely fast in my opinion and do not forget that UNBOUND has " caching " - Read my first tutorial which is referred to and has links for at the beginning of this tutorial for a better understanding of this entire setup.

Peace and God Bless,

directnupe

A retired English Teacher? With what you've written above I figured you were working with Vint Cerf and Bob Kahn when they invented TCP/IP! I will look through your instructions carefully and give it a try, however it may be a week before I get to it. Thanks again!

Dear slim0287,
Once again - thank you and you are welcome for your kind words. Take your time - and let me know how it goes. But I will tell you to be confident - because literally there have been over ten thousand people who have followed this tutorial successfully. So - it must not beyond the skill level and capabilities of the average knock around hobbyists such as you and myself.
What I am good at is research - which I guess means - searching and then researching again and again until you learn a little bit about a lot. I am sure that we all work harder and smarter as we get older.
However, again thank you - and I will assist you in any way that I can in order to help you with you getting this set up. Feel free to reach out should you need to do so.

God Bless You and Yours Always In Peace,

directnupe

directnupe,

I went ahead and did your implementation for getdns-stubby-unbound. It looks like you have an error in step 14. You indicate the bold faced text should be commented, however I believe you want the “for” loop as an actual script command and it is in boldface. After all, the for loop is what provides the pause prior to restarting unbound, stubby, and openvpn.

The DNS lookups do take quite a bit of extra time compared to using a DNS lookup server. However, of course the results are cached, so that extra time is only a one-time affair.

I have a few questions, as follows:

  1. I have ipv6 access through my ISP. Do I need to do anything to my configuration files to ensure I’m not somehow using ipv6 for DNS resolution? I don't think any requests are going out to ipv6 nameservers, but I do have two DNS servers configured for ipv6 so I thought I would ask.

  2. You write the guide for unbound 1.8.1-2. I’m using davidc502’s r8373 build from 10-25. It gives me unbound 1.8.1-1. Any reason I should be concerned about the mismatch?

  3. My dnsmasq options haven’t been the defaults for quite some time. I eliminated “list server” and “noresolv” from the options which were included because I was using my VPN's DNS nameserver. However are there other dnsmasq options I should be concerned about? Seems like everything is working fine but I thought I would ask.

  4. Lastly, when it comes time to upgrade the davidc502 build again, I gather there is only a subset of your 14 steps that I need to repeat. Any comments on that upgrade process?

Thanks again! I appreciate running my own DNS resolver.

Dear slim0287,
First thanks for the heads up about the line which begins with for i in you are absolutely correct - it should not be commented out and I have fixed it. I am glad to see that you got this up and running.By working together we can all get things working for all of us.
As far as your questions go:
1- ipv6 - I do not use it so you might be better off asking someone more familiar with this type of setup. However, there are DNS OVER TLS SERVERS for ipv6 if you configure these in your /etc/stubby/stubby.yml file then UNBOUND will resolve to those upstream name servers. Just remember that if you use upstream ipv6 nameservers you must configure Stubby to use listen_addresses: - 0::1 in addition to - 127.0.0.1 for ipv4 -
As long as you do not change anything on the Network > Interfaces page - it is my understanding that OpenWrt supports IPV6 out the box. if you notice there is even a Wan6 interface - at least on Davidc502 Builds. If you look under Global network options on this page you will see your IPv6 ULA-Prefix displayed. So, as far as I know - you should be good to go regarding DNS OVER TLS with IPV6. Just remember to choose upstream nameservers with QNAME minimisation enabled as we discussed earlier. As a matter of fact - most if not all of the name servers I listed in this guide also provide IPV6 DNS OVER TLS - so that it a good place to start. See here : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers and look under the the second column " IP addresses " for IPV6 addresses of nameservers. Do take special note that some providers have a different SPKI pin ( in the fifth column ) for IPV6 nameserver addresses. Good luck -

2- Your Question: You write the guide for unbound 1.8.1-2. - My answer: I am testing using Dave's TEST BUILD of 10/25/2018 aka r8380 so that accounts for the difference in our packages. By the way r8373 is from 2018-10-22. Your question # 2 - Any reason I should be concerned about the mismatch? My answer # 2 - No.

3 - Your Question: However are there other dnsmasq options I should be concerned about? My answer Absolutely not - everything is fine. I state in the guide " DO NOT I REPEAT DO NOT do anything to the default /etc/config/dhcp file as in the old guide " .

4 - Your Question: Lastly, when it comes time to upgrade the davidc502 build again, I gather there is only a subset of your 14 steps that I need to repeat. Any comments on that upgrade process?

My answer: These upgrades are done upstream by NLnet Labs - the folks who bring us Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ).
See here: https://www.nlnetlabs.nl/ and here: https://www.nlnetlabs.nl/projects/getdns/
David Mora aka iamperson347 is package maintainer of GETDNS and STUBBY package for OpenWRT / LEDE. So, I can not predict the future. However, Davidc502, you me and all who use these packages are in the position of having to adapt the changes which come down from above. But do not worry, if there are any changes and a need to update these instructions - I will do my absolute best to apprise all of how to proceed forward.

Peace and God Bless,

directnupe

1 Like

directnupe,

I took five steps to add ipv6 capability to getdns-stubby-unbound. I'll list them here.

  1. Configure stubby with an additional listen address by modifying /etc/stubby/stubby.yml as shown:
listen_addresses:
  - 127.0.0.1@5453 #Stubby/Unbound#Default Address/Port
  - 0::1@5453
  1. Add a forward address to 0::1@5453 in /etc/unbound/unbound_ext.conf as shown:
forward-zone:
    name: "."    # Allow all DNS queries
    forward-addr: 127.0.0.1@5453
    forward-addr: 0::1@5453
  1. Add several ipv6 upstream recursive servers to /etc/stubby/stubby.yml, using as a reference the web link you gave plus the ipv4 servers you used:
  - address_data: 2a04:b900:0:100::37
    tls_port: 853
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
  - address_data: 2001:a18:1::29
    tls_auth_name: "kaitain.restena.lu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
  - address_data: 2001:610:1:40ba:145:100:185:17
    tls_port: 853
    tls_auth_name: "dnsovertls2.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
  - address_data: 2a03:b0c0:0:1010::e9a:3001
    tls_auth_name: "dot.securedns.eu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
  - address_data: 2001:470:1c:76d::53
    tls_port: 443
    tls_auth_name: "dns.cmrg.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5zFN3smRPuHIlM/8L+hANt99LW26T97RFHqHv90awjo=
  - address_data: 2001:19f0:7001:1ded:5400:01ff:fe90:945b
    tls_auth_name: "dns.jp.blahdns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: AoeARyI3TTLqCwrnDI1oPCWjvp2WXJ6Avhl/vF0ntGg=
  - address_data: 2a01:4f8:c0c:3c03::2
    tls_port: 853
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
  - address_data: 2a01:4f8:c0c:3bfc::2
    tls_port: 853
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=
  - address_data: 2a00:5884:8209::2
    tls_port: 443
    tls_auth_name: "dns.neutopia.org"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
  - address_data: 2001:913::8
    tls_auth_name: "ns0.ldn-fai.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
  1. Under Network -> Interfaces -> Edit Wan6 -> Advanced Settings use 0::1 (Local host) for DNS and remove check from “Use DNS servers advertised by peer”

  2. Restart unbound by executing /etc/init.d/unbound restart at the command line

After doing all the above, I found when going to http://www.testipv6.com/ that I had 10/10 for ipv6 stability and readiness, plus I could access ipv6-only sites, plus ipv6 would show up in the unbound cache as revealed by unbound-control dump_cache when executed at the command line.

So, it all works very well!

Dear slim0287,
You know that you really do an excellent job of getting things done in a swift, mindful and thorough fashion. Oh I have forgotten my manners, let me begin by saying "Hello my friend once again ". I am glad that you got IPV6 up and running. Maybe you will throw a quick tutorial up on the forum for this as several folks have asked me how to implement it, but as I told you earlier - I was not quite sure how to do it. If you do not have time or do not wish to do that ( write The DNS OVER TLS IPV6 TUTORIAL ) for whatever reasons; I will do it if you have no objections. It is that important in my estimation.
By the way, See here for GETDNS AND STUBBY on OPENWRT / LEDE:
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 .
Let me say that it is really a pleasure and productive to work with you on these topics. You are very knowledgeable, thorough precise and courteous - thank you for being you. Let me know about The DNS OVER TLS IPV6 TUTORIAL and I will speak with you soon.

Peace My Brother,

directnupe

1 Like

directnupe,
Thank you so much for the greetings and I return the same for you. I think my reply to your post is the tutorial for adding IPV6 functionality. I provided five additional steps which get IPV6 up and running.

While doing this work and reviewing the reference https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers it appears there are a few mistakes in the upstream recursive servers that you provide for the stubby.yml file. Here is a list:

  1. For 185.49.141.37, you give a tls_pubkey_pinset value of foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q= whereas the site provides one of foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9S=. Notice the second to last character is different (Q to S)
  2. For 146.185.167.43, 199.58.81.218, 89.234.186.112, and 80.67.188.188 you provide a tls_port of 443, whereas the site provides a tls_port of 853.

I was careful to look at the tls ports for the ipv4 addresses. Are these typos? In other words, should I correct all of them in my stubby.yml file?

Thanks
slim0287

Dear slim0287,
Hello once again. At the end of my replies to your questions here; I am going to ask you for a little assistance with something I am trying to get set up here on my end if it is all right with you.
On to your questions. First of all regarding the "getdnsapi.net" SPKI pin value - and SPKI pin values in general, I will explain this process here so that you can verify that you are assigning the correct key value as this is most important.
There is a sure fire method 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 108.61.201.119
OR
echo | openssl s_client -connect '108.61.201.119:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Now you can use either of these methods to manually obtain and verify the SPKI key for each and every upstream nameserver which you have chosen to use in your /etc/stubby/stubby.yml file.
You use the command line in SSH for these commands. So for getdnsapi.net Host - for example - you would enter:

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

and the readout outcome on the line below this entry is - foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
and that is the actual SPKI key being used at the current time for getdnsapi.net

If you use this method gnutls-cli --print-cert -p 853 185.49.141.37 ( in this case again for getdnsapi.net ) Look for this section near the top of the readout:

    Public Key PIN:
            pin-sha256:foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
    Public key's random art:

in this case the SPKI key is shown behind the pin-sha256: section.

You may see this result below at the end of readout using this method gnutls-cli --print-cert -p 853 185.49.141.37
-Status: The certificate is NOT trusted. The name in the certificate does not match the expected.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.

As far as I know, it can be ignored as this error reflects the fact that many of the DNS OVER TLS NAME SERVERS use Let's Encrypt Certificates. Let's Encrypt Certificates must be renewed every 90 days or so. So, I imagine that the DNS SERVER PROVIDERS do not always update the certificates on their end. However, even the main DNS OVER TLS NAME SERVER ( getdnsapi.net ) also prints out this error when using the gnutls-cli --print-cert -p 853 185.49.141.37 method. So, I assume that this must be secure as getdnsapi.net is part of NLnet Labs which is responsible for Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ).The only certificate that reads out as - Status: The certificate is trusted. is cloudflare-dns.com - So, if you are only comfortable with a trusted certificate you will be limited to only deploying Cloudflare, but they do log DNS queries. See here : https://www.cloudflare.com/privacypolicy/ - But if you are running a VPN then you should be safe from their snooping.

Also pay special attention to the top of the page in question : https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
where it clearly states these caveats:

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

So you can see why it is wise and beneficial for you to check and verify the SPKI yourself. By the way, in order to use gnutls-cli --print-cert -p 853 185.49.141.37 you must opkg install gnutls-utils - it is available in Dave's repos.

As for choosing to use port 443 entries read this from the first tutorial I wrote which is referenced above:
I have read here: https://www.monperrus.net/martin/randomization-encryption-dns-requests that also, it is good to set up some servers that listen 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.
Along with the main DNS Privacy Test Servers page ( where port 443 is listed for some of the servers I chose if you look closely ) you should also look at The Project dnsprivacy-monitoring page here: https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ for the real time actual status of all The DNS Privacy Test Servers including whether port 443 is available among all other available active features. On this page, which I strongly suggest you check from time to time because these services are experimental; the services sometimes have outages and then come back on line. This is why it is a good practice to keep an eye on this page as well.

Now for my question - can you please help me with setting up an OpenVpn client with IPV6 ( if it is doable and practical ) - you know firewall rules and so on. Any assistance you can provide will be most helpful and appreciated. Also how to configure UNBOUND with IPV6 when using OpenVpn client would be helpful as well. If you point me to any documentation on these topics I will be grateful.

Peace,

directnupe

PS- Not to be in any way offensive but you should read through the first tutorial which is linked at the top of this guide. The SPKI key issue I am going to put up on the first tutorial and this one as well. Thanks for bringing that to my attention as I am sure a great deal of folks may have questions about that as well. As an after thought:
As a matter of fact on the main page https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers for TLS Ports- dns.cmrg.net https://dns.cmrg.net/ lists 853 and 443 and ( 53053 for ipv6 ) - ns0.ldn-fai.net aka The Lorraine Data Network lists 443 and 853 - dns.neutopia.org http://dns.neutopia.org/ lists 443 and 853. The only only server I list which does not have port 443 listed is - dot.securedns.eu - however, if you look here : https://securedns.eu/ you will see that Alternative Port: 443 is listed in the upper right hand of its' homepage.
https://ldn-fai.net/serveur-dns-recursif-ouvert/ The Lorraine Data Network

1 Like

directnupe,

No offense taken at all. After all, I'm on this journey to learn this next step of networks and it helps to have a guide. Thank you again for your long and detailed writing both on SPKI and TLS Port. I used both gnutls-cli and openssl to find the SPKI for the various sites. I did find the 185.49.141.37 SPKI pin value was as you listed, however when I interrogated the 1.0.0.1 cloudflared, I found a SPKI pin value different than that in your stubby.yml file; in fact 1.0.0.1 returned the same SPKI that is given for 1.1.1.1. This is true also of the ipv6 version of 1.0.0.1, 2606:4700:4700::1001, as well. It returns the same SPKI pin value as 2606:4700:4700::1111. Given that cloudflare makes no guarantee as to this value, I guess it is not a surprise. I encourage you to look at it for yourself and see if I have that correct.

I would like to help you with setting up an OpenVPN client with IPV6 but I will say it has been so long since I have done so, and the reference I originally used to do so has changed (https://openwrt.org/docs/guide-user/services/vpn/openvpn/client). However, it was pretty straightforward as there is one tunnel and I have a single zone, which includes both the wan and wan6 interfaces, that goes through the tunnel. Do you have specific questions that I can interrogate my set-up with and answer for you?

Best regards,
slim0287

Hello I have problem with resolving Amazonaws link
With unbound with TLS enabled
Anyone have this problem?

Do you mean https://aws.amazon.com/? If so, I have no problem resolving it with the getdns-stubby-unbound setup that directnupe has described.

Dear slim0287,
Hello - I got some information for you regarding the SPKI keys. Look here:

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

directnupe,
Thanks. I notice that this kdig command supplies two SHA-256 PINs. In the message where I stated that you seemed to have the wrong PIN for 1.0.0.1, I see with this command that the #2 SHA-256 PIN is what we have in the subby.yml file for 1.0.0.1, whereas the #1 SHA-256 PIN is what we have in the stubby.yml file for 1.1.1.1 as well as the other upstream recursive servers. I think we need to use the PIN which has CN=server.name. So, you'll forgive me, but I need to ask the same question. Are we using the right SPKI key for 1.0.0.1? It seems we have the wrong one in the stubby.yml file.

Yes, you are right that the correct PIN is the one associated with the correct common name, CN=\*.cloudflare-dns.com, which also matches the stubby config tls_auth_name: "cloudflare-dns.com". The other SHA-256 is for another certificate in the hierarchy.

BTW, Cloudflare's own documentation explicitly mentions using SPKI, highlights the "cloudflare-dns.com" name presented by the cert, and gives an example with the correct SHA-256 PIN.

Dear slim0287,
Yes you were and are correct that value: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
for Clodflare - address_data: 1.0.0.1 is not correct. Forgive my error. However, I have eliminated CloudFlare from my upstream_recursive_servers: entries as I do not like their privacy policies and for that reason I now only use Tenta for my ### Anycast services ### Tenta's privacy policies are outstanding and you can read about the here: https://tenta.com/dns-setup-guides
As far as your question regarding DNSMASQ-FULL vs UNBOUND for DNS OVER TLS it depends on your preference. However, if you are already using DNSMASQ-FULL if I were you then I would not add redundancy to my setup and strictly and solely use DNSMASQ-FULL. As I said in the tutorial, you get DNSSEC authoritative DNS resolver and QNAME minimisation works as designed. So I see no added benefits for you in running UNBOUND ; however, I am by far no expert in networking routing and the like.

Peace,

directnupe

Directnupe,
Thanks. I moved to using DNSMASQ-FULL instead of unbound. I think this set up works better in the sense that it is a little speedier. I also understand your comment and concern associated with cloudflare and will do likewise.
Best,
slim0287

Hello. Thank you for your guides. I have a question though - performance wise, which is better dnsmasq-full + stubby or unbound + stubby + dnsmasq (for dhcp)?