OPNsense Forum
English Forums => Tutorials and FAQs => Topic started by: directnupe on July 15, 2019, 07:06:36 pm
-
Dear Community,
First you all know the drill by now - " The Intro " we would all have a better world if we remember to practice the concept that - NOW ! is the time for all of US ( A ) to GET UP & GET INVLOVED and act with SOUL POWER ! - lyrics to sing along : https://genius.com/James-brown-get-up-get-into-it-get-involved-lyrics plus https://genius.com/James-brown-soul-power-lyrics and video : https://www.youtube.com/watch?v=1pvIarW3xHg Bonus JB : https://www.youtube.com/watch?v=v8TvBPshngE - Since version OPNsense 18.7 - you may install stubby and getdns on OPNsense by simply issuing command # pkg install getdns ( Special Thanks and Kudos to Franco and the marvelous OPNsense Development Team ) - Please disregard and do not use any guides and / or tutorials which pre-date this one which covers installation and configuration of DNS Privacy on OPNsense FireWall. This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for OPNsense. I run GetDns and Stubby forwarded to and integrated with Unbound. For those who wish to explore Stubby and GetDns - this method is the one recommended by DNSPRIVACY - see here :
https://getdnsapi.net/
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#DNSPrivacyClients-Unbound - please read this carefully - you will note that it indicates : Unbound As A DNS TLS Client Features:Unbound can be run as a local caching forwarder, configured to use SSL upstream, however it cannot yet authenticate upstreams, re-use TCP/TLS connections, be configured for Opportunistic mode or send several of the privacy related options (padding, ECS privacy) etc. Some users combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as a fully featured TLS forwarder).
I was asked by a still skeptical devotee of DOH
" What makes this way better than just running the DNS-over-https-proxy ?
My answer was : Read this and make your
decisions and conclusions concerning DOH vs DOT .
Here is the article below :
https://www.netmeister.org/blog/doh-dot-dnssec.html
Bottom Line Conclusion From Jan Schaumann - The Author of This Blog Entry :
For that, my current preference is quite clearly DNS-over-TLS:
I fear a bifurcation of DNS resolution by apps combined with the
push for using public resolvers with DoH will lead to a more complex
environment and threat model for many users.
Short Synopsis of DOH:
In other words , ( with DOH ) we gain the same
protections as with DoT for our web applications,
but leaves all other DNS traffic vulnerable.
Subsequently, as a matter of fact and in practice
with DNS OVER TLS ALL DNS traffic is invulnerable
and protected.This is why I run DOT and
eschew DOH on my OPNsense Router.
Further, Personally, I run GETDNS STUBBY and UNBOUND as
described here along with ( wait for it )
FireFox DOH along with Encrypted SNI - plus TLS v 1.3 in Stubby
and naturally a properly configured and encrypted VPN -
These are the reasons I choose to use GetDns and Stubby with Unbound. Those reasons being so that I can take full advantage of all of the most secure privacy features available when running DNS OVER TLS. What I give you here is the absolute best method of implementation and deployment of DNS OVER TLS. For any and all who may be wondering why DNS OVER TLS is all the rage - read this:
https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt I always set up DNS OVER TLS first before configuring OpenVPN and / or WireGuard on OPNsense - this DNS solution works flawlessly with either VPN protocol. So here we go. So go ahead and issue command # pkg install getdns in order to get started. After installing getdns which includes stubby follow the steps below.
1 - Now Ryan Steinmetz aka zi - the port maintainer and developer of this port was kind enough to include a start up script ( stubby.in ) for this package. See the stubby.in here in the raw : https://svnweb.freebsd.org/ports/head/dns/getdns/files/stubby.in?view=markup. All I had to do was ask him and he did for any and all who elect to use this great piece of FreeBSD software.
2 - Now to put all of this together, The stubby.in file is located here - /usr/local/etc/rc.d/stubby by default. First though Stubby needs Unbound root.key - run this command before getting started:
# su -m unbound -c /usr/local/sbin/unbound-anchor Then -
A - Issue this command :
# mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh
Make it executable - I run two commands - it works for me:
# chmod 744 /usr/local/etc/rc.d/stubby.sh # chmod a+x /usr/local/etc/rc.d/stubby.sh
B - Yes must enable Stubby Daemon in the file - open file by : nano /usr/local/etc/rc.d/stubby.sh
go to line 27 - : ${stubby_enable="NO"} change the setting to : ${stubby_enable="YES"} - that is all you have to do to this file. It comes pre-configured. Save and exit.
3 - You can and should also check real time status of DNS Privacy Servers as they are experimental and are not always stable - you can monitor DNS TLS Servers Real Time Status here below:
https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/
I have read here: https://www.monperrus.net/martin/randomization-encryption-dns-requests that Also, it is good to set up some servers that listens 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.
Now you must configure Stubby to resolve DNS OVER TLS - nano /usr/local/etc/stubby/stubby.yml
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/
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 and Updated On November 3 2020 With A+ Rating - 100% Perfecto Configuration on website: https://www.immuniweb.com/ssl/?id=Su8SeUQ4n ** These servers support the most recent and secure TLS protocol version of TLS 1.3 **
Good configuration - These server configurations support only TLSv1.2 and TLSv1.3 protocols - current most secure encryption.
# Also I have added the Country Locations of These DNS PRIVACY Servers using the Alpha 3 Code Format
# see country code lists here :
# https://www.nationsonline.org/oneworld/country_code_list.htm or https://www.iban.com/country-codes
# Use as many or as few depending on your specific needs
## Go Into SSH shell and enter : # nano /usr/local/etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
idle_timeout: 9000
listen_addresses:
- 127.0.0.1@8053
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
round_robin_upstreams: 1
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"
upstream_recursive_servers:
### IPV4 Servers ###
### DNS Privacy DOT Test Servers ###
## 1 - The getdnsapi.net DNS TLS Server A+ ( NLD )
- address_data: 185.49.141.37
tls_auth_name: "getdnsapi.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## 2 - The Surfnet/Sinodun DNS TLS Server #3 A+ ( NLD )
- address_data: 145.100.185.18
tls_port: 853
tls_auth_name: "dnsovertls3.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## 3 - The The Surfnet/Sinodun DNS TLS Server A ( NLD )
- address_data: 145.100.185.15
tls_auth_name: "dnsovertls.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
## 4 - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD )
- address_data: 145.100.185.16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
## 5 - The dns.cmrg.net DNS TLS Server A+ ( CAN )
- address_data: 199.58.81.218
tls_auth_name: "dns.cmrg.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
## 6 - The BlahDNS Japan DNS TLS Server A+ ( JPN )
- address_data: 45.32.55.94
tls_auth_name: "dot-jp.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: gIoiNFxX1Nw+7/pVsmUKBU941bMBYjEYuB2T9drULOM=
## 7 - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU )
- address_data: 159.69.198.101
tls_auth_name: "dot-de.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: YZeyeJf/suAR2fMHLc9RDPkcQi/e8EEnzk5Y1N90QQE=
## 8 - The BlahDNS Finland DNS TLS Server A+ ( FIN )
- address_data: 95.216.212.177
tls_auth_name: "dot-fi.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: PID8ufrN/lfloA6y/C+mpR8MT53GG6GkAd8k+RmgTwc=
## 9 - The BlahDNS Singapore DNS TLS Server A+ ( SGP )
- address_data: 139.180.141.57
tls_auth_name: "dot-sg.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: iENlCR6FD7l71PESwzzBUGVgJ5MtJykG2F1fV1RyV4A=
## 10 - The dns.neutopia.org DNS TLS Server A+ ( FRA )
- address_data: 89.234.186.112
tls_auth_name: "dns.neutopia.org"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
## 11 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT )
- address_data: 146.255.56.98
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: iPoeezj2bJ8n0ZgK7HWPy5g0E7nNB8ugiXGZOHslVMs=
## 12 - The Secure DNS Project by PumpleX DNS TLS Server #1 A+ ( GBR )
- address_data: 51.38.83.141
tls_auth_name: "dns.oszx.co"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: uWtC2lljtQnMVcmKS8mt7sWHuS5mFJ9TWdBDv4ti830=
# 13 - The dismail.de DNS TLS Server #1 A+ ( DEU )
- address_data: 80.241.218.68
tls_port: 853
tls_auth_name: "fdns1.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU=
## 14 - The dismail.de DNS TLS Server #2 A+ ( USA )
- address_data: 159.69.114.157
tls_port: 853
tls_auth_name: "fdns2.dismail.de"
tls_pubkey_pinset:
- digest: "sha256"
value: yJYDim2Wb6tbxUB3yA5ElU/FsRZZhyMXye8sXhKEd1w=
## 15 - The Lorraine Data Network DNS TLS Server A+ ( FRA )
- address_data: 80.67.188.188
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=
## This certificate is currently expired which
## does not pose any concerns in SPKI mode
## (in practice with Stubby)
## Source : https://ldn-fai.net/serveur-dns-recursif-ouvert/
# 16 - The ibksturm.synology.me DNS TLS Server A+ ( CHE )
- address_data: 85.5.93.230
tls_auth_name: "ibksturm.synology.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: npNOnBcLbvZWZgdmcuFaEqYJbaGjBlHMf9DknDoIkgg=
## 17 - The dns.flatuslifir.is DNS TLS Server A+ ( ISL )
- address_data: 46.239.223.80
tls_auth_name: "dns.flatuslifir.is"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: YdmlL2GSokMgH/t506AaHtdfhoW+WAPVwv4dAWGXYMs=
### Publicly Available DOT Test Servers ###
## 18 - The ContainerPI.com - CPI DNS TLS Server A+ ( JPN )
- address_data: 45.77.180.10
tls_auth_name: "dns.containerpi.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 0fDCu9NeTLXKniGX7Hqjq4PLqXV7kvxv04lAWs/dOHY=
## 19 - The FEROZ SALAM DNS TLS Server A+ ( GBR )
- address_data: 46.101.66.244
tls_auth_name: "doh.li"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: E3//wtQoI+p2eDg0+zEejPX3kHowMAUiLwGG6sGckFo=
## 20 - The Andrews & Arnold DNS TLS Server #1 A+ ( GBR )
- address_data: 217.169.20.23
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: N1HkO1CiKQiPYEoFjMMU/mgZc7PMPaVE016y5w8+hUg=
## 21 - The Andrews & Arnold DNS TLS Server #2 A+ ( GBR )
- address_data: 217.169.20.22
tls_auth_name: "dns.aa.net.uk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Rq21Y/YgMvw00ZzFGsiJKTEz0u9BBecPl0ns9oploKE=
## 22 - The dns.seby.io - Vultr DNS TLS Server A+ ( AUS )
- address_data: 45.76.113.31
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
## 23 - The dns.seby.io - OVH DNS TLS Server A+ ( AUS )
- address_data: 139.99.222.72
tls_auth_name: "dot.seby.io"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: y8hXAlkRxglOPlYivo/S/E1EfNFoU9f/Uf4dQcXiHhg=
## 24 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE )
- address_data: 185.95.218.43
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 831vfDRFtFD6GNs592KLJtGWy1174q+L9GrgLTiLEZo=
## 25 - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE )
- address_data: 185.95.218.42
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: amK6e4lPnP+3bOVdh8unyfcLBsCNyPfvHAws+hXCrX4=
## 26 - The Antoine Aflalo DNS TLS Server #1 A+ ( USA )
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: +J+sm9pbtEYYrcm45xqRqsOKmFuwTFdfrct/n5N5Pzo=
## 27 - The Privacy-First DNS TLS Server #1 A+ ( JPN )
- address_data: 172.104.93.80
tls_auth_name: "jp.tiar.app"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: VVZwjDE4AgVuuGDxr3kja+u/0uw2LBoVeO5TH0tfTfU=
## 28 - The Privacy-First DNS TLS Server #2 A+ ( SGP Hosted In USA )
- address_data: 174.138.29.175
tls_auth_name: "dot.tiar.app"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: zI+rGvaSUWXd0uhG1w8ZgR2ZZCAVzfaLPgEg1R+ucfl=
## 29 - The ibuki.cgnat.net DNS TLS Server A+ ( USA )
- address_data: 35.198.2.76
tls_auth_name: "ibuki.cgnat.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: v1FqNAlDF1cvui9S6E1zGYOOiCON4JepZPbBeNqkAK0=
## 30 - The PI-DNS.COM West USA DNS TLS Server A+ ( USA )
- address_data: 45.67.219.208
tls_auth_name: "dot.westus.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: UqbpjW5q+T28xsDG0/QAlklvT39U5h+EtZ9l0/POwaw=
## 31 - The PI-DNS.COM DNS TLS East USA Server A+ ( USA )
- address_data: 185.213.26.187
tls_auth_name: "dot.eastus.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: OupxDACOoLzFnGNfDLsv+Y1KOU/94kfV9wWnpP1+19g=
## 32 - The PI-DNS.COM Central Europe DNS TLS Server A+ ( DEU )
- address_data: 88.198.91.187
tls_auth_name: "dot.centraleu.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: a5xHUXhJT/rl7c9F1qNJafxosDRFNFA+qlLvE8WN56M=
## 33 - The PI-DNS.COM North Europe DNS TLS Server A+ ( FIN )
- address_data: 95.216.181.228
tls_auth_name: "dot.northeu.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: uPFdDaPL7tML0mdZg23LiXyC5AWp+wS+mRsxbeXpK8k=
## 34 - The PI-DNS.COM East Australia DNS TLS Server A+ ( AUS )
- address_data: 45.63.30.163
tls_auth_name: "dot.eastau.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: wTfoz9ckLNEh8Z5+Z+87gLWV/OjNLXCBq1XYnLvmXDk=
## 35 - The PI-DNS.COM East Asia DNS TLS Server A+ ( USA )
- address_data: 66.42.33.135
tls_auth_name: "dot.eastas.pi-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yZvYIR4ivuMRoAD/P8RBcc5TC31BRmcnVJGULFZ4Ows=
## 36 - The Snopyta DNS TLS Server A+ ( FIN )
- address_data: 95.216.24.230
tls_auth_name: "fi.dot.dns.snopyta.org"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: CgI1BzAYzsdcueKIbt682Gu+QEN2z9KDMCLdD192FSA=
## 37 - The NixNet Uncensored Las Vegas DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.lv1.dns.nixnet.xyz" )
- address_data: 209.141.34.95
tls_auth_name: "uncensored.lv1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: d4gBa/F8dM8cWcCpisAzVTp0SGKAEdfsM/2gHe/xJlk=
## 38 - The NixNet Uncensored New York DNS TLS Server A+ ( USA )
## - or use ( tls_auth_name: "adblock.ny1.dns.nixnet.xyz" )
- address_data: 199.195.251.84
tls_auth_name: "uncensored.ny1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: g1jYIvb7hZn98EN0dZszrwdqZTE7so7j6Kb8tvuZQDc=
## 39 - The NixNet Uncensored Luxembourg DNS TLS Server A+ ( LUX )
## - or use ( tls_auth_name: "adblock.lux1.dns.nixnet.xyz" )
- address_data: 104.244.78.231
tls_auth_name: "uncensored.lux1.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 2Lx5gMhMV5DAfJKQcEJ+bL5RKFqgcPV/4gveSCMV6ps=
## 40 - The Lelux.fi DNS TLS Server A+ ( FRA Hosted In GBR )
- address_data: 51.158.147.50
tls_auth_name: "resolver-eu.lelux.fi"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: J9bGpxSju+xN7J9vu4W7+U6jzT1BpwoTCKMeqwf80u8=
## 41 - The Lightning Wire Labs DNS TLS Server A+ ( DEU )
- address_data: 81.3.27.54
tls_auth_name: "recursor01.dns.lightningwirelabs.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 8jveGZnOPVo3ZEpqP373s58WRH802JRT6s7iG1JEMwY=
## 42 - The dnsforge.de DNS TLS Server #1 A+ ( DEU )
- address_data: 176.9.1.117
tls_auth_name: "dnsforge.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
## 43 - The dnsforge.de DNS TLS Server #2 A+ ( DEU )
- address_data: 176.9.93.198
tls_auth_name: "dnsforge.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: m51QwAhzNDSa3G7c1Y6eOEsskzp6ySzeOqy0LKcptDw=
# 44 - The Freifunk München DNS TLS Server A+ ( DEU )
- address_data: 195.30.94.28
tls_auth_name: "doh.ffmuc.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: xDA3eGNf/X3vu9frKPawOAnVFIjIqjp9KxR5nd4ZrQQ=
## 45 - The CIRA Canadian Shield DNS TLS Servers A+ ( CAN )
- address_data: 149.112.121.10
tls_auth_name: "private.canadianshield.cira.ca"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
- address_data: 149.112.122.10
tls_auth_name: "private.canadianshield.cira.ca"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sXmZXPsnkbQMw68THpV0Tgh9zCe12TtXIinSTf7lkkw=
# 46 - The dns.dnshome.de DNS TLS Server #1 A+ ( DEU )
- address_data: 185.233.106.232
tls_auth_name: "dns.dnshome.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
- address_data: 185.233.107.4
tls_auth_name: "dns.dnshome.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: q5AkxgnWVCVjCUNUKl3aIBpGTfXF5GahE0RcncwbZoc=
## 47 - The Usable Privacy DNS TLS Server A+ ( DEU / AUT )
- address_data: 149.154.153.153
tls_auth_name: "adfree.usableprivacy.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: apo4E7JrhTTLL08Y3JLq68Gp6yG1TgHKtwaQKnhqWFs=
## 48 - The DeCloudUs DNS TLS Server A+ ( DEU )
- address_data: 176.9.199.152
tls_auth_name: "dot.decloudus.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: CIeKIadXRDK1slGmnnQzvC38rKBbcGaSyXMPG6leHJA=
## 49 - The Hurricane Electric DNS TLS Server A+ ( USA )
- address_data: 74.82.42.42
tls_auth_name: "ordns.he.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: G9pQNrYB98Wll0AmBF/GsMMn6gaDbXDnInV1je1MaPo=
## 50 - The Stéphane Bortzmeyer DNS TLS Server A+ ( FRA )
- address_data: 193.70.85.11
tls_auth_name: "dot.bortzmeyer.fr"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY=
## 51 - The LibreDNS DNS TLS Server #1 A+ ( IND )
- address_data: 116.202.176.26
tls_auth_name: "dot.libredns.gr"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
## 52 - The LibreDNS DNS TLS Server #2 A+ ( IND )
- address_data: 116.202.176.26
tls_auth_name: "dot.libredns.gr"
tls_port: 854
tls_pubkey_pinset:
- digest: "sha256"
value: V0Y0pvWkAwOPkNSPxDyZd/vJ2bo40ylADWJFu/ubPlM=
### Anycast Publicly Available DOT Test Servers ###
## 53 - The DNSlify DNS TLS Servers A+ ( Anycast )
- address_data: 185.235.81.1
tls_auth_name: "doh.dnslify.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=
- address_data: 185.235.81.2
tls_auth_name: "doh.dnslify.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: w5AEEaNvoBOl4+QeDIuRaaL6ku+nZfrhZdB2f0lSITM=
### DNS Privacy Anycast DOT Public Resolvers ###
## 54 - The DNS.SB DNS TLS Servers A+ ( Anycast )
- address_data: 185.222.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
- address_data: 185.184.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
## 55 - The DNSPod DNS TLS Server #1 A+ ( CHN )
- address_data: 162.14.21.178
tls_port: 853
tls_auth_name: "dns.pub"
tls_pubkey_pinset:
- digest: "sha256"
value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM=
## 56 - The DNSPod DNS TLS Server #2 A+ ( CHN )
- address_data: 162.14.21.56
tls_port: 853
tls_auth_name: "doh.pub"
tls_pubkey_pinset:
- digest: "sha256"
value: Q1JRqG379NbZYD6KcA+jl8co9wuQNhg/YmN4dLImQpM=
# Set the acceptable ciphers for DNS over TLS. With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
#tls_ciphersuites option. This option can also be given per upstream.
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_min_version: GETDNS_TLS1_2
# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
tls_max_version: GETDNS_TLS1_3
Save and Exit
Configure Stubby To Implement TLSv1.3 For OPNsense 20.1 And Above
Add this entry ( found directly above ) to the bottom of your stubby.yml
configuration file ( aka /usr/local/etc/stubby/stubby.yml ) -
make sure to skip a line after last entry before appending these settings:
Starting with OPNsense 20.1-RC1 in order for TLSv1.3 protocol to work properly
( read at all ) in your Stubby instance, OpenSSL 1.1.1 must be active and configured
in the kernel. OPNsense 20.1-RC1 and above does provide OpenSSL 1.1.1 support.
When you have OpenSSL 1.1.1 with TLSv1.3 support simply add the section above in order to set
Stubby to implement TLS1.3. The operative lines necessary are these two specifically
found at the bottom of the stubby.yml file above:
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
tls_max_version: GETDNS_TLS1_3
See below for TLS1.3 Support Check SSH Commands -
openssl s_client -connect 46.101.66.244:853
OR :
openssl s_client -connect 45.32.55.94:443
Read Out Will Be Verified By These Lines Below:
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_CHACHA20_POLY1305_SHA256
OR :
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Depending on Configuration on Tested DOT Server
Note: You will not get a readout indicating that the selected Tested DOT Server utilizes
TLS1.3. This is due to the fact that OPNsense 20.1 does not fully utilize OpenSSL 1.1.1 -
When you run command # openssl version - you will see that OPNsense 20.1 still runs on
OpenSSL 1.02 - This is slated to be fixed on the next major OPNsense release.
Lastly, you can and should take advantage of this new DNS OVER TLS provider.
You need to sign up and use configured settings in order to use it.
NextDNS is a free service - ANYCAST and pretty much cutting edge.
ANYCAST speeds up your DNS - Here it is:
NextDNS https://my.nextdns.io/signup
or feel free to use and test
NextDNS " Try it now for free " Feature
go to : https://nextdns.io/
I also strongly encourage you to subscribe to blockerDNS found here : https://blockerdns.com/
This new DOH / DNS OVER TLS provider is the fastest I have run across. blockerDNS is run by
Tambe Barsbay a seasoned, thorough and extremely proficient tech practitioner.
blockerDNS is based in the U.S. and its infrastructure is hosted on Google Cloud Platform
and DigitalOcean. You can view blockerDNS subscription options here : https://blockerdns.com/tryit -
Most significantly, Tambe stands by his claim that he offers " Instant support by phone or email ".
Overall blockerDNS is a great DNSPRIVACY DNS Service. Tip : The Mobile $0.99 per month option should
suffice for most home users. Links : https://tambeb.com/ https://blockerdns.com/blog
https://blockerdns.com/support https://blockerdns.com/overview
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.
Use either or both of these two methods to verify QNAME Minimisation
A - Run command : drill txt qnamemintest.internet.nl
and / or
B - Run 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 under Unbound " Custom Options":
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes
4 - In order to have OPNsense use default start up script ( /usr/local/etc/rc.d/stubby.sh ) at boot time you will have to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following :
# touch /etc/rc.conf.d/stubby - create the needed new file
# nano /etc/rc.conf.d/stubby - in the new file enter the following two lines:
stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby.sh"
Save and exit / then make the file executable - once again - works for me : # chmod 744 /etc/rc.conf.d/stubby # chmod a+x /etc/rc.conf.d/stubby
5- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
UNBOUND GENERAL SETTINGS
Network Interfaces = Select ALL !
Under Custom options enter the following :
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053
## END OF ENTRY
Outgoing Network Interfaces = Select ALL !
Make Sure to NOT CHECK - DO NOT CHECK - the box for DNS Query Forwarding. Save and Apply Settings
Next -Under System > Settings > General Settings
Set the first DNS Server to 127.0.0.1 with no gateway selected /
Make sure that DNS server option
A - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked !
and DNS server option
B - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked !
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.
- Save and Apply Settings
C'est Fini C'est Ci Bon C'est Magnifique
Reboot your router just to sure. Lastly, you can check your DNS at GRC DNS Nameserver Spoofability Test - DNSLeak.com - or any 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.
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
Most Simple and Direct Method:
gnutls-cli --print-cert -p 853 159.69.198.101 | grep "pin-sha256" | head -1
And / Or With Adjustment For SSL Port and Address Being Tested
gnutls-cli --print-cert -p 443 159.69.198.101 | grep "pin-sha256" | head -1 - where you must pkg install gnutls
OR
echo | openssl s_client -connect '185.49.141.37:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
Remember to change port to 443 or port for IPV6 if different than standard 853 where applicable.
https://www.dnsleaktest.com/ https://www.perfect-privacy.com/dns-leaktest https://cryptoip.info/dns-leak-test
https://www.grc.com/dns/dns.htm https://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/
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.
Special thanks to all who helped me with this project.
Thank you all and God Bless Always In Peace,
directnupe
-
thanks again directnupe for your tutorial. always exceedingly helpful!
i followed several of your older guides to achieve DOT but i unfortunately reverted back to dnscrypt with queries routed over vpn because the stubby resolution was painfully slow. i decided to try this version of the guide with the hopes stubby + DOT providers had improved but unfortunately i experience more resolution timeouts than anything.
clearly, i can pick and choose providers based on ping time, however i wanted to ask you if there are other things to i might troubleshoot as well.
in the interest of full transparency i am not running stubby on the opnsense box. though i did so in one or several of my previous attempts, my present setup finds it running on raspbian in parallel to pihole. the concepts are still applicable in both circumstances, however. :D
-
i used netselect this evening to find servers with lowest latency among those provided; in turn speeding up resolution quite drastically. a few of the DOT servers i selected were not on the suggested config...including one that was removed from your previous list, cmrg.net according to my tests it was the fastest by a wide margin so i'd appreciate your input as to why it should be excluded!
-
Dear firewall,
Sorry for the delay in replying - by the way Hello and I hope that you are well. The rationale I used in selecting these DNS Servers listed above is that they are rated A+ on https://www.immuniweb.com/ssl/?id=Su8SeUQ4 website. Moreover, I live in New York USA and there is one server "dns-nyc.aaflalo.me" which is based here. QNAME minimisation also is a significant factor in my selecting DNS Resolvers. dns.cmrg.net rates an A on port 443 and an A+ on port 853. These servers change over time - are upgraded and so on. So I will put dns.cmrg.net:853 back on the list. dns.cmrg.net:443 comes with this warning - The server has TLS 1.0 enabled. Since the 30th of June 2018 it is non-compliant with PCI DSS.
So speed is not my main or only concern. When OPNsense moves to OpenSSL 1.1.0 Series with the 20.0 version then TLSv1.3 protocol will also be fully supported. I use these servers now on OpenWRT and pfSense 2.5.0 as both ship with OpenSSL 1.1 variants. If you read this guide carefully - and even some of the older ones - I explained that Please disregard and do not use any guides and / or tutorials which pre-date this one
Also I explain in all the guides that 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. So, you must constantly test and update your servers. I failed to do that with dns.cmrg.net and thanks for pointing that out. Look here : https://forum.opnsense.org/index.php?topic=12495.msg57456#msg57456 for information on testing DOT Servers
Peace,
directnupe
-
There must be missing something in the writeup. Implemented it as it states, and lost connectivity. Something should be overlooked regarding firewall rules.
There isn't still any alternative that doesn't require installing external modules and circunventing the system?
-
Dear Serius,
I really am confused by your feedback / comments. All I can say is that literally thousands have followed this and related tutorials I have posted about DNS OVER TLS. Please provide more specific information regarding your setup. Honestly, this method should and will work if you follow the steps exactly as stated. Give it a fresh start, and if you have any further questions / issues - get back to me and I will do my best to assist you.
Peace,
directnupe
Dear krdk,
Hello and I hope that you are well. First off - you must configure and fine tune UNBOUND RESOLVER for your particular CPU - memory and so on in order to get the best results for DNS Resolution. I have a Dell Optiplex 7010 Intel(R) Core(TM) i5-3470S CPU @ 2.90GHz (4 cores) with 8G of Ram on which I run OPNsense. Here is the full Custom options: I use for UNBOUND ( you must adjust this for your hardware ) see here : https://nlnetlabs.nl/documentation/unbound/howto-optimise/ Here are the Custom options: :
tls-cert-bundle: "/etc/ssl/cert.pem"
hide-identity: yes
hide-version: yes
hide-trustanchor: yes
harden-glue: yes
harden-dnssec-stripped: yes
harden-large-queries: yes
harden-dnssec-stripped: yes
harden-short-bufsize: yes
harden-algo-downgrade: yes
num-threads: 4
interface-automatic: yes
msg-cache-slabs: 8m
rrset-cache-slabs: 8m
infra-cache-slabs: 8m
key-cache-slabs: 8m
rrset-cache-size: 256m
msg-cache-size: 128m
so-rcvbuf: 1m
unwanted-reply-threshold: 10000000
val-clean-additional: yes
use-caps-for-id: no
do-ip6: no
do-ip4: yes
do-tcp: yes
do-udp: yes
minimal-responses: yes
aggressive-nsec: yes
prefetch: yes
prefetch-key: yes
qname-minimisation: yes
qname-minimisation-strict: yes
rrset-roundrobin: yes
target-fetch-policy: "0 0 0 0 0"
max-udp-size: 3072
harden-below-nxdomain: yes
ip-ratelimit: 300
ip-ratelimit-factor: 10
incoming-num-tcp: 100
edns-buffer-size: 1472
outgoing-range: 8192
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8069
Now, remember this is tailored and setup for my particular machine. As far as the stubby.yml files you can use these if you are in the US :
upstream_recursive_servers:
# IPV4 Servers
### DNS Privacy Test Servers ###
#The dns.cmrg.net DNS TLS Server A+ - CANADA
- address_data: 199.58.81.218
tls_auth_name: "dns.cmrg.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
#The dns-nyc.aaflalo.me DNS TLS Server A+ - USA
- address_data: 168.235.81.167
tls_auth_name: "dns-nyc.aaflalo.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: KqzeDRgYePfKuZrKttwXM8I2Ej4kD6Sayh0kp4NWaJw=
### Anycast DNS Privacy Public Resolvers ###
#The security-filter-dns.cleanbrowsing.org DNS TLS Server # 1 A+
- address_data: 185.228.168.9
tls_auth_name: "security-filter-dns.cleanbrowsing.org"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: rb2O6hMTZZ/go/vOqyVLY2lATD9DkD6+BkKfJwYYMFw=
#The DNS Warden DNS TLS Secondary Server A+
- address_data: 116.203.35.255
tls_auth_name: "dot2.dnswarden.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
## The DNS.SB DNS TLS Primary Server A+
- address_data: 185.222.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
## The DNS.SB DNS TLS Secondary Server A+
- address_data: 185.184.222.222
tls_auth_name: "dns.sb"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: /qCm+kZoAyouNBtgd1MPMS/cwpN4KLr60bAtajPLt0k=
Also, you can and should take advantage of this new DNS OVER TLS provider. You need to sign up - it is a free service - ANYCAST and pretty much cutting edge. ANYCAST speeds up your DNS - Here it is NextDNS https://my.nextdns.io/configuration/19474f/setup
Lastly, I am send ing four ( 4 ) screen shots so you can see how to set up and configure UNBOUND - make sure the ports in stubby.yml matches the forward port you use for UNBOUND.
Peace and I am OUT !
directnupe
-
Have you moved the custom options section into the miscellaneous section when you add the plugin for Unbound support of TLS? Second is there a document available for those of us that do not want to use Stubby?
-
This is a great writeup - and I'm really wanting to implement this. I'm a full n00b with opnsense so bear with me. I'm currently running unbound/bind. I really like the filtering options in bind eg: force safe search etc. etc. with kids in the house. That being said, it seems that if I want to use this method of DNS over TLS or something like DNSCrypt, I have to give up the filtering of bind? Is there a way to keep it all?
-
I have tried this a number of times. Each time I setup the 127.0.0.1 in both the custom settings and the DNS servers as my only DNS, I lose the ability to communicate. If I undo the 127.0.0.1 in unbound custom settings and set the DNS to cloudflare, I regain access. I figure I must be doing something wrong. Can anyone suggest anything?
-
Hello lovely Opnsense forum,
I know this post is a little bit old, but I would like to post the actually configuration.
# install
pkg install getdns
# if you use DNSSEC aktually, there is no need for you to use the command down there for initial the trust anchor from unbound, ten there it is allready
# if you doesn't use it to day, use the folowing command:
su -m unbound -c /usr/local/sbin/unbound-anchor
# configure stubby to run - from NO to YES
nano /usr/local/etc/rc.d/stubby
: ${stubby_enable="YES"}
## write config
# i use the preconfigured config
# first, in there are functional comments for almost all commands.
# second, this commands comes with mostly useful preconfigured strings / variables
nano /usr/local/etc/stubby/stubby.yml
# add / rewrite the the following commands:
# dnssec_return_status: GETDNS_EXTENSION_TRUE
# the stuby doku don't know this command -> older versions also?
# actually the command is this:
dnssec: GETDNS_EXTENSION_TRUE # remove #
listen_addresses:
- 127.0.0.1@8053 # add specific port
#- 0::1 # important!: if you don't use ipv6 -> comment out;
# if you use ipv6 the set the right port; for example: "- 0::1@8053"
# otherwise unbound can't srart, becouse without port, stubby uses the same port: 53, and stubby start faster then unbound after a reboot
# tls_ca_path: "/usr/local/share/certs/ca-root-nss.crt"
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt" # add this line
# for not sequentially using the listed upstreamserver,
# but for randomly using
round_robin_upstreams: 1 # add this line
dnssec_trust_anchors: "/usr/local/sbin/unbound-anchor" # add the right path
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # remove #
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # remove # be aware: Use it only with OpenSSL; don't use it with LibreSSL -> see supplement
tls_min_version: GETDNS_TLS1_2 # remove #
You can use the test servers in the yml file, but i have add almost all servers from the post below.
# now two methods to verify QNAME minimisation
drill txt qnamemintest.internet.nl
# or
dig txt qnamemintest.internet.nl +short
# 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 from the post below:
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 under Unbound " Custom Options":
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes
I doesn't found these three variables in the standard config in /var/unbound/* and the unbound documentation is not really informative =) :
https://unbound.readthedocs.io/en/latest/topics/privacy/qname-minimisation.html
These are the facts why i add there to the unbound config also (GUI).
After upgrade to 21.1, unbound want start with these three commands (if unbound doesn't start, you can check the config with unbound-checkconf /var/unbound/unbound.conf) also i removed it and test the command below again:
dig txt qnamemintest.internet.nl +short
..you should see the hoooray again =)
After you save the config in the GUI, you can find it in
nano /var/unbound/unbound.conf
# set a startscript to run the stubby script ( /usr/local/etc/rc.d/stubby) after boot
nano /etc/rc.conf.d/stubby
stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby"
# Save and exit , then make the file executable
chmod 755 /etc/rc.conf.d/stubby
# I don't know why directnupe set permissions with chmod to 744 and then set the permissions with a+x to 755???
# Anyway, thanks to directnupe to the introduction!
# Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS
"UNBOUND" "GENERAL SETTINGS"
"Network Interfaces" = Select ALL !
# Under Custom options enter the following below the three Qname variables:
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053
# set
"Outgoing Network Interfaces" = Select ALL !
# Make sure the box for "DNS Query Forwarding" is unchecked
# Save and Apply Settings
# Next go to
"System" > "Settings" > "General Settings"
# and set the first DNS Server to
127.0.0.1
# with
"no gateway"
# selected
# Make sure that DNS server option
"Allow DNS server list to be overridden by DHCP/PPP on WAN"
# is unchecked
# and DNS server option
"Do not use the DNS Forwarder/Resolver as a DNS server for the firewall"
# is unchecked also
# save all
# log in to ssh and check stubby works perfectly
# run:
stubby -l
# go to GUI under
"DNS check"
# and check out an ip from a website
# after this, go to ssh terminal and check the logs (stubby -l)
# is everything is fine (ip and logs), then restart opnsene and enjoy
# note: it is a good idea to check the DoT DNS servers in stubby.yml every half year
Afterwords, it is a good idea to check these boxes in Unbound :
hide-identity and hide-version.
So I hope this post trigger you to run DoT with verification and not only unbund to use Dot without verification.
kind regards
transmissionend
supplement / usecase LibreSSL:
1. At the moment, you can't use LibreSSL with the "tls_ciphersuites". This command isn't working.
If you use the command, stubby can't resolve any DNS query. You get the message: "This LIbreSSL version does not support configurating cipher suites"
2. When you moved from OpenSSL to LibreSSL, you have to set stubby to enable again: "/usr/local/etc/rc.d/stubby"