Jump to content
TorGuard
Sign in to follow this  
directnupe

OPNSENSE DNS OVER TLS UPDATED NOW ! DEAD SIMPLE

Rate this topic

Recommended Posts

directnupe

Dear Community,
First you all know the drill by now - " The Intro " we would all have a better world if remembered to practice " Baby Love " lyrics : https://genius.com/Mothers-finest-baby-love-lyrics and video : https://www.youtube.com/watch?v=Z1LCj0Gkq94 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).

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 get 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 On https://www.immuniweb.com/ssl/?id=Su8SeUQ4 September 18 2019 With A+ Rating - 100%  Perfecto Configuration
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: 60000
listen_addresses:
  - [email protected]
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
round_robin_upstreams: 1
tls_ca_path: "/etc/ssl/"

upstream_recursive_servers:
# IPV4 Servers
### DNS Privacy Test Servers ###
## The Surfnet/Sinodun DNS TLS Server   A+
  - address_data: 145.100.185.18
    tls_port: 853
    tls_auth_name: "dnsovertls3.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
### Test servers ###
#The DNS Warden DNS TLS Primary Server   A+
  - address_data: 116.203.70.156
    tls_auth_name: "dot1.dnswarden.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0=
#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.cmrg.net DNS TLS Server  A+
  - address_data: 199.58.81.218
    tls_auth_name: "dns.cmrg.net"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
#The BlahDNS German DNS TLS Server   A+
  - address_data: 159.69.198.101
    tls_auth_name: "dot-de.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: lI/c+XiSmaAm79YulIzRmskcP7MAAD4G4uaD3iLs3Bk=
#The BlahDNS Japan DNS TLS Server   A+
  - address_data: 108.61.201.119
    tls_auth_name: "dot-jp.blahdns.com"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: psuldEImRyeSkU88b2ORtiNQ2uBdo+RCwAw6SxaJWQ4=
# The securedns.eu DNS TLS Server   A+
  - address_data: 146.185.167.43
    tls_auth_name: "dot.securedns.eu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
#The dns.neutopia.org  DNS TLS Server   A+
  - address_data: 89.234.186.112
    tls_auth_name: "dns.neutopia.org"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
#The dns.seby.io - Vultr DNS TLS Server   A+
  - address_data: 139.99.222.72
    tls_auth_name: "dot.seby.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw=
#The dns.seby.io - OVH DNS TLS Server   A+
  - address_data: 45.76.113.31
    tls_auth_name: "dot.seby.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: H13Su1659zEn0ZIblEShwjZO+M5gxKK2wXpVKQHgibM=
#The Primary appliedprivacy.net DNS TLS Server   A+
  - address_data: 37.252.185.232
    tls_auth_name: "dot1.appliedprivacy.net"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yJ5GuTCv9+gRyR78zryHT38gTJ0lmAcsXZXTH/XVA0Y=
#The Secure DNS Project by PumpleX DNS TLS Server   A+
  - address_data: 51.38.83.141
    tls_auth_name: "dns.oszx.co"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: uXHfOKxBJ4aqMWmVw7+NtXGCkiYLyaeM7WujER0jIkM=
#The dns.digitale-gesellschaft.ch DNS TLS Server # 1   A+
  - address_data: 185.95.218.43
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: JnvUziCIRjvSPYAqcTkQu7ZPuWLP3R6R6aPKrDvlzMs=
#The dns.digitale-gesellschaft.ch  DNS TLS Server # 2    A+
  - address_data: 185.95.218.42
    tls_auth_name: "dns.digitale-gesellschaft.ch"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: nBRTYH4++qjDTSJAhlzd2wxXf5cBviICH74qg4Qi3uw=
#The dot.tiar.app DNS TLS Server   A+
  - address_data: 174.138.29.175
    tls_auth_name: "dot.tiar.app"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: AlZ2o2V62EJgD/7QjuuJWRvVLi2cDLiDR2yux6WNnnA=
#The dns-nyc.aaflalo.me DNS TLS Server     A+
  - address_data: 168.235.81.167
    tls_auth_name: "dns-nyc.aaflalo.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: KqzeDRgYePfKuZrKttwXM8I2Ej4kD6Sayh0kp4NWaJw=
#The dns.aaflalo.me DNS TLS Server     A+
  - address_data: 176.56.236.175
    tls_auth_name: "dns.aaflalo.me"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 9QK9j+GK8Vc6HrzAGlwxjKL+dWGe/fpLjleufiKKU6o=
#The jp.tiar.app DNS TLS Server # 2     A+
  - address_data: 172.104.93.80
    tls_auth_name: "jp.tiar.app"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: rHMXX6yjgu62Z7QKtK6joQ3xHf8g/SJey8qiaXFdKKM=
### 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.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=

Save and Exit



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 :

# 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: [email protected]

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×