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
You may also choose to use DNS OVER TLS with DNSMASQ. However, that is not the focus of this tutorial.

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 .
See Here For OPENWRT STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING
https://torguard.net/forums/index.php?/topic/1455-openwrt-stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/
Stubby dns over tls using dnsmasq-full for dnssec & caching

There have been some changes to DNS OVER TLS From The DNS Privacy Project. Here is how this up and running. Much remains the same but be aware of the changes from the original guides which I will point out to you along the way. Original posts here: ( From The DNS Privacy Project ) DNS-OVER-TLS on OpenWrt/LEDE FEATURING UNBOUND GETDNS and STUBBY
and here: https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/

By the way I run Davidc502 LEDE Snapshots - Moderately Customized LEDE Development Builds for Linksys 1900ac v.1 and 1900ac v.2, 1900acs v.1 v.2, 3200acm, WRT32X and 1200ac v.1 v.2 series routers. These builds keep up to date package repositories.. GetDns and Stubby are included. Dave's Builds have many other pre-installed common packages as well.. Check out homepage and downloads here: https://davidc502sis.dynamic-dns.net/ and downloads here: https://davidc502sis.dynamic-dns.net/snapshots/ . In addition, there is a very informative, instructive and active thread ( forum ) for Dave's builds and discussion of many OpenWrt / Lede packages, features, and issues. In short great technical advice and assistance can be found here: https://forum.openwrt.org/t/davidc502-wrt1200ac-wrt1900acx-wrt3200acm-wrt32x-builds/ Dave releases new updated builds every two weeks - near the middle and first of each month.
I tell you the above because I always have the most up to date packages, linux kernel, wifi drivers and so on. This tutorial may not be for you if you do not have the versions of the software listed in the header of this post. OK - here we go once again.

This setup is specifically designed for GETDNS and STUBBY with Unbound DNS and Dnsmasq for DHCP. You can use odhcpd which will handle both DNS and DHCP where you disable and/ or remove DNSMASQ - but you will experience a performance hit. This why I use Unbound/ STUBBY for DNS and Dnsmasq for DHCP. Here is a basic guide as to how to do it - 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.

Refer to this guide while following along with me : https://blog.grobox.de/2018/what-is-dns-privacy-and-how-to-set-it-up-for-openwrt/

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 install unbound odhcpd unbound-control unbound-control-setup luci-app-unbound unbound-anchor unbound-host
2 - opkg install getdns stubby

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 )

You should " Optimize Unbound " - especially increase size of cache among other things see guide here and adjust for your router's memory , number of cores and so on-
see here: https://nlnetlabs.nl/documentation/unbound/howto-optimise/ 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
Enter via SSH command line:
uci set ‘unbound.@unbound[0].query_minimize=1’

4 - Here is where a major change takes place. On getdns 1.4.2-2 and stubby 0.2.3-3 the /etc/stubby/stubby.yml file DOES NOT control the configuration of STUBBY by default. This has been replaced by the UCI system and the file /etc/config/stubby. 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:

Note: by default on OpenWRT stubby configuration is handled via
the UCI system and the file /etc/config/stubby. If you want to
use this file to configure stubby, then set option manual '1'
in /etc/config/stubby.

5 - To keep this simple - go into default UCI STUBBY file which is /etc/config/stubby by entering nano /etc/config/stubby and then set option manual '1' - if you leave it at default setting of option manual 'o' you will not be able to use the /etc/stubby/stubby.yml file in order to configure STUBBY as before. So, after changing option manual '1' in the /etc/config/stubby file - configure /etc/stubby/stubby.yml as follows:
open image in new tab and enlarge and / or see here for Stubby configuration:
https://github.com/getdnsapi/stubby
VERY IMPORTANT UPDATE:
After checking, rechecking and the triple checking on this website mentioned above : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 I have made some very serious discoveries regarding which DNS Privacy Test Servers to use. The bottom line that I strongly suggest you only choose to deploy servers which support the TLSv1.3 protocol . See here for information and importance of TLSv1.3 : https://kinsta.com/blog/tls-1-3/ 1
I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is:

nano /etc/stubby/stubby.yml and change the file content to:

## Tested On https://cmdns.dev.dns-oarc.net/ May 20 2019 A Rating - Perfecto Configuration

# Note: by default on OpenWRT stubby configuration is handled via
# the UCI system and the file /etc/config/stubby. If you want to
# use this file to configure stubby, then set "option manual '1'"
# in /etc/config/stubby.
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: 60000
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453 ## If you use IPV6 Servers
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
upstream_recursive_servers:
# IPV4 Servers
### DNS Privacy Test Servers ###
## The Surfnet/Sinodun DNS TLS Server
  - address_data: 145.100.185.18
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
# The securedns.eu DNS TLS Server  dot.securedns.eu
  - address_data: 146.185.167.43
    tls_auth_name: "dot.securedns.eu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
#The BlahDNS German DNS TLS Server
  - address_data: 159.69.198.101
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: GsfF6a28usi59J/pUUtqbyfmmyKE7+7OfzdLXzUt/Aw=
#The BlahDNS Japan DNS TLS Server
  - address_data: 108.61.201.119
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: B0mMSct7Bbz4E7Lk6BwXuVzdxA1KuYtDs8pw7uaPmB4=
#The DNS Warden DNS TLS Primary Server
  - address_data: 116.203.70.156
    tls_auth_name: "dot1.dnswarden.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA=
#The DNS Warden DNS TLS Secondary Server
  - address_data: 116.203.35.255
    tls_auth_name: "dot2.dnswarden.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: deCWLScS/hqOKvzPDNr9JZdoBYsrWM7AWQ56biseGxA=
#The Primary appliedprivacy.net DNS TLS Server
  - address_data: 37.252.185.232
    tls_auth_name: "dot1.appliedprivacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: ScYkwTIhR1AZGwAsy9Fgn+ET70+t8HR8giYq9abl7tA=
#The ibksturm DNS TLS Server
  - address_data: 217.162.206.220
    tls_auth_name: "ibksturm.synology.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: v9DZ6wtFZcs26wzq6lwHSlcV6o0Nvw/9pLiBarQJfQE=
#The Secure DNS Project by PumpleX DNS TLS Server
  - address_data: 51.38.83.141
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: P/Auj1pm8MiUpeIxGcrEuMJOQV+pgPY0MR4awpclvT4=
### Anycast DNS Privacy Public Resolvers ###
#Quad9 'secure' DNS TLS Secondary Server
  - 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=

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

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

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

uci add_list dhcp.@dnsmasq[-1].server='127.0.0.1#5453'
uci set dhcp.@dnsmasq[-1].noresolv=1
uci commit && reload_config
or
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

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

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

or

Via Luci Interface Under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server 127.0.0.1 - I now only run 127.0.0.1 ( Localhost ) configured as the only DNS SERVER on my WAN interface. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.

11 - Optionally, enter DNS Servers in order 127.0.0.1, along with Tenta nameservers 99.192.182.200 and 99.192.182.100 - Your DNS will still resolve using the upstream name servers you selected in stubby.yml - Things Will Work Fine and as Intended. I have found that you may use Tenta DNS name servers as " custom DNS servers " on the Wan interface. Tenta DNS is a good choice because their name servers support both emerging DNS privacy standards - DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep your DNS queries private and free from tampering. Tenta DNS also is the only AnyCast DOT service which includes built-in BGP integration, offering single engine convenience for DNS Anycasting with QNAME minimisation enabled on its' name servers by default. Main benefits of Tenta DNS as the backbone name servers on OpenWrt:
A - Stop ISPs from spying on your browser history. DNS-over-TLS adds a layer of encryption over your DNS requests, keeping your ISP from seeing which websites you visit.
B - Stay private online. Tenta DNS logs a counter instead of queries so your data stays private. No one, not even Tenta, has access to your browsing data.

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

13 - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup. These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. )
Use either 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

14 - I have found that for whatever reasons it is best to make these entries in startup in order for stubby and unbound to fire up after a reboot. On boot, in case GetDns and Stubby fails to start. This is very likely due to Internet connection not available yet at time of starting Unbound GetDns and Stubby. In such a case, the workaround is to wait for Internet connection to be available before restarting Unbound GetDns and Stubby. Add the following lines into /etc/rc.local:
You may also enter these additions via Luci menu Startup > Local Startup
nano /etc/rc.local
Note: you must comment out with the symbol ## the BOLD FACED ENTRIES BELOW:
( at the beginning of each line ONLY )

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

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

Restart DNS Privacy Daemon - Stubby as it requires a successful
time sync for its encryption to work/
/etc/init.d/unbound restart
/etc/init.d/stubby restart
/etc/init.d/openvpn restart #If you run VPN as you should

exit 0

15 - You will now be running DNS OVER TLS with GETDNS and Stubby on LEDE / OpenWrt
Make sure to follow this guide precisely and it works GREAT!!!
You can check logs under Services > Recursive DNS > Status > Log - you will see that you have a caching encrypted DNS Resolver !!!

Bonus Setup Option ( Highly Recommended ) - Install WatchCat
http://www.ibuyopenwrt.com/index.php/2-uncategorised/224-watchcat-reboot-on-internet-drop I set "Reboot on Internet Connection Lost" option. I have WatchCat set to ping Fourth Estate DNS address - 179.43.139.226 - every 20 minutes. This will keep your router up and running consistently.

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

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

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

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

Parting Thoughts:
My reason for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file is for the following reasons.
1- I found that I had more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on.
2 - In my testing UCI system /etc/config/stubby file configurations did not work well with UNBOUND. As I said, I believe that this is for native DNSMASQ on Openwrt. For instance, there is an entry option appdata_dir '/var/lib/stubby' - this is for Stubby to do DNSSEC as DNSMASQ does do not do this.
3 - In short, I prefer UNBOUND along with STUBBY and GETDNS as NLnet Labs develops all of these components which were constructed to implement DNS OVER TLS ( aka DNS PRIVACY ). I am sure that they will do their best to make sure that all of these components work well together.
Others may think otherwise and I respect that. However, the major point is that NLnet Labs is running "The Whole GETDNS STUBBY / UNBOUND Show" - so that is a good thing that one developer is handling all components needed for DNS OVER TLS.

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