READ ENTIRE GUIDE BEFORE YOU BEGIN
See here for GETDNS AND STUBBY on OPENWRT / LEDE:
https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
OPENWRT STUBBY DNS OVER TLS USING UNBOUND:
https://forum.openwrt.org/t/from-the-dns-privacy-project-dns-over-tls-on-openwrt-lede-featuring-unbound-getdns-and-stubby/13765
https://torguard.net/forums/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/
I have written tutorials where DNS OVER TLS setup is focused on deploying UNBOUND STUBBY and GETDNS along with DNSMASQ for DHCP on OPENWRT/LEDE. Thanks to my good friend Specimen ( see his tutorial / guide here : https://forum.openwrt.org/t/tutorial-dns-over-tls-with-dnsmasq-and-stubby-no-need-for-unbound/18663 - I was able to realize that we can eliminate UNBOUND all together for those who wish to do so for any number of reasons. For those of you who that may have limited memory or storage available on your router and you need more storage and swap memory for your router see here: http://ediy.com.my/index.php/blog/item/118-how-to-increase-storage-on-tp-link-tl-mr3020-with-extroot and here: https://samhobbs.co.uk/2013/11/more-space-for-packages-with-extroot-on-your-openwrt-router -Specimen's tutorial features a method to install STUBBY and GETDNS to RAM very smartly and efficiently as well - that will not be covered here as I have found that DNSMASQ-FULL is a better solution in my opinion.
So - let's get started with no further ado:
2 -
A - opkg update
B - opkg install ca-certificates
C - opkg install stubby ( GETDNS and LIBYAML will be installed as dependencies )
3 - This guide aforementioned at the top of this page: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md is the one I followed. However, the only issue is that the guide gives one several options as to how to deploy STUBBY and GETDNS with DNSMSQ and / or DNSMSQ-FULL. With the availability of options just may come confusion and mistakes. So, the purpose of this tutorial is to demonstrate how to eliminate potential errors during setup of STUBBY DNS OVER TLS USING DNSMASQ-FULL FOR DNSSEC & CACHING as the title asserts.
4 - I chose to use the /etc/stubby/stubby.yml file to configure STUBBY. My reasons for preferring to configure Stubby with the /etc/stubby/stubby.yml file instead of the now default UCI system /etc/config/stubby file are for several reasons. I found that I have more control over the security options which DNS OVER TLS is intended to provide. Like padding - 853 or 443 port and so on. So in order to use /etc/stubby/stubby.yml file, you must change a default setting in the /etc/config/stubby file to allow manual configuration.
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:
6 - The next step is to configure /etc/stubby/stubby.yml file in the standard fashion. Note that DNSSEC is not configured in STUBBY as DNSMASQ-FULL
will be configured to implement this feature later on in this process. Here is my /etc/stubby/stubby.yml file nano /etc/stubby/stubby.yml :
# 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
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 60000
listen_addresses:
- [email protected]
upstream_recursive_servers:
# IPV4 Servers
# The getdnsapi.net Server
- address_data: 185.49.141.37
tls_port: 853
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
# The Fondation RESTENA Server
- address_data: 158.64.1.29
tls_auth_name: "kaitain.restena.lu"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
### Test servers ###
## Surfnet/Sinodun Servers
- address_data: 145.100.185.17
tls_port: 853
tls_auth_name: "dnsovertls2.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
# The securedns.eu Server
- address_data: 146.185.167.43
tls_auth_name: "dot.securedns.eu"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
# The dns.cmrg.net Server
- address_data: 199.58.81.218
tls_port: 443
tls_auth_name: "dns.cmrg.net"
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
#The BlahDNS Japan DNS TLS Server
- address_data: 108.61.201.119
tls_auth_name: "dns.jp.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: xUUS3QKzpYz2seet8+zChlhp0jpNCbiGtXFb0ZtAkic=
#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: atJFsia3frz6t/gLTe2qyBKT1a+nrPpyjQqp1bZwttI=
# DNSPRIVACY.at Primary DNS TLS Server
- address_data: 94.130.110.185
tls_port: 853
tls_auth_name: "ns1.dnsprivacy.at"
tls_pubkey_pinset:
- digest: "sha256"
value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
# DNSPRIVACY.at Secondary DNS TLS Server
- address_data: 94.130.110.178
tls_port: 853
tls_auth_name: "ns2.dnsprivacy.at"
tls_pubkey_pinset:
- digest: "sha256"
value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=
#DNS Warden DNS TLS Primary Server
- address_data: 213.136.83.50
tls_auth_name: "dns1.dnswarden.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: fOJ7TG7gmlcDEsqvf6qhtThCUri7U+p/QgTnG62D5FA=
#dns.seby.io - Vultr TLS Server
- address_data: 45.76.113.31
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Zo6lWnGmWBuhPToAq3GR8QFwRxRdFaLNgFlbS9Z8ALU=
#The doh.defaultroutes.de DNS TLS Server
- address_data: 5.45.107.88
tls_auth_name: "doh.defaultroutes.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: zYnx/ptyLlxHp9RQ5cHXbe2HJLXyZUT3A/lbyhd0B/M=
# The dns.neutopia.org Server
- address_data: 89.234.186.112
tls_port: 443
tls_auth_name: "dns.neutopia.org"
tls_pubkey_pinset:
- digest: "sha256"
value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
# The Lorraine Data Network TLS Server
- address_data: 80.67.188.188
tls_auth_name: "ns0.ldn-fai.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
### Anycast services ###
#Tenta ICANN DNS TLS Primary Server
- address_data: 99.192.182.200
tls_auth_name: "iana.tenta.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=
#Tenta OpenNIC DNS TLS Primary Server
- address_data: 99.192.182.100
tls_auth_name: "opennic.tenta.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=
#Cloudflare DNS TLS Primary Server
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
#Cloudflare DNS TLS Secondary Server
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
7 - Integration of STUBBY with DNSMASQ
A - Set DNSMASQ to send DNS requests to STUBBY - this is done to allow Localhost ( 127.0.0.1 ) on port 5453 to be the sole resolver used by your router. This forces router to use DNS OVER TLS as STUBBY listens on the default address / port 127.0.0.1#5453 .
There are two methods to do this:
uci add_list [email protected][-1].server='127.0.0.1#5453'
uci set [email protected][-1].noresolv=1
uci commit
Or edit the /etc/config/dhcp file
nano /etc/config/dhcp
list server '[email protected]'
option noresolv '1'
8 - Disable Sending DNS Requests to ISP Provided DNS Servers
uci set network.wan.peerdns='0'
uci set network.wan.dns='127.0.0.1'
uci set network.wan6.peerdns='0' # If you use STUBBY for IPV6
uci set network.wan6.dns='0::1' # If you use STUBBY for IPV6
uci commit
Or
In the Luci Web interface under Network > Interfaces > Edit Wan > Advanced Settings > Remove Check From Box Next To " Use DNS servers advertised by peer " and enter DNS Server 127.0.0.1 -
9 - Now restart DNSMASQ and enable, start and restart STUBBY just to make sure everything is up and running before you proceed. Run the following commands:
/etc/init.d/dnsmasq restart
/etc/init.d/stubby enable
/etc/init.d/stubby start
/etc/init.d/stubby restart
10 - Enabling DNSSEC - We are going to use DNSMASQ-FULL in order to enable this feature. This one command removes DNSMASQ and installs DNSMASQ-FULL. In order to achieve this end, enter this as one command:
A - opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk
11 - We are now going to configure STUBBY not to perform DNSSEC validation and configure DNSMASQ-FULL to require DNSSEC validation. We do so by entering the following commands via UCI:
uci set [email protected][-1].dnssec=1
uci set [email protected][-1].dnsseccheckunsigned=1
uci commit
Or edit the /etc/config/dhcp file
nano /etc/config/dhcp
option dnssec '1'
option dnsseccheckunsigned '1'
To verify DNSSEC trust-anchors, this is how to do it ( 1 ) trust-anchors are here: TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf"
so in SSH shell issue command : cat /usr/share/dnsmasq/trust-anchors.conf - and Voila' - Whoop There It Is !
12 - Now I am used to running UNBOUND so I accustomed its' caching feature. To increase DNSMASQ-FULL cache use one of these two methods:
A - Via UCI (Unified Configuration Interface) - in shell
uci set [email protected][0].cachesize=1000
uci commit dhcp
Or edit the /etc/config/dhcp file
nano /etc/config/dhcp
option cachesize '1000'
Now restart DNSMASQ and restart STUBBY once again:
/etc/init.d/dnsmasq restart
/etc/init.d/stubby restart
13 - I have found that for whatever reasons it is best to make these entries in startup in order for STUBBY and DNSMASQ-FULL 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 DNSMASQ-FULL GETDNS and STUBBY. In such a case, the workaround is to wait for Internet connection to be available before restarting DNSMASQ-FULL GETDNS and STUBBY. The solution is to 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 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/dnsmasq restart
/etc/init.d/stubby restart
/etc/init.d/openvpn restart #If you run VPN as you should
exit 0
Reboot your router just to make sure everything is running as designed.
14 - Two quick command line tests for you to conduct after rebooting your router:
A - DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy. The name servers listed I use help to consistently ensure QNAME Minimisation functions as designed. The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. You need to opkg install bind-tools or opkg install bind-dig
command : dig txt qnamemintest.internet.nl +short and / or dig -t txt qnamemintest.internet.nl
The results in any of these scenarios will show either:
"HOORAY - QNAME minimisation is enabled on your resolver :)!”
or “NO - QNAME minimisation is NOT enabled on your resolver :(.”
Reference https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4
You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration.
B - DNSSEC TEST - command : dig dnssectest.sidn.nl +dnssec +multi @127.0.0.1
Look at the flags section. You should see : ;; flags: qr rd ra ad; As long as you get ad flag as you should, you now have verified DNSSEC as well.
VERY IMPORTANT TIP:
Please note that right at the top of the main DNS Privacy Test Servers Homepage ( https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ) It Ominously Declares:
DoT servers
The following servers are experimental DNS-over-TLS servers.
Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified.Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!
For these reasons it is most important to check and verify your SPKI pin(s) for TLS authentication manually yourself from time to time. There 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
Peace Unto All,
directnupe
Parting Thoughts:
I really like this deployment and implementation of DNS OVER TLS. It seems to be very snappy in resolving DNS queries - even a bit more responsive than UNBOUND. It is pretty simple and straight forward to set up and the documentation is very easily understood. Moreover, DNSMASQ is the native resolver for OpenWRT, so this set up minimizes any other components which may bog down your router. In essence, this setup is most clean and elegant in my estimation. Also, DNSMASQ-FULL allows you a more robust resolver than the native install standard DNSMASQ version. DNSMASQ-FULL allows for DNSSEC and QNAME Minimisation. I am using this setup now and I will report back later on; however, for now it is working beautifully.

Hello,
i guess most people have heard about the cloudbleed bug.
if not:
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
Since TorGuards Website also uses it, maybe everyone here should change his/her password and activate 2FA.

Not bad at all for simply connecting but as you see, even connecting to torguard brings issues if your ISP is spying on you. This is very good example of something, where other tests show you that everyhing is ok but this test clearly shows you that your ISP is hijacking DNS.
You need to have Java installed on your pc to run these tests, it does not work in chrome, but on firefox it does even if using combination of proxifier and foxyproxy (because java tool does all the job, not the browser itself)
TEST NOW WITH ANALYZR
Good article in german explaining it a little bit and includes the test itself.
Send your tests to TorGuard support, they will help you very fast with any leaks, problems or even unintentionally missconfigured device like to open ports which you do not want at all opened. Here is one example (it provides a link which you can send to torguard support if your tests show any issues):
More test results (example):