Jump to content
Sign in to follow this  

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

Rate this topic

Recommended Posts

DNS OVER TLS FOR getdns 1.4.2-2 stubby 0.2.3-3 and unbound 1.8.1-2
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 .
You may also choose to use DNS OVER TLS with DNSMASQ.  However, that is not the focus of this tutorial. 



There have been some changes to DNS OVER TLS From The DNS Privacy Project. Here is how to get 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: https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765 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 -
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
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-
cat >> /etc/unbound/unbound_srv.conf <<UNBOUND_SERVER_CONF
# 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: 600
cache-max-ttl: 14400
hide-trustanchor: yes
infra-cache-numhosts: 100000
num-queries-per-thread: 4096
max-udp-size: 2048
minimal-responses: yes
rrset-roundrobin: yes
do-tcp: yes
do-ip6: no
prefetch: yes
prefetch-key: yes
qname-minimisation: yes
qname-minimisation-strict: yes
so-reuseport: yes
unwanted-reply-threshold: 10000000
interface-automatic: yes
do-not-query-localhost: no
use-caps-for-id: yes
verbosity: 1
private-domain: "your.domain"
harden-referral-path: yes
target-fetch-policy: "0 0 0 0 0"
val-clean-additional: yes
As per Torsten's Thoughtcrimes Guide : Don’t let each server know the next recursion
Enter via SSH command line:
uci set ‘[email protected][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:
nano /etc/stubby/stubby.yml - open file and you will see:
# 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: 

See here for how to configure Stubby: https://github.com/getdnsapi/stubby


nano /etc/stubby/stubby.yml - replace contents of file with configuration below:

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

## All DNS Privacy Servers Below Tested On https://www.immuniweb.com/ssl/?id=Su8SeUQ4 September 18 2019 With A+ Rating - 100%  Perfecto Configuration
nano /usr/local/etc/stubby/stubby.yml

# Note: by default on OpenWRT stubby configuration is handled via
# the UCI system and the file /etc/config/stubby. If you want to
# use this file to configure stubby, then set "option manual '1'"
# in /etc/config/stubby.
round_robin_upstreams: 1
appdata_dir: "/var/lib/stubby"
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 60000
  - [email protected]
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
tls_ca_path: "/etc/ssl/certs/"
# IPV4 Servers
### DNS Privacy Test Servers ###
## The Surfnet/Sinodun DNS TLS Server   A+
  - address_data:
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
### Test servers ###
#The DNS Warden DNS TLS Primary Server   A+
  - address_data:
    tls_auth_name: "dot1.dnswarden.com"
    tls_port: 443
      - digest: "sha256"
        value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
#The DNS Warden DNS TLS Secondary Server   A+
  - address_data:
    tls_auth_name: "dot2.dnswarden.com"
    tls_port: 443
      - digest: "sha256"
        value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
#The dns.cmrg.net DNS TLS Server  A+
  - address_data:
    tls_auth_name: "dns.cmrg.net"
    tls_port: 853
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
#The BlahDNS German DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
      - digest: "sha256"
        value: lI/c+XiSmaAm79YulIzRmskcP7MAAD4G4uaD3iLs3Bk=
#The BlahDNS Japan DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
      - digest: "sha256"
        value: psuldEImRyeSkU88b2ORtiNQ2uBdo+RCwAw6SxaJWQ4=
# The securedns.eu DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot.securedns.eu"
    tls_port: 853
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
#The dns.neutopia.org  DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dns.neutopia.org"
    tls_port: 443
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
#The dns.seby.io - Vultr DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot.seby.io"
    tls_port: 853
      - digest: "sha256"
        value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw=
#The dns.seby.io - OVH DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot.seby.io"
    tls_port: 853
      - digest: "sha256"
        value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
#The Primary appliedprivacy.net DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot1.appliedprivacy.net"
    tls_port: 443
      - digest: "sha256"
        value: yJ5GuTCv9+gRyR78zryHT38gTJ0lmAcsXZXTH/XVA0Y=
#The Secure DNS Project by PumpleX DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
      - digest: "sha256"
        value: uXHfOKxBJ4aqMWmVw7+NtXGCkiYLyaeM7WujER0jIkM=
#The dns.digitale-gesellschaft.ch DNS TLS Server # 1   A+
  - address_data:
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
      - digest: "sha256"
        value: JnvUziCIRjvSPYAqcTkQu7ZPuWLP3R6R6aPKrDvlzMs=
#The dns.digitale-gesellschaft.ch  DNS TLS Server # 2    A+
  - address_data:
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
      - digest: "sha256"
        value: nBRTYH4++qjDTSJAhlzd2wxXf5cBviICH74qg4Qi3uw=
#The dot.tiar.app DNS TLS Server   A+
  - address_data:
    tls_auth_name: "dot.tiar.app"
    tls_port: 853
      - digest: "sha256"
        value: AlZ2o2V62EJgD/7QjuuJWRvVLi2cDLiDR2yux6WNnnA=
#The dns-nyc.aaflalo.me DNS TLS Server     A+
  - address_data:
    tls_auth_name: "dns-nyc.aaflalo.me"
    tls_port: 853
      - digest: "sha256"
        value: KqzeDRgYePfKuZrKttwXM8I2Ej4kD6Sayh0kp4NWaJw=
#The dns.aaflalo.me DNS TLS Server     A+
  - address_data:
    tls_auth_name: "dns.aaflalo.me"
    tls_port: 853
      - digest: "sha256"
        value: 9QK9j+GK8Vc6HrzAGlwxjKL+dWGe/fpLjleufiKKU6o=
#The jp.tiar.app DNS TLS Server # 2     A+
  - address_data:
    tls_auth_name: "jp.tiar.app"
    tls_port: 853
      - digest: "sha256"
        value: rHMXX6yjgu62Z7QKtK6joQ3xHf8g/SJey8qiaXFdKKM=
### Anycast DNS Privacy Public Resolvers ###
#The security-filter-dns.cleanbrowsing.org  DNS TLS Server # 1     A+
  - address_data:
    tls_auth_name: "security-filter-dns.cleanbrowsing.org"
    tls_port: 853
      - digest: "sha256"
        value: rb2O6hMTZZ/go/vOqyVLY2lATD9DkD6+BkKfJwYYMFw=
## The DNS.SB DNS TLS Primary Server   A+
  - address_data:
    tls_auth_name: "dns.sb"
    tls_port: 853
      - digest: "sha256"
        value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
## The DNS.SB DNS TLS Secondary Server   A+
  - address_data:
    tls_auth_name: "dns.sb"
    tls_port: 853
      - digest: "sha256"
        value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=

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

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
    name: "."    # Allow all DNS queries
    forward-addr: [email protected]
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 '[email protected][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 '[email protected][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
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 [email protected][-1].server=''
uci set [email protected][-1].noresolv=1
uci commit && reload_config

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

    list server '' # 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 - 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
config unbound
        option dns64 '0'
        option edns_size '4096'
        option extended_luci '1'
        option hide_binddata '1'
        option enabled '1'
        option listen_port '53'
        option localservice '1'
        option luci_expanded '1'
        option manual_conf '0'
        option rebind_localhost '0'
        option rebind_protection '1'
        option recursion 'passive'
        option resource 'medium'
        option root_age '9'
        option ttl_min '120'
        option unbound_control '2'
        option validator '1'
        option validator_ntp '1'
        option query_minimize '1'
        option query_min_strict '1'
        option dhcp_link 'dnsmasq'
        option protocol 'ip4_only'
        option prefetch_root '0'
        option extended_stats '1'
        list trigger_interface 'lan'
        list trigger_interface 'wan'

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

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


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 - I now only run ( 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 - VERY IMPORTANT STEP - after setting your DNS to ( you need 127.0.01 as this is what both Stubby and Unbound use as their local resolver ) You must run /etc/init.d/unbound restart one more time. When you do this you will see that your unbound root.key will be installed to /var/lib/unbound/root.key and also it will install root.key to /etc/unbound/root.key. This will automatically configure DNSSEC on your router. The function also lists your auto-trust anchor in your /var/lib/unbound/unbound.conf file. 
12 - 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 :(.”
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
13 - 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 
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# Wait until Internet connection is available
for i in {1..60}; do ping -c1 -W1 &> /dev/null && break; done
# Restart DNS Privacy Daemon - Stubby as it requires a successful
#time sync for its encryption to work/
/etc/init.d/unbound restart
/etc/init.d/stubby restart
/etc/init.d/openvpn restart #If you run VPN as you should
exit 0
14 - 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 - - every 20 minutes. This will keep your router up and running consistently. 
Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares:
DoT servers
The following servers are experimental DNS-over-TLS servers.
Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified.Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!
For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There is 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
Most Simple and Direct Method:
gnutls-cli --print-cert -p 853 | grep "pin-sha256" | head -1
       And / Or With Adjustment For SSL Port and Address Being Tested
gnutls-cli --print-cert -p 443 | grep "pin-sha256" | head -1 -
where you must opkg install gnutls-utils
echo | openssl s_client -connect '' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
There is also a third option. kdig -d @ +tls-ca +tls-host=getdnsapi.net example.com - where you must install knot-dig / opkg install knot-dig
This is my personal favorite as the readout from this command will list the certificate specifically like so:
;; DEBUG:  #1, CN=getdnsapi.net
;; DEBUG:      SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

and let you know that the certificate is valid like so: ;; DEBUG: TLS, The certificate is trusted.
Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable.
To use kdig certificate verification method on an alternate port example: kdig -d @ -p 443 +tls-ca +tls-host=dns.cmrg.net example.com
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://cmdns.dev.dns-oarc.net/ for a thorough in depth DNS Test    https://bash.ws/dnsleak/test/     
See here for TorGuard Open VPN 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,
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.
  • Like 1

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this