OPNsense Forum

English Forums => Tutorials and FAQs => Topic started by: directnupe on February 16, 2020, 07:37:27 am

Title: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: directnupe on February 16, 2020, 07:37:27 am
LAN Interface For GETDNS and STUBBY Plus UNBOUND
WHY YOU ASK ? ANSWER : IN LIFE ONE SHOULD HAVE OPTIONS

IMPORTANT UPDATED INFORMATION !!! - READ FULL GUIDE BEFORE GETTING STARTED !!!

Stop OPNsense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OPNsense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on OPNsense. So, let's get started.

See Below For Definition and Function Of Unbound Root Hints :
Unbound is a caching DNS resolver. It uses a built in list of authoritative
nameservers for the root zone (.), the so called root hints.
On receiving a
DNS query it will ask the root nameservers for an answer and will in almost
all cases receive a delegation to a top level domain (TLD) authoritative nameserver.
Source Document : https://man.openbsd.org/unbound

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 -

Your OPNsense /etc/resolv.conf file before and after configuring
LAN Interface For GETDNS and STUBBY Plus UNBOUND as described in
this tutorial.


Your OPNsense Firewall
# domain secureone.duckdns.org # Domain Used In My
# OpenWRT DuckDNS LET’S ENCRYPT CERTIFICATES MADE SIMPLE Tutorial

Before Below :
# cat /etc/resolv.conf
domain secureone.duckdns.org
nameserver 127.0.0.1
nameserver 127.0.0.1


After Below :
~ # cat /etc/resolv.conf
domain secureone.duckdns.org
nameserver 192.168.7.11


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 the 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

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.
Go To Services > UNBOUND > GENERAL SETTINGS

UNDER UNBOUND GENERAL SETTINGS
Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES

Under Custom options enter the following :
server:
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 192.168.7.11@8053 ## ( Your One Main LAN Address )
## END OF ENTRY

## Note : do-not-query-localhost: no
## this entry is necessarily removed
## from this UNBOUND configuration
## Disabling DNS Queries From Localhost ( 127.0.0.1 )

Outgoing Network Interfaces = Select LAN ONLY ! # IF You Have Multiple Lan Interfaces - Select ALL LAN INTERFACES

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 Your One Main LAN Address ( 192.168.7.11 ) 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 Checked  - I repeat - Is Checked !

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

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

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.

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.
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: mrancier on April 29, 2020, 01:32:45 am
trying to get this to work with nextdns or blockerdns, but although stubby runs, when I try to dig the server to test it I get  "WARNING: recursion requested but not available".
Running latest production 20.1.5.

Any help would be appreciated.
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Easylarveur on May 20, 2020, 09:47:05 pm
Thank you for this big update on how to install unbound + stubby on opnsense.

I am a satisfied user of these 2 softwares for about a year now.
I have got a few questions for you. I hope you will have the time to answer a few of them.

1) I have seen that you have enable the DNSSEC extension in Stubby.
We can see it in the stubby.yml files:
Quote
dnssec_return_status: GETDNS_EXTENSION_TRUE

If you have already activated the DNSSEC validation in unbound, don't you think that it is useless to activate it in stubby?
I have enabled DNSSEC only in unbound and everything is fine.
Unbound is making all the stuff about the dns queries. I am using stubby only to send the dns queries from unbound with DoT or DoH to several servers.


2) I will try your new settings with the main LAN Address instead of the localhost address. What is exactly the pro of this new settings ?

3)With the new plugin unbound-plus we will soon not have access anymore to the "custom options" in unbound GUI.
Where can we then specify the following to transfer the dns queries from unbound to stubby?
Quote
server:
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 192.168.7.11@8053 ## ( Your One Main LAN Address )
## END OF ENTRY

Thanks again for all the help provided on the install of stubby on opnsense.
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: directnupe on May 20, 2020, 10:49:35 pm
trying to get this to work with nextdns or blockerdns, but although stubby runs, when I try to dig the server to test it I get  "WARNING: recursion requested but not available".
Running latest production 20.1.5.

Any help would be appreciated.

Dear mrancier,
Hello and I hope that you are both safe and well. Forgive me for not getting back to you earlier. My main router is OpenWRT and I use both nextdns and blockerdns. I just ran the dig commands for both of these with no issues. Now - to be transparent, I am running getdns stubby and unbound on localhost ( 127.0.0.1 ) on my OpenWRT router. So try changing to that setup and test it ( you know troubleshooting ). Here below for how to : https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0

The other possibility could involve how you are configuring blockerdns and nextdns respectively.  See here for nextdns demo and illustration : https://nextdns.io/ - Click on " Try It Now For Free "
you must append your own prefix to the DNS OVER TLS endpoint ( see this entry at the very bottom of the page ) :

DNS-over-TLS
Prepend the name to the provided domain (the name should only contain a-z, A-Z, 0-9 and -). Use -- for spaces.
For "John Router", you would use John--Router-f7fc55.dns.nextdns.io as your DNS-over-TLS endpoint.


That may solve your issue on nextdns. As for blockerdns - Tambe recently changed his IP addresses - use the following command line entry to determine them for yourself:

dig +short abcdefgh.blockerdns.com  ( where abcdefgh is your blockerdns "username" ) see here  : https://blockerdns.com/overview read the section here :

Do I get a username and/or password to use blockerDNS? How do you know I'm actually a user if all I'm doing is putting in a DNS server in my settings?
If you're accessing our service via DNS over TLS or DNS over HTTPS, the way we handle authentication is by giving you a unique URL to put as your setting. It'll be something like asdfghjkl.blockerdns.com. The first portion is what serves as your "username".



You must be careful and precise when entering server - address_data: tls_auth_name: and value: for SPKI key - hope this helps and stay safe
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: directnupe on May 20, 2020, 11:04:29 pm
Thank you for this big update on how to install unbound + stubby on opnsense.

I am a satisfied user of these 2 softwares for about a year now.
I have got a few questions for you. I hope you will have the time to answer a few of them.

1) I have seen that you have enable the DNSSEC extension in Stubby.
We can see it in the stubby.yml files:
Quote
dnssec_return_status: GETDNS_EXTENSION_TRUE

If you have already activated the DNSSEC validation in unbound, don't you think that it is useless to activate it in stubby?
I have enabled DNSSEC only in unbound and everything is fine.
Unbound is making all the stuff about the dns queries. I am using stubby only to send the dns queries from unbound with DoT or DoH to several servers.


2) I will try your new settings with the main LAN Address instead of the localhost address. What is exactly the pro of this new settings ?

3)With the new plugin unbound-plus we will soon not have access anymore to the "custom options" in unbound GUI.
Where can we then specify the following to transfer the dns queries from unbound to stubby?
Quote
server:
forward-zone:
 name: "."    # Allow all DNS queries
 forward-addr: 192.168.7.11@8053 ## ( Your One Main LAN Address )
## END OF ENTRY

Thanks again for all the help provided on the install of stubby on opnsense.

Dear Easylarveur,
Hello and I hope that you are safe and doing well in these days. As far as Stubby ( it is called a stub resolver ) so it is actually doing the DNS look ups and forwarding them to UNBOUND. I am not a pure expert or sure of this - however; this is the suggested setup from DNSPRIVACY. See here below  :
https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby#ConfiguringStubby-DNSSEC

DNSSEC
To enable DNSSEC validation when using Stubby add the following option to the configuration file
dnssec_return_status: GETDNS_EXTENSION_TRUE

As to the advantages of this setup - this from the top of the page for this tutorial

Stop OPNsense Router from occasionally allowing UNBOUND Root Hints to resolve queries on its own. This configuration ensures that localhost ( 127.0.0.1 ) will not be used as a resolver on OPNsense Box. You will only use GETDNS and STUBBY DNS SERVERS if you follow this tutorial. You will use your One Main LAN Interface as the listening interface for STUBBY and the listening and outgoing interface for your UNBOUND DNS RESOLVER on OPNsense. So, let's get started.

See Below For Definition and Function Of Unbound Root Hints :
Unbound is a caching DNS resolver. It uses a built in list of authoritative
nameservers for the root zone (.), the so called root hints. On receiving a
DNS query it will ask the root nameservers for an answer and will in almost
all cases receive a delegation to a top level domain (TLD) authoritative nameserver.
Source Document : https://man.openbsd.org/unbound


My reference :
https://forum.netgate.com/topic/130832/solution-posted-dns-tls-getdns-stubby-from-pfsense-freebsd-ports/13
Read Actionhenk' Comment in the thread - second to the last - this is why I set this up this way. However, you can always use the standard installation found here :
https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0

It is up to you - hope this helps
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: firewall on May 24, 2020, 03:52:22 am
directnupe,

thanks, as always, for your marvelous write-ups surrounding DNS PRIVACY.  i commend you again for your efforts.

it should be noted here that nextdns will sunset their beta program in june and will henceforth enforce their monthly limit of 300,000 queries for free accounts. an unfortunate fact, however it is an affordable fee and will certainly still be worthy of consideration for many.

regards,
firewall
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: mrancier on May 25, 2020, 06:15:45 pm
trying to get this to work with nextdns or blockerdns, but although stubby runs, when I try to dig the server to test it I get  "WARNING: recursion requested but not available".
Running latest production 20.1.5.

Any help would be appreciated.

Dear mrancier,
Hello and I hope that you are both safe and well. Forgive me for not getting back to you earlier. My main router is OpenWRT and I use both nextdns and blockerdns. I just ran the dig commands for both of these with no issues. Now - to be transparent, I am running getdns stubby and unbound on localhost ( 127.0.0.1 ) on my OpenWRT router. So try changing to that setup and test it ( you know troubleshooting ). Here below for how to : https://forum.opnsense.org/index.php?PHPSESSID=k6ivse7g94849ga6nk9r8kg9g5&topic=13487.0

The other possibility could involve how you are configuring blockerdns and nextdns respectively.  See here for nextdns demo and illustration : https://nextdns.io/ - Click on " Try It Now For Free "
you must append your own prefix to the DNS OVER TLS endpoint ( see this entry at the very bottom of the page ) :

DNS-over-TLS
Prepend the name to the provided domain (the name should only contain a-z, A-Z, 0-9 and -). Use -- for spaces.
For "John Router", you would use John--Router-f7fc55.dns.nextdns.io as your DNS-over-TLS endpoint.


That may solve your issue on nextdns. As for blockerdns - Tambe recently changed his IP addresses - use the following command line entry to determine them for yourself:

dig +short abcdefgh.blockerdns.com  ( where abcdefgh is your blockerdns "username" ) see here  : https://blockerdns.com/overview read the section here :

Do I get a username and/or password to use blockerDNS? How do you know I'm actually a user if all I'm doing is putting in a DNS server in my settings?
If you're accessing our service via DNS over TLS or DNS over HTTPS, the way we handle authentication is by giving you a unique URL to put as your setting. It'll be something like asdfghjkl.blockerdns.com. The first portion is what serves as your "username".



You must be careful and precise when entering server - address_data: tls_auth_name: and value: for SPKI key - hope this helps and stay safe

I've setup things in copy/paste fashion from your instructions and it will resolve, exactly, one query correctly and then changes to SERVFAIL.  If I restart stubby it does the same thing :  First query works, every subsequent query fails.  Again, this is with the exact same config you posted, save for the LAN address.  Not sure what is going on.  Any help is, naturally, appreciate it.
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Koldnitz on July 05, 2020, 10:34:04 pm
Directnupe,

Thanks you for the awesome write up.

Please note a few things that I noticed messing with this all last weekend / finally fixed today.

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


You do need not to do this part.

Out of the box installed via the pkg manager /usr/local/etc/rc.d/stubby will work / start correctly.

I was unable to get stubby to work with any TLS Server that did not include a pinset

Using the method Directnupe linked to where openssl calculated a server's pinset, allowed me to use cloudflare / google DNS servers.

This was not an optimum solution because they change their certificates (google did theirs today it seems), and your DNS servers would stop working / you will have to recalculate the pinset.

Without the tls_pubkey_pinset I would get the following error in stubby's logs:

unable to get local issuer certificate

I do not understand why tls_ca_path will not work.  It did not work for me in unbound either, hence me using Directnupe's write-up.

Then it did not work with stubby.

Furthermore, I have noticed that opnsense does not make the symbolic link to /etc/ssl/cert.pem (the package options are set to not make symbolic links for some reason), but it seems to be installed nevertheless (?) at the same time ca-root-nss package was.  The wisdom on these forums seem to be to use the cert.pem, but elsewhere I have seen it said to use ca-root-nss.crt.

***************SUPER IMPORTANT***********************************
*******The way to fix this on opnsense 20.1.8_1*****************

Use nano to edit /usr/local/etc/stubby/stubby.yml

Change:
tls_ca_path: "/etc/ssl/"

to

tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"

or

tls_ca_file: "/etc/ssl/cert.pem"


I have confirmed that my cert.pem file appears to be identical with the ca-root-nss.crt file but with the addition of my opnvpn certificate.

Now it works.

I have disabled tls_pubkey_pinset on cloudflare and google dns servers and everything is working correctly.

I hope this helps someone.

Cheers,
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Nekromantik on July 18, 2020, 02:04:01 pm
have this working but first time you visit website it does add a long delay
anyway to make this quicker?
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Koldnitz on July 18, 2020, 03:55:20 pm
Nekromantik,

The DNS servers recommended in the original post were very slow for me (Texas). 

I am using cloudflare (1.1.1.1 and 1.0.0.1) and recursion time usually ends up looking like this on the unbound statistics tab: 0.16 average and 0.1 median. 

Cloudflare is by far the fastest DNS, and mixing it with google and quad 9 noticeable slows things down.  When you throw NextDNS in the mix it gets even slower. 

When I used the Directnupe's recommended A+ servers based in the USA it was averaging 1.5 seconds for a recursion.  Those servers are based in East / West coast so it might be where I am located geographically.

I also messed around with the TTL on unbound and made it serve expired and it seemed to up the amount of cache hits significantly.

Using only Cloudflare with Stubby/Unbound cache I do not notice any difference from when I was just using unbound to forward to Cloudflare / Google servers from the general setting DNS area.

Cheers,
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Nekromantik on July 18, 2020, 06:42:53 pm
yes may need to play around with servers
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: simops on August 18, 2020, 09:31:02 am
Thanks for posting guys, both the original tutorial and the followup posts were extremely helpful.

At first I was just running a pi-hole as a DNS server behind my opnsense home firewall. I then used the method in the first post to set up Stubby and Unbound, once I understood how it worked the only issue I had was I had to change the tls_ca_file: "/etc/ssl/cert.pem" entry as per Koldnitz's post and everything worked perfectly.

I can now send queries either via pihole -> Unbound -> Stubby -> Cloudflare over TLS, or just go directly Unbound -> Stubby -> Cloudflare. Since the latest version of opnsense has blacklists built into Unbound the pihole is redundant except for the nice dashboards, but I can live without those.

On the forward-facing side Unbound can now support DNS over TLS, and since you can enter multiple forward TLS resolvers in the Custom Options box, I don't think I understand what extra value there is by introducing Stubby to the resolver chain.

Does Stubby bring anything vitally important to the mix or is it just easier to leave it right out and run Unbound by itself?
Title: Re: FRESH NEW AND IMPROVED GETDNS STUBBY AND UNBOUND AKA DNS PRIVACY
Post by: Koldnitz on August 20, 2020, 03:53:36 am
I personally could not get unbound to do both encryption and validation of the DoT servers.

Encryption was no problem
https://sahlitech.com/opnsense-setup-unbound-dns/ (https://sahlitech.com/opnsense-setup-unbound-dns/)

forward-ssl-upstream:yes
forward-addr: 1.1.1.1@853   #CloudFlare

but ...

When I put this:

forward-tls-upstream: yes
forward-addr: 1.0.0.1@853#one.one.one.one (as an example)

from https://calomel.org/unbound_dns.html (https://calomel.org/unbound_dns.html) (unbound tutorial on calomel.org) I could not get anything to work.  I never even saw the error in my logs (I am sure this was due to me not understanding where to look) and I could not find any information on why this does not work.

TLDR: As soon as I added the bit following # symbol all DNS stopped.

After doing lot of googling / lurking on these forums you find a few posts where people say this functionality does not work yet with the unbound in Opnsense, but other people claim it does, both on this forum in tutorials, and all over the web, so your mileage may vary.

Stubby works for me, it is supposedly is more efficient (reuses TLS connections) than unbound, and it incorporates TLS 1.3.

The main thing for me again is the fact that it fully works.

If you can get unbound to work fully (i.e. it will verify the dns server is who it says it is, ie it works with the bit after the # above) I do not see the point in adding stubby.

Cheers,