DNS Privacy aka DNS OVER TLS For OpenWrt - UPDATED w/ Bonus Videos For Setup and Verification

This Is An Updated Guide - February 26, 2021
Dear Community,
As always - the intro - https://www.youtube.com/watch?v=6q_Fyv_znkw and lyrics
to sing along - https://genius.com/Sly-and-the-family-stone-stand-lyrics
Hello and I hope that all are both safe and well. Here I am going to write a new
tutorial for OpenWRT Snapshots. Some of you may remember my tutorial below :
( From The DNS Privacy Project ) DNS-OVER-TLS on OpenWrt/LEDE FEATURING UNBOUND GETDNS and STUBBY The main reason for this updated guide for implementing DNS-OVER-TLS on OpenWrt FEATURING UNBOUND GETDNS and STUBBY is due to Unbound 1.13.0-1. Eric Luehrsen - the maintainer for Unbound package on OpenWRT explains the issue here: Need Help With UNBOUND Setup on Snapshots - #30 by directnupe - Basically, in his words: As far as the PEM files, it seems Unbound has a defect with respect to the published behavior. They should be loaded before chroot. That is they are in (real root) /etc/unbound but somewhere in the mess unbound-control is trying /chroot.../etc/unbound. Enable unbound-control only localhost without encryption and it should work.

This guide was works on OpenWRT Snapshots, upcoming 21.02 and kernel versions 5.10 in other words this works with Unbound-daemon - 1.13.1-1 ( current version ).
As a Bonus - Videos detailing all of this are here DNSPRIVACY FOR ALL REDEUX The setup video illustrates and details how to install and configure unbound, stubby and getdns along with native dnsmasq to achieve DNS OVER TLS on OpenWRT. So let's get started. Just follow the steps and you can look at the videos as you read this set up guide. Here is the OpenWRT stubby page :https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
When running DNS OVER TLS ( my setup ) - I first had to stop and disable odhcpd This setup depends on DNS functionality. odhcpd conflicts with dnsmasq for dhcp hence also DOT.
The commands are as below :

/etc/init.d/odhcpd stop 
/etc/init.d/odhcpd disable
Step # 1 -  opkg update && opkg install wget nano ca-bundle 
ca-certificates  ( these are prerequisites - especially ca-bundle )
Step # 2 - opkg update ; opkg install unbound-daemon unbound-control 
unbound-control-setup luci-app-unbound unbound-anchor 
unbound-host stubby getdns unbound-checkconf   
( this installs unbound and stubby dependencies )
Step # 3 - By default, configuration of stubby is integrated 
with the OpenWRT UCI system using the file /etc/config/stubby. 
We wish to configure stubby using the /etc/stubby/stubby.yml file. 
We need to set option manual '1' in /etc/config/stubby and 
all other settings in /etc/config/stubby will be ignored. 
See below for correct entry ( nano /etc/config/stubby ):

config stubby 'global'
       option manual '1'
Step # 4 - Configure stubby.yml - enter nano /etc/stubby/stubby.yml 
see how below : Please use as many or as few upstream servers 
as you deem necessary or desired for our needs.I have shown file 
to use both IPV4 and IPV6 servers. All servers support TLSv1.3 protocol.
Pick those closet to you geographically and so forth.

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: 10000
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_connection_retries: 5
tls_backoff_time: 300
timeout: 1000
limit_outstanding_queries: 100
tls_ca_file: "/etc/ssl/certs/ca-certificates.crt"
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 Servers #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=
## xx - The The Surfnet/Sinodun DNS TLS Server  A ( NLD )
  - address_data: 145.100.185.15
    tls_auth_name: "dnsovertls.sinodun.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
## xx - The The Surfnet/Sinodun DNS TLS Server #1  A ( NLD )
  - address_data: 145.100.185.16
    tls_auth_name: "dnsovertls1.sinodun.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
## 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: G69vD32lVULKRAA1Mey0aY5HqCtixfcFj6d7YfZXcXQ=
## xx - The BlahDNS German DNS TLS Server  A+ ( USA Hosted In DEU )
  - address_data: 78.46.244.143
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: MYAdUawDyym0aCys3RM7wjnGt6/VPkXRSnUynBVCZ0M=
## xx - 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=
## xx - The BlahDNS Singapore DNS TLS Server  A+ ( SGP )
  - address_data: 139.180.141.57
    tls_auth_name: "dot-sg.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: iENlCR6FD7l71PESwzzBUGVgJ5MtJykG2F1fV1RyV4A=
## xx - The BlahDNS Switzerland DNS TLS Server  A+ ( CHE )
  - address_data: 45.90.57.121
    tls_auth_name: "dot-ch.blahdns.com"
    tls_port: 4443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 0i6NHVbpWtZUAxlyKkIPo3xwYQPdwcDYMmZmOvQSBd8=
## 5 - 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=
## 6 - The Foundation for Applied Privacy DNS TLS Server #1  A+ ( AUT )
  - address_data: 146.255.56.98
    tls_auth_name: "dot1.applied-privacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wi251KSU9HwFOjL3cgG+vxxyrQl0FyP5aBkBcqs4dow=
## 7 - 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: l58wGW4rA4vpqbwyQkBK+TC8nWT7ESkMnn1aG3ehbFc=
## 8 - The dismail.de DNS TLS Server #1  A+ ( DEU )
  - address_data: 80.241.218.68
    tls_port: 853
    tls_auth_name: "fdns1.dismail.de"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU=
## xx - The dismail.de DNS TLS Server #2  A+ ( USA )
  - address_data: 159.69.114.157
    tls_port: 853
    tls_auth_name: "fdns2.dismail.de"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w=
## 9 - 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/
## 10 - The ibksturm.synology.me DNS TLS Server  A+ ( CHE )
  - address_data: 89.217.74.236
    tls_auth_name: "ibksturm.synology.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: ST64ZkZeik0+6/e9gCs+dGB5r4lEMWcgxg58eBhQGDY=
## 11 - 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: bCliMm8V6PPPhy3qOG45fkJhqJZ/H7HQH3GF3RHP2sg=
### Publicly Available DOT Test Servers ###
## 12 - 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: 0fDCu9NeTLXKniGX7Hqjq4PLqXV7kvxv04lAWs/dOHY=
## 13 - 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: TP3QdfiIGmReSKJ3XW+T+yQ+xy5KMNtcTt6TJ+MMynI=
## 14 - 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: ynHdh6Gn21nGQDVYEz0eYp8rktzwbAmSJgncIEk4yTI=
## xx - 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: 3sSy32B+XnIOKckcW9vT06D0+XUgW3CSno+p1k3vp9Y=
## 15 - 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=
## xx - 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: y8hXAlkRxglOPlYivo/S/E1EfNFoU9f/Uf4dQcXiHhg=
## 16 - 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: A0Te9x7eWRcFvhbIVMSuJJV6tr4ABUnGEKBm+FyaknQ=
## xx - 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: XToXSSeTAIsKEZ4+KjhlWla0LtOFwI90J5nnOAY6dcE=
## 17 - 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: s2bFv4zDfIc+7wIMA59QTImqx9uzko6TQVfXAz8JLto=
## 18 - 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: UV439TTY3wPh+k2bKJmvHrU3gcz4bDYd6S0poXN7bZU=
## xx - 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: YhPROg0ogwGqlsQAehkkxQk8lMUNUVJiR04c/rO2Pdo=
## 19 - The ibuki.cgnat.net DNS TLS Server  A+ ( USA )
  - address_data: 168.138.243.216
    tls_auth_name: "ibuki.cgnat.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: UVKs87p2i+i+6cTOsfmZWHpononMhaZ1/TaOUCCdEYA=
## 20 - The AhaDNS.com Netherlands DNS TLS Server  A+ ( NLD )
  - address_data: 5.2.75.75
  - address_data: 2a04:52c0:101:75::75
    tls_auth_name: "dot.nl.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vhyny5bRLcdUo8nT8yYPU3Ba3n59tw/p9ZdM7CdB7XA=
## xx - The AhaDNS.com India DNS TLS Server  A+ ( IND )
  - address_data: 45.79.120.233
    tls_auth_name: "dot.in.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: I2d/sF4W9UzEJDacfEioGpjzfdKfA9vScD27fL+X7y4=
## xx - The AhaDNS.com Los Angeles DNS TLS Server  A+ ( USA )
  - address_data: 45.67.219.208
  - address_data: 2a04:bdc7:100:70::70
    tls_auth_name: "dot.la.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: I8+ilcgZbzlDJibVX+ao3N4CaN71oi/67kARvAvkF68=
## xx - The AhaDNS.com New York DNS TLS Server  A+ ( USA )
  - address_data: 185.213.26.187
    tls_auth_name: "dot.ny.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: KFnD8W9moK59GXrouEF2PRnD3TI5dwNerLGz2fVGUg4=
## xx - The AhaDNS.com Poland DNS TLS Server  A+ ( IND )
  - address_data: 45.132.75.16
  - address_data: 2a0e:dc0:7:d::d
    tls_auth_name: "dot.pl.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: k+2Qzo5pl+70VXixFeBNRswWwdwAu/hC6gNdFytr2Bw=
## xx - The AhaDNS.com Italy DNS TLS Server  A+ ( IND )
  - address_data: 45.91.95.12
  - address_data: 2a0e:dc0:8:12::12
    tls_auth_name: "dot.it.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: XOAIkTcSr/sm3w8JalaSP9apN7visaVWJ7Ak6SnwFBg=
## xx - The AhaDNS.com Spain DNS TLS Server  A+ ( IND )
  - address_data: 45.132.74.167
  - address_data: 2a0e:dc0:9:17::17
    tls_auth_name: "dot.es.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: MfhmtxPms+ZsB7v5iLdmGgoIYCDkxs55DTiY1p/+OcU=
## xx - The AhaDNS.com Norway DNS TLS Server  A+ ( IND )
  - address_data: 185.175.56.133
  - address_data: 2a0d:5600:30:28::28
    tls_auth_name: "dot.no.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P++7ZdWm1d+diD5Qt9PV7SFQDCrZK/jH8mo9G1xF8nc=
## xx - The AhaDNS.com Chicago DNS TLS Server  A+ ( IND )
  - address_data: 193.29.62.196
  - address_data: 2605:4840:3:c4::c4
    tls_auth_name: "dot.chi.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: UF0rIyP2tkD8NG4FEZ/NDFu16vkXVNV4Jg4yml5oRfk=
## xx - The AhaDNS.com Australia DNS TLS Server  A+ ( IND )
  - address_data: 103.73.64.132
  - address_data: 2406:ef80:100:11::11
    tls_auth_name: "dot.au.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WULSbPGl4Jckg99ATU12Hp+aVdLz5H3ltu9g5cBU9q4=
## 21 - 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: PNeoThB4S+lf+p/ZkXZZqjWmUn13lu809xuDgBZ+xp8=
## 22 - 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: Cv0Ap5Pf5+ZP0JxsBIm5xsnNmIK0YameM8QDWg4VKR0=
## 23 - 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: sYtspi4dALWTVbMppLGpjFDQvCEZeuabtXyoGo/Q3ng=
## 24 - 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=
## xx - 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=
## 25 - The Freifunk München DNS TLS Server  A+ ( DEU )
  - address_data: 5.1.66.255
    tls_auth_name: "doh.ffmuc.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: BkjoiHvX67yHa/G2NNPi5G4WAN5Wh3fjIO3CRPqPYJA=
  - address_data: 185.150.99.255
    tls_auth_name: "doh.ffmuc.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P77Y2o4+q8v3l8Qq7M8fre0S0buvRG5gYKhM94YJEHU=
## 26 - 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=
## 27 - 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=
## 28 - 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=
## 29 - The Stéphane Bortzmeyer DNS TLS Server A+ ( FRA )
  - address_data: 193.70.85.11
    tls_auth_name: "dot.bortzmeyer.fr"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY=
## 30 - The LibreDNS DNS TLS Server #1  A+ ( IND )
  - address_data: 116.202.176.26
    tls_auth_name: "dot.libredns.gr"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
## xx - The LibreDNS DNS TLS Server #2  A+ ( IND )
  - address_data: 116.202.176.26
    tls_auth_name: "dot.libredns.gr"
    tls_port: 854
    tls_pubkey_pinset:
      - digest: "sha256"
        value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
## 31 - The LavaDNS-US-1 DNS TLS Server  A+ ( USA )
  - address_data: 79.110.170.43
    tls_auth_name: "us1.dns.lavate.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: W0y9+3Qy77HrkCYLNSg0oY2J7aIqwC5GbPEP6pBTfws=
## xx - The LavaDNS-EU-1 DNS TLS Server  A+ ( FIN )
  - address_data: 95.217.25.217
    tls_auth_name: "eu1.dns.lavate.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WSQmsUvZJRZ5EcIyZdtqt1UsB1KEeAX8+cFy/v7AiCk=
## 32 - The yepdns.com DNS TLS Server #1  A+ ( USA )
  - address_data: 94.237.68.80
    tls_port: 853
    tls_auth_name: "sg.yepdns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: m+Gh4LlejsfHgD3yOg4QIUc2VcfP9ukrq7AR0WQd7q0=
## 33 - The Faelix DNS TLS Server #1  A+ ( LTU )
  - address_data: 185.134.196.54
    tls_auth_name: "rdns.faelix.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g=
## xx - The Faelix DNS TLS Server #2  A+ ( LTU )
  - address_data: 185.134.196.55
    tls_auth_name: "rdns.faelix.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g=
## xx - The Faelix DNS TLS Server #3  A+ ( LTU )
  - address_data: 46.227.200.55
    tls_auth_name: "rdns.faelix.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g=
## xx - The Faelix DNS TLS Server #4  A+ ( LTU )
  - address_data: 46.227.200.54
    tls_auth_name: "rdns.faelix.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: OcCIDQdRSeK9hcmmdj1Rr3/Ma7cZ75l+nRYQMtPJz+g=
## 34 - The Arapurayil's DNS TLS Server #1  A+ ( USA )
  - address_data: 3.7.176.123
    tls_port: 853
    tls_auth_name: "dns.arapurayil.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: fod+JGyXcnJBDOrt1Iq14abGcxgNjh2zFVOO8saHnBM=
## 35 - The Brahma World DNS TLS Server  A+ ( USA )
  - address_data: 94.237.80.211
    tls_port: 853
    tls_auth_name: "dns.brahma.world"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: gJR4ekQiIPT5+ug7Rzxr+9O9sKLkTgKS8Lam5EXncEU=
## 36 - The Uncensored DNS TLS Server #1  A+ ( DNK )
  - address_data: 91.239.100.100
    tls_auth_name: "anycast.censurfridns.dk"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 6eW98h0+xxuaGQkgNalEU5e/hbgKyUoydpPMY6xcKyY=
## xx - The Uncensored DNS TLS Server #2  A+ ( DNK )
  - address_data: 89.233.43.71
    tls_auth_name: "unicast.censurfridns.dk"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: INSZEZpDoWKiavosV2/xVT8O83vk/RRwS+LTiL+IpHs=
## 37 - The Digitalcourage e.V. DNS TLS Server  A+ ( DEU )
  - address_data: 46.182.19.48
    tls_auth_name: "dns2.digitalcourage.de"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: v7rm6OtQQD3x/wbsdHDZjiDg+utMZvnoX3jq3Vi8tGU=
## 38 - The Usable Privacy DNS DNS TLS Server A+ ( CHE )
  - address_data: 149.154.153.153
    tls_auth_name: "adfree.usableprivacy.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: SQjhS4EtweDmR5+NMLGMVXxYP8ZwGVa1YDSoM8N5wiU=
## 39 - 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=
  - address_data: 185.26.126.14
    tls_auth_name: "dns.hostux.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE=
## 40 - The dns.therifleman.name DNS TLS Servers  A+ ( USA )
  - address_data: 172.104.206.174
    tls_auth_name: "dns.therifleman.name"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: mZJECUWOKQW4SAvZSgM3LRalJQDUCxtImKW0KO/+ijU=
### Anycast Publicly Available DOT Test Servers ###
## 41 - The DNSlify DNS TLS Servers  A+ ( Anycast )
  - address_data: 185.235.81.1
    tls_auth_name: "a.ns.dnslify.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: QZKcLeM+e5+3DYMrpNYv/iRMtNbRtvN8dCmWbBZFT68=
  - address_data: 185.235.81.2
    tls_auth_name: "b.ns.dnslify.com"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: QZKcLeM+e5+3DYMrpNYv/iRMtNbRtvN8dCmWbBZFT68=
### DNS Privacy Anycast DOT Public Resolvers ###
## 42 - 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=
####### Servers that listen on port 443 (IPv4 and IPv6) #######
### Test servers ###
## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD )
  - address_data: 2a04:b900:0:100::38
    tls_auth_name: "getdnsapi.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## xx - The The Surfnet/Sinodun DNS TLS Server #1  A ( NLD )
  - address_data: 2001:610:1:40ba:145:100:185:16
    tls_auth_name: "dnsovertls1.sinodun.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
  - address_data: 2001:610:1:40ba:145:100:185:18
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## 2 - The Foundation for Applied Privacy DNS TLS Server #1  A+ ( AUT )
  - address_data: 2a02:1b8:10:234::2
    tls_auth_name: "dot1.applied-privacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wi251KSU9HwFOjL3cgG+vxxyrQl0FyP5aBkBcqs4dow=
## 3 - The AhaDNS.com New York DNS TLS Server  A+ ( USA )
  - address_data: 2a0d:5600:33:3::3
    tls_auth_name: "dot.ny.ahadns.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: KFnD8W9moK59GXrouEF2PRnD3TI5dwNerLGz2fVGUg4=

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

Step # 5 - This step tells Stubby to forward all  DNS requests to Unbound :

cat >> /etc/unbound/unbound_ext.conf <<UNBOUND_FORWARD_CONF
server:
do-not-query-localhost: no
forward-zone:
 name: "."   # Allow all DNS queries
 forward-addr: 127.0.0.1@5453
 forward-addr: 0::1@5453
UNBOUND_FORWARD_CONF
Step # 6 - Now, you just need to move the existing dnsmasq server aside, so 
Unbound can answer your devices DNS queries.  Issue commands (a) through (g) as detailed below :

# Move dnsmasq to port 53535 where it will still serve local DNS from DHCP
# Network -> DHCP & DNS -> Advanced Settings -> DNS server port to 53535
( a ) 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.
( b ) uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)"
( c ) uci set 'unbound.@unbound[0].dhcp_link=dnsmasq'

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

# Restart (or start) unbound (System -> Startup -> unbound -> Restart)
( e ) /etc/init.d/unbound enable 
( f ) /etc/init.d/unbound start
( g ) /etc/init.d/unbound restart
Step # 7 - Set dnsmasq to send DNS requests to stubby

Since dnsmasq now responds to LAN DNS requests on port 53535 of the OpenWRT device, 
all that is required is to have dnsmasq forward those requests to stubby which is listening on port 
5453 of the OpenWRT device. To achieve this, we need to set the server option in the dnsmasq 
configuration in the /etc/config/dhcp file to '127.0.0.1#5453'. We also need to tell dnsmasq not 
to use resolvers found in /etc/resolv.conf by setting the dnsmasq option noresolv to 1 in the same file. 
This can be achieved by editing the /etc/config/dhcp file directly or executing the following 
commands - ( a ) - ( e ) at the command line:

( a ) - uci add_list dhcp.@dnsmasq[-1].server='/pool.ntp.org/129.6.15.30'
( b ) - uci add_list dhcp.@dnsmasq[-1].server='127.0.0.1#5453'
( c ) - uci add_list dhcp.@dnsmasq[-1].server='0::1#5453'
( d ) - uci set dhcp.@dnsmasq[-1].noresolv=1
( e ) - uci commit && reload_config
Step # 8 - Disable sending DNS requests to ISP provided DNS servers

( a ) - uci set network.wan.peerdns='0'
( b ) - uci set network.wan.dns='127.0.0.1'
( c ) - uci set network.wan6.peerdns='0'
( d ) - uci set network.wan6.dns='0::1'
( e ) - uci commit && reload_config
Step # 9 - Shrink Dnsmasq cache as we use Unbound and increase forwards
Issue commands ( a ) - ( c ) below :

( a ) - uci set dhcp.@dnsmasq[0].cachesize=50
( b ) - uci set dhcp.@dnsmasq[0].dnsforwardmax=250
( c ) - uci commit dhcp && reload_config
Step # 10 - ( Optional ) - Edit Startup Services

nano /etc/rc.local  - and enter the following below :

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

/usr/sbin/ntpd -n -q -N -p 129.6.15.30

# Wait until Internet connection is available
for i in {1..60}; do ping -c1 -W1 185.49.141.37 &> /dev/null && break; done

# Restart DNS Privacy Daemon - Stubby as it requires a successful
#time sync for its encryption to work/
/etc/init.d/network restart
/etc/init.d/firewall restart
/etc/init.d/unbound restart
/etc/init.d/stubby restart

/usr/sbin/ntpd -n -q -N -p 129.6.15.30 

exit 0
Step # 11 - Configure Unbound via configuration file - replace contents of 
file with the following - see below :  nano /etc/config/unbound 

config unbound 'ub_main'
        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 'mydomain.com'  ## enter your actual domain here
        option domain_type 'transparent'
        option edns_size '1232'
        option extended_stats '1'
        option hide_binddata '1'
        option interface_auto '1'
        option extended_luci '1'
        option luci_expanded '1'
        option listen_port '53'
        option localservice '1'
        option manual_conf '0'
        option num_threads '2'
        option protocol 'mixed'
        option query_minimize '1'
        option query_min_strict '1'
        option rate_limit '0'
        option rebind_localhost '0'
        option rebind_protection '1'
        option recursion 'aggressive'
        option resource 'medium'
        option root_age '9'
        option ttl_min '120'
        option unbound_control '1'
        option validator '1'
        option validator_ntp '1'
        option verbosity '1'
        list trigger_interface 'lan'
        list trigger_interface 'wan'
        option query_minimize '1'
        list domain_insecure '3.us.pool.ntp.org'
        list domain_insecure 'mydomain.com'  ## enter your actual domain here
        option dhcp_link 'dnsmasq'
Step # 12 - Manually edit /etc/config/dhcp -  go into nano /etc/config/dhcp 
and do the following below :

A - ## --- Make sure you disable (apply "#" in front) this entry to ignore ISP's supplied DNS
done by doing as detailed directly below:

#       option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'

B - ## --- Your router date & time must be correct in order to have successful tls initiation
done by doing as detailed directly below:	

list server '/pool.ntp.org/129.6.15.30'	( Make sure this entry was added in Step # 7 via uci )
Step # 13 - Check your Unbound Configuration -
 enter command # unbound-checkconf 
 
Checks unbound config file syntax and other errors.
Step # 14 - Setup Unbound Files For Unbound Control - 
enter command # unbound-control-setup

Generates self-signed certification and private keys for both server and client.
Step # 15 - Enable and Update DNSSEC - 
enter command  # unbound-anchor -a "/etc/unbound/root.key"
	
Performs the configuration or update of the root trust anchor for DNSSEC validation.
Step # 16 - Reboot your router 

Step # 17 - Go to https://browserleaks.com/dns - and you will see that you are now
You are now running DNS OVER TLS with GETDNS plus STUBBY
( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.

Now all you need to do is run is a properly configured VPN Service.
By doing so, running DNS over TLS with Stubby and GetDns will keep
your VPN provider from spying on your encrypted DNS look ups - and
also your DNS providers both the ISP ( replaced by encrypted Stubby )
and your Encrypted TLS DNS Service Provider will see your IP as the
one from your encrypted tunneled VPN provider.

8 Likes

Copy and paste to wiki?

1 Like

Dear Doppel-D,
Hello and I hope that you are both safe and well. Regarding your question :

Copy and paste to wiki?

I do not know if you are asking me for permission to do that - or if you are asking me to copy and paste this tutorial to the wiki. I believe that one of my tutorials was posted on the wiki years ago. Frankly, I do not remember if I did that or if it was a moderator - I do not remember exactly how it wound up there. I do not know if I am authorized to post content on the wiki. So, if you let me know what is the proper procedure ( s ) to get this up on the wiki - and I certainly am willing to allow this setup to post on the wiki in order to benefit any and all in the greater OpenWRT Community that wish to deploy this setup on their devices.
Peace

1 Like

Hello directnupe,
thank you for your best wishes, same to you!

Regarding the wiki contribution: I am generally interested in the the subject but actually not in a mood for trying / implementing. So if I would write a Wiki entry I would least liked to try it first on my own ;- )

Also after reading wikirules there seem to be some work to be done to get your article in the right shape....but I suggest the following:

I will try if my wiki credentials are working and if so I will put an link on the DoT Wiki entry to your post so more people can give it a try and help to prepare for a "How to".
Kind regards, Eric

Addendum: Changed link

1 Like

Dear Doppel-D,
You are the man. Thanks for the update regarding rules and clarification concerning your position related to the Wiki matter which we were discussing. I see your progress related to your intention stated here:

I will try if my wiki credentials are working and if so I will put 
an link to the unbound section to your post so more 
people can give it a try and help to prepare for a "How to"

I see that you achieved the goal of having this as a WIP link in the Unbound Section on the Wiki - thanks for that. You are gentleman and I appreciate all that you do to help advance the overall development of OpenWRT for us all.
Peace

Thanks, but I have done not much, perhaps not even well ;- ) You have done all the effort to make it work and already put it in a HowTo! Lets see if it's helpfull to others.

1 Like

Kudos for documenting your efforts and creating the guide!

I'm curious what was the reason to go thru all the troubles above for DoT rather than installing https-dns-proxy (and optionally the luci app which comes pre-configured for a large number of supported providets) which uses DoH and does the work of automatically reconfiguring everything else for you?

2 Likes

Dear Stangri,
Hello and I hope that you are safe and well. I have appreciated your work for quite some time. If you read through the original guide here : DNS OVER TLS I wrote up about all of DOT - you can read through all the documentation referenced there along with my own personal rationale for going to lengths I do to ensure DNS Privacy I am retired ( have time on my hands ) and once you get this methodology down - it takes about 6 - 10 minutes to setup - if that - Especially Read the Article DNS Security: Threat Modeling DNSSEC, DoT, and DoH
by Jan Schaumann

1 Like

Dear Community,
I am being constantly asked why did I go through all the trouble of setting up
this " so called elaborate " configuration of a DNS solution - namely DNS
OVER TLS ( DOT ). Among the many contributors to this project are Sinodun IT,
NLnet Labs, SalesForce, Surftnet, NLnet Foundation, OTF, Stephane Bortzmeyer
and No Mountain Software. The answers ( s ) are rattled off below :

Unbound - Unbound
Stichting NLnet Labs
Science Park 400, 1098 XH Amsterdam, The Netherlands

To help increase online privacy, Unbound supports DNS-over-TLS and 
DNS-over-HTTPS which allows clients to encrypt their communication. 
In addition, it supports various modern standards that limit the amount 
of data exchanged with authoritative servers. These standards do 
not only improve privacy but also help making the DNS more 
robust. The most important are Query Name Minimisation, the 
Aggressive Use of DNSSEC-Validated Cache and support for 
authority zones, which can be used to load a copy of the root zone.

Stubby - Stubby

About Stubby
'Stubby' is an application that acts as a local DNS Privacy 
stub resolver (using DNS-over-TLS). Stubby encrypts DNS 
queries sent from a client machine (desktop or laptop) to a DNS
Privacy resolver increasing end user privacy. Stubby is developed 
by the getdns project, has it's own github repo and issue tracker 
but dnsprivacy.org currently hosts the online documentation for Stubby 

.

Welcome to the DNS Privacy project home page
DNS Privacy Project

This site is the home of a collaborative open project 
to promote, implement and deploy DNS Privacy. The 
goals of this project include:Raising awareness of the 
issue of DNS Privacy. Empowering users to take 
advantage of DNS Privacy tools and resources 
(client applications, DNS Privacy resolvers)
Evolving the DNS to support DNS Privacy in particular 
developing new DNS Protocol standards
Working towards full support for DNS Privacy in a range of 
Open Source DNS implementations including: getdns, 
Unbound, NSD, BIND and Knot (Auth and Resolver)
Co-ordinating deployment of DNS Privacy services and 
documenting operational practices

getdns - getdns

getdns is a modern asynchronous DNS API. It implements 
DNS entry points from a design developed and vetted by 
application developers, in an API specification. The open source 
C implementation of getdns is developed and maintained in collaboration 
by NLnet Labs, Sinodun and No Mountain Software. This 
implementation is licensed under the New BSD License.

So - Stichting NLnet Labs develops and maintains Unbound, getdns and Stubby.
This company sets the industry's " Gold Standard ". I use pfSense and Opnsense -
I am used to Unbound. I used to run dnscrypt years ago - but then I upped my
game and moved on DNS OVER TLS - DOT. Plain and simple. Once again - anyone with questions about the various DNS solutions available today should read : DNS Security: Threat Modeling DNSSEC, DoT, and DoH along with my original tutorial on this topic written a while back. And by all means go with your own preference.

I hope this puts this issue to rest. Again, this takes 6 to 10 ten minutes to set up.
Plus I have given any and all videos to follow. These standards and products are
reviewed, standardized, continually developed and constantly improved.
Peace and God Bless - Stay Safe

3 Likes

FYI: Recent press announcement from Quad9, configuration options

1 Like

Hi directnupe,
I see that you have at least 4 guides now for DNS over TLS. Thank you for your continued effort on this subject.

While this may be the most recent and up-to-date guide in terms of software releases and configuration syntax, I am wondering about some things that seem to have been reverted since a previous guide:
https://forum.openwrt.org/t/fresh-new-and-improved-getdns-stubby-and-unbound-aka-dns-privacy/55502/1

In that guide, it is recommended to disable root hints, to disable using 127.0.0.1 as a resolver, and to require minimum TLSv1.3.

I see now in this guide 127.0.0.1 and TLSv1.2 are back. Is there a particular reason for this?

Also, what is the purpose of installing odhcpd in step 2? Is it replacing dnsmasq as our ipv4 DHCP server? Step 2 here seems to imply that we are still using dnsmasq for DHCP, but I can't be sure. I'm just wondering since I have all of my static leases set up in /etc/config/dhcp and I wasn't sure if installing odhcpd on top of dnsmasq would mess with that.

Lastly, in your original guide that you linked in the first post:
https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765/1
You give the option of using drill and/or dig to do some additional CLI testing. Are these still applicable and can they be used after completing this guide? I will also use the website tests that you have linked in the guides, but I want to be sure that the results on those sites are not related to any browser enhancements/addons and that embedded and IoT devices that do not have a way to test through a browser are fully protected through DoT and DNSSEC.

Thanks,
~Chainu

2 Likes

Dear chainu127,
Hello and I hope that you are both safe and well. Please forgive me for not getting back to you in the most timeliest of fashions.I will do my best to answer your questions albeit I am no expert. First your comment :

I see that you have at least 4 guides now for DNS over TLS

Well - simply put - there is more than one way to fry chicken. Meaning there are different means to achieve a goal - in this case DNS OVER TLS on OpenWRT. Your next question :

In that guide, it is recommended to disable root hints, to 
disable using 127.0.0.1 as a resolver, and to require minimum TLSv1.3.
I see now in this guide 127.0.0.1 and TLSv1.2 are back. 
Is there a particular reason for this?

I wrote the guide you refer to where you use Lan instead of local host based on this advice here from the pfSense forum ( as I use both pfSense and OPNsense on a mini pc I own and run ) see below:

So, I just went back to using 127.0.0.1 as a resolver - and I started using some upstream resolvers in
stubby.yml which only support TLSv1.2 on port 443 - specifically :

dnsovertls.sinodun.com
dnsovertls1.sinodun.com
Also, what is the purpose of installing odhcpd in step 2?

Now as I said earlier, I am no expert - so perhaps this package - odhcpd should be removed. I am willing to learn and if I have made an error here - I will correct the guide to reflect the proper method.

You give the option of using drill and/or dig to 
do some additional CLI testing. Are these still 
applicable and can they be used after completing this guide?

Yes - you can and should still use those methods from time to time. For SPKI keys and dates of issue and expiration - see below :

Most Simple and Direct Method:

gnutls-cli --print-cert -p 853 9.9.9.9 | grep "pin-sha256" | head -1

gnutls-cli --print-cert -p 443 146.255.56.98 | grep "pin-sha256" | head -1

kdig -d @45.77.180.10 +tls-ca +tls-host=dns.containerpi.com containerpi.com

kdig -d @108.61.201.119 -p 443 +tls-ca +tls-host=dot-jp.blahdns.com blahdns.com

Test for TLS version on remote server :

openssl s_client -connect 185.49.141.37:853 

openssl s_client -connect 145.100.185.15:443

or

openssl s_client -connect getdnsapi.net:853 

openssl s_client -connect dnsovertls.sinodun.com:443
I will also use the website tests that you have linked in the guides, 
but I want to be sure that the results on those sites are not related 
to any browser enhancements/addons and that embedded and 
IoT devices that do not have a way to test through a browser 
are fully protected through DoT and DNSSEC

The website in question : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 - tests the remote server ONLY - nothing else or anything you mention in your question
Hope some of helps. - and get back to me about odhcpd - most of the builds I use come with odhcpd already installed. Towards answering your questions / observation around this issue - I am going to disable odhcpd while setting up Hannu Nyman aka hnyman's Test-DSA-kernel 5.10 210314 on my R7800. I will let you know how that works out as I have been having a few DNS issues with all Test-DSA-kernel 5.10 Builds on R7800 - not just hnyman's.

Yes chainu127 - you were absolutely correct. I found out why adblock and banip were not working for me. When running DNS OVER TLS ( my setup ) - I had to stop and disable odhcpd These packages depended on DNS functionality. So I will amend the tutorial to reflect this finding.
The commands are as below :

/etc/init.d/odhcpd stop 
/etc/init.d/odhcpd disable

Thanks for alerting me to my error.

I have a Linksys WRT 1200ac, thank you directnupe for this guide. Everything works as it should, Previously I had an LTE HILINK 3372, then I also used your guide Now I have fiber 600/100. I think it is the best solution for privet DNS. .

Thanks,
Pitu

1 Like

Dear pitu,
Thanks for appreciating my efforts and I am pleased that the DNSPRIVACY solution is working so well for you. God Bless you and stay safe and well.
Peace

@directnupe - cheers for all the stuff you do here. Greatly appreciated. I have found thought, through my own trial and error that odhcpd/Unbound without stubby is way quicker; esp. on the 1st resolve of a site not in cache and is just as secure. The only thing I find it can fail on is the RPKI test on https://cmdns.dev.dns-oarc.net/ which would intermittently fail on me too with stubby if no browser cache cleared (it was always successful on a fresh cache clear, but then qname minimisation would regularly fail on there edit with STUBBY).

I do keep dnsmasq in the loop but purely for ipset only (DSCP marking...SQM guide on here) -DNSMASQ does nothing but get the port 53 requests to build my ipsets and then hands everything off to Unbound for Secure DNS. Using the full, latest unbound.conf example of gitlab [no luci config]...if you want a copy of the configs to see if its any quicker, same/more/less secure, give me a shout as I would like to find out from someone with experience in the area. May also work with the 21.x variants of OpenWRT (not ventured there). 19.07 does the /var/lib/unbound/etc/unbound/xxx.crt/pem thing too so have all my workaround in there for it.

Keep up the good work anyways!

  • Edit 2 - Worked out the RPKI thing...had 2 Sinodun servers without the port reference and could see my DNS was using it a lot on a tcpdump. Plugged in the port and all 100%
1 Like

Thanks @directnupe, but from a fresh reset I cannot get past 6d in this guide. As soon as I try and restart unbound it fails to start. If I try to push ahead and complete the rest of the configuration I am unable to get internet connection again.
I have tried implementing DDNS first as stated as a requirement in other guides, but that seems to make no difference, even when I follow this guide exact to the letter.
I have really enjoyed using your configuration before, but regret that I can no longer find anything that works. Hope you might be able to advise. Stay safe.. rgs AGS13

Dear AGS13,
I have amended this tutorial by changing Step # 6 see below :

# Restart (or start) unbound (System -> Startup -> unbound -> Restart)
( e ) /etc/init.d/unbound enable 
( f ) /etc/init.d/unbound start
( g ) /etc/init.d/unbound restart

If you had looked at the videos and followed along - implementing each step - as you go through the setup video - you would have seen that these are the steps I actually use in my setup. Also - as an alternative - before you begin - and after installing all unbound and getdns packages - try this below :

First go into unbound configuration -   nano /etc/config/unbound 
and make this change and this change ALONE aka ONLY

        option unbound_control '1'

That is make sure unbound control is set to '1' in
nano /etc/config/unbound
After doing this step - which enables unbound ( unencrypted ) just follow the tutorial starting with

/etc/init.d/odhcpd stop 
/etc/init.d/odhcpd disable

which is right above Step 1 - hope this helps - however, do look at the videos - especially the SETUP video - Peace

Not sure if it was your extra steps that did it or if it was the way I was originally implementing ddns. Anyhow I have had nearly a month of internet working the way I have want - trouble free. That is a record for me so thank you diretnupe

1 Like

Dear AGS13,
I hope that you are both safe and well. Glad to hear that DOT on OpenWRT is up and running for you as you like it. This was my pleasure for you and all who value DNSPRIVACY.
Peace and God Bless to You and Yours Always -