OPNsense Forum
English Forums => Tutorials and FAQs => Topic started by: directnupe on May 05, 2018, 08:27:52 am
-
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
This Guide/Tutorial Is Deprecated Except For QNAME Minimisation and VERY IMPORTANT TIP Sections Below for informational purposes. Please Go to https://forum.opnsense.org/index.php?topic=13487.0 for New Updated Guide for DNS OVER TLS on OPNsense. The stubby.yml configuration file below is properly configured along with being up to date with the best DNS PRIVACY SERVERS.
Why I am so damn serious about DNS Privacy ( just watch these when you have time - all at once or in intervals - very educational ):
https://dnsprivacy.org/wiki/display/DP/IETF+DNS+Privacy+Tutorial
https://www.youtube.com/watch?v=JnxE5RPnyiE https://www.youtube.com/watch?v=2JeYIecfwdc
Active work is also underway at the IETF on DNS-over-HTTP (DOH) but today the only method standardized by the IETF is DNS-over-TLS. In the world of encryption, it's always safer to go with standardized protocols that have gone through a rigorous review process. Unfortunately DNSCrypt has not been standardized yet, and some of the ways it uses cryptography are unusual.
For all the doubters and naysayers concerning GETDNS and STUBBY - they are developed by NLnet Labs - the same folks who bring us Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ) see here: https://www.nlnetlabs.nl/ https://www.nlnetlabs.nl/projects/getdns/
Dear Opnsense Community,
Hello and I hope that all is well with all. This is a 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 So here we go.
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.
1 - You can install GetDns and Stubby from Opnsense Ports. Located here - https://github.com/opnsense/ports/tree/master/dns/getdns
2 - First you must install Opnsense Ports - which is a wonderful feature from Opnsense Developers. Here is how to do just that.
A - pkg install git / you must then configure git.
B - Configuring Git Example - Issue Commands
# git config --global user.name "jhon"
# git config --global user.email "jhon@example.com"
# git config --global core.editor "nano"
You can check that your updates went through by looking at your configuration settings with:
# git config --list
Example Output
user.name=jhon
user.email=jhon@example.com
core.editor=nano
3 - Proceed and complete Opnsense Ports install with the following commands: ( Note that is designed for Opnsense 18.7 Variants; however, I believe that it will work with all Opnsense versions - but I have not tested that proposition. )
# cd /usr
# git clone https://github.com/opnsense/ports ## wait for ports to install - then after go to next step
# cd /etc
# fetch https://raw.githubusercontent.com/opnsense/tools/master/config/18.7/make.conf
4 - As Opnsense Ports from GitHub are synced with FreeBsd Ports the rest may be familiar to many of you who use or have used FreeBsd. The GetDns Port page here - https://www.freshports.org/dns/getdns/
5 - If you read carefully you must use " make config ' in order to install the Stubby Daemon along with Getdns.
A - So first - enter Ports directory command
# cd /usr/ports/dns/getdns/
B - Then command to configure installation options
# make config
6 - After entering the " make config " command you will be presented with the Options Screen - select them all except SAFESTACK. After selecting options, press enter OK or whatever to accept the options you just selected. You will now be back in ports directory for getdns port:
#/usr/ports/dns/getdns/
Now issue command:
# make install clean
Let the installation run until it is done. After the installation completes, reenter the /root directory -
command #cd /root - or start new SSH session in order to configure Stubby and integrate it with Unbound.
7 - 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.
8 - 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.
9 - 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
My config file for Stubby yml: you can choose other resolvers from here (https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers ). Here is a list of all DNS Privacy Servers in the raw. Add ( tls_port: 853 ) after ( - address_data: ) entry:
https://github.com/getdnsapi/stubby/blob/release/0.2.3/stubby.yml.example
See here for how to configure Stubby: https://github.com/getdnsapi/stubby
I prefer to run these DNS TLS SERVERS as they tend to be stable most all of the time. The mix of dns.cmrg.net, DNSPRIVACY.at and getdnsapi.net Servers work in an optimal fashion on OpnSense. However, if for any reason you lose internet while running Stubby- chances are it is due to one or more of the servers you are running being down. I told you and it is mentioned on DNSPRIVACY website that all of this ( for the time being ) is experimental. However, even if you run ssl-upstream with Unbound you still will need to monitor real time status of DNS Privacy Test Servers. So, Stubby is still the full featured way to go.
## Begin Sample /usr/local/etc/stubby/stubby.yml file configuration:
# This is a yaml version of the stubby configuration file (it replaces the
# json based stubby.conf file used in earlier versions of getdns/stubby).
## All DNS Privacy Servers Below Tested and Updated On August 21 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_path: "/etc/ssl/"
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 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=
## 10 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT )
- address_data: 94.130.106.88
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU=
## 11 - The Foundation for Applied Privacy DNS TLS Server #2 A+ ( AUT )
- address_data: 93.177.65.183
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 78kfbZFJaxGrAl+0hkiyWER0ajTgFL/KxMAZQHSNhWU=
## 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: Bt3fAHJeDPU2dneCx9Md6zTiKhzWtZ152To0j0f32Us=
## 13 - The Rubyfish Internet Tech DNS TLS Server A+ ( CHN )
- address_data: 115.159.131.230
tls_auth_name: "dns.rubyfish.cn"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=
## 14 - 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/
## 15 - The DNSPRIVACY.at TLS Server #1 A+ ( DEU )
- address_data: 94.130.110.185
tls_auth_name: "ns1.dnsprivacy.at"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Fr9YdIAIg7TXJLLHp0XbeWKBS2utev0stoEIb+7rZjM=
## 16 - The DNSPRIVACY.at TLS Server #2 A+ ( DEU ) - expired 2020-04-01
- address_data: 94.130.110.178
tls_auth_name: "ns2.dnsprivacy.at"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 68MH4G5hipbK1xYATBFgA+/DNLDd333oXr22QyB/RRo=
# 17 - 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=
## 18 - 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: OvqVajUX+2j/xfYqPZid2Z8DMX2Vex8geaYw0UG77BE=
### Publicly Available DOT Test Servers ###
## 19 - 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: xz8kGlumwEGkPwJ3QV/XlHRKCVNo2Fae8bM5YqlyvFs=
## 20 - 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: fiOT+xcarY8uz1UBZ0DzA+Gi5kcSHdBDrofcsZL3HGo=
## 21 - 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: BrjhBir4pbQ0+uTjlViVlc5qf1172WLQxDWevO/4bKI=
## 22 - 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: 1Mu+KSivSkoBfLiCzL+8xhg1YO7xmAjPJAJkjrv5ZvA=
## 23 - 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=
## 24 - 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: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw=
## 25 - 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: OHdm30CP5hu1KI1bLnIokKL1eKbLNWQvN9bNsXb5TJQ=
## 26 - 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: W0CoacPgp4VP2zsOt2ERQuFqXTG37ud5t3ClB5Xh7dY=
## 27 - 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: NZqlaEd1y4tc4z2s/GcclhKlOQtynBKtbomw1dVCydU=
## 28 - 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: +Q7ZdLW0QXokd2OY/vUJm10ZAnm2KFC+ovJfm5++hDc=
## 29 - 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: +zKyo0IWR+e38Yw2KN7pMAkktQSjZUGN4h7BoYLytTk=
## 30 - 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: gWjnc5JNaub1U83vNZtyY/7f1ZYH+Zwt+LWLeTzbLEU=
## 31 - 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: R9/K3atF+ZHuBAVREmFiTX5N0qse+JIqoMF+usZ2dZg=
## 32 - 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: oZQKQh794UHpdtZc/7CG+9VUw+3uGIrQFfAhCvYcds4=
## 33 - 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: ZdED9Ry+FfdsbpGVr2IxR/IB0D7FaVpSBWvsRWutrjg=
## 34 - 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: xb6yo+7vmxFhyrA+NV1ZOKBGHuA03J4BjTwkWjZ3uZk=
## 35 - 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: 0oVEbW/240sc4++zXjICyOO4XKTIEewY9zY5G5v9YnY=
## 36 - 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: 3dV7cgTZbmHD/JTfocBI6FvoyGevpZf2n5k2fG4uVr8=
## 37 - 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: cYf+8BXhzbBmQe6qP+BHzLb2UZ/rgOspuyCmk2aVhlE=
## 38 - 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: Ua+l/cIZ9dbJPExk4grit6qFZWmQZcoIoMBvMLwUDHc=
## 39 - 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: P8A1QEHTXs7QSmAuwR4FupMd3L/OW9TXbTXcFaazzoU=
## 40 - 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: ncPZ5vhEPiv7VOf2nesJW9GYOGZ48MsAhzd4PO+3NJQ=
## 41 - 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: 8ZpLg8m7CE41EnXddCRJGsaWK2UVjy2UnhPo/7BsPIo=
## 42 - 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: 9QRO8JyJCVMU+KAO9acW5xfQnSXRuj1OqAz5aZHwH+4=
## 43 - The Hostux DNS TLS Server A+ ( LUX )
- address_data: 185.26.126.37
tls_auth_name: "dns.hostux.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: P0gaP31TQQzAIN3DomM5vXS3+8oCgYcTA/ZJ09Jw4QE=
## 44 - 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=
## 45 - 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=
# 46 - 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: vAgfcoO9rzejY7Pdv9MK9DymLvYYJ4PF5V1QzReF4MU=
# 47 - The doh.defaultroutes.de DNS TLS Server A+ ( DEU )
- address_data: 5.45.107.88
tls_auth_name: "doh.defaultroutes.de"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: p7t6DDebAlM1rwkrJgZJ6CDkuJG0Ff5PKYZ8bUPQCM0=
## 48 - 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=
# 49 - 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=
## 50 - 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: wnJgPKtu/QHXHx3QZ7mZuIsNMv85buI5jsdsS9cTU5w=
## 51 - 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: +rBZZHFEVTmFwA8RuR9I5vdPqqaBSighP7rcoWgY9MI=
## 52 - The Arapurayil DNS TLS Server A+ ( AUS )
- address_data: 3.7.156.128
tls_auth_name: "dns.arapurayil.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: c3S8JssMSrXuMjDfjwzXHoO4RQckTYTTeUThdW+meo0=
## 53 - 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=
## 54 - 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=
### Anycast Publicly Available DOT Test Servers ###
## 55 - The NixNet Uncensored Anycast DNS TLS Servers ( Anycast )
- address_data: 198.251.90.114
tls_auth_name: "uncensored.any.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug=
- address_data: 198.251.90.89
tls_auth_name: "adblock.any.dns.nixnet.xyz"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Ryhjf7K6V9/Fw/7XU7fqzrVJVEOyPtlHR/rFetOXrug=
## 56 - 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 ###
## 57 - 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=
## 58 - The Comss.one DNS TLS Server #1 A+ ( CHN )
- address_data: 92.38.152.163
tls_port: 853
tls_auth_name: "dns.comss.one"
tls_pubkey_pinset:
- digest: "sha256"
value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4=
## 59 - The Comss.one DNS TLS Server #2 A+ ( CHN )
- address_data: 93.115.24.205
tls_port: 853
tls_auth_name: "dns.comss.one"
tls_pubkey_pinset:
- digest: "sha256"
value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4=
## 60 - The Comss.one DNS TLS Server #3 A+ ( CHN )
- address_data: 93.115.24.204
tls_port: 853
tls_auth_name: "dns.comss.one"
tls_pubkey_pinset:
- digest: "sha256"
value: biGOXwJ1zClsvIfsjqV1FOdRq1jZdw5Sy61AqrlgKj4=
## End of Sample File /
Save and Exit
Configure Stubby To Implement TLSv1.3 For OPNsense 20.1 And Above
Add this entry ( found directly below ) 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:
# 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
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.
DNS query name minimisation to improve privacy, along with DNS resolution speed and accuracy - Run Test After Completing Full Setup
These name servers listed above help to consistently ensure QNAME Minimisation functions as designed within UNBOUND ( The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. )
Use either or both of these two methods to verify QNAME Minimisation
A - 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
10 - 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
11- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
UNBOUND GENERAL SETTINGS
Network Interfaces = WAN LAN ( all of your LAN interfaces if you have more than one ) And You Must Select Localhost - repeat - You Must Select Localhost !
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 = Localhost
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 Spoofability Test - DNS Leak - 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://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
PS -
If you have already installed getdns-1.4.1 then you can see here for how to update:
** BONUS DNS OVER TLS: UPDATE Opnsense Ports for getdns-1.4.2**
https://forum.opnsense.org/index.php?topic=8748.msg38928#msg38928
-
thanks for this! 8)
-
thanks for this! 8)
Dear firewall,
This was a labor of determined effort and ( somewhat ) love and I felt that it was best to share with as many as possible. I am a retired teacher.
You are most welcome and I appreciate your expression of gratitude. God Bless You and Yours - Always
In Peace,
directnupe
-
Please see below.
-
thanks for this! 8)
Dear firewall,
This was a labor of determined effort and ( somewhat ) love and I felt that it was best to share with as many as possible. I am a retired teacher.
You are most welcome and I appreciate your expression of gratitude. God Bless You and Yours - Always
In Peace,
directnupe
Hey @directnupe . from the OPNsense appliance CL it is not possible to ping any address. Prior to trying to ping a host I DID install got using pkg.
Sent from my PH-1 using Tapatalk
@directnupe , for whatever reason when running the git clone command , it is unable to connect to github. Do you have any insight into why this is happening?
Sent from my PH-1 using Tapatalk
-
Dear user7654,
Please read this reply which I wrote to another with a similar issue:
https://forum.opnsense.org/index.php?topic=8759.msg44156#msg44156
See here for UNBOUND setup before installing GETDNS and STUBBY:
https://www.tecmint.com/install-configure-pfblockerng-dns-black-listing-in-pfsense/
You should be able to resolve everything before starting process.
I enter 127.0.0.1 and Tenta ICANN nameservers 99.192.182.200 and 66.244.159.200 under System > General Setup > DNS Server Settings > DNS Servers during initial setup. Also follow these two steps as well during setup of your system initially:
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 hope this helps.
Peace,
directnupe
PS - make sure that you set hostname and domain up under Administration
also under UNBOUND > General Settings - you might see how DNS works if you check BOX for " register dhcp leases in the dns resolver "
see here:
https://www.bytesizedalex.com/pfsense-dns-resolution-for-dhcp-leases/
and
https://forum.netgate.com/topic/17915/enable-registration-of-dhcp-client-names-in-dns-not-working/12
https://www.netgate.com/docs/pfsense/dns/unbound-dns-resolver.html
-
Hi
I have set this up but when I use https://tenta.com/test/ it states none of my DNS servers are using TLS and only 2 are using DNSSEC.
I selected same servers in stubby as the guide.
-
Dear Nekromantik.
Hello - you should check your DNS here : https://cmdns.dev.dns-oarc.net/ and see the features which are listed as being enabled on your resolver ( UNBOUND ). Look for TRANSPORT and you should see TCP which means that you are using DNS OVER TLS and DNS Features QNAME Minimisation which indicates UNBOUND DNS query name minimisation privacy features are in effect.
I have found that the test you mention -: https://tenta.com/test/ is not the best way of testing your DNS attributes. I believe that https://tenta.com/test/ is set up to only fully approve of and verify ( and I guess test ) Tenta DNS and its' browser.
Also, with qname-minimisation enabled your resolver ( UNBOUND ) is set up to minimise the amount of data sent from the DNS resolver to the authoritative name server and in addition with randomize_upstreams: 1 option set in STUBBY - then the DNS TLS Stub resolver aka STUBBY will instruct stubby to distribute queries across all available name servers - key word being available. So theoretically DNS name servers will respond in the fastest way possible - meaning that all the name servers may not be queried as qname-minimisation and qname-minimisation-strict limit the amount of data being sent and received between UNBOUND ( and STUBBY ) and the upstream DNS OVER TLS name servers you have configured in your /usr/local/etc/stubby/stubby.yml configuration file. Hope this helps.
Peace,
directnupe
-
Dear Nekromantik.
Hello - you should check your DNS here : https://cmdns.dev.dns-oarc.net/ and see the features which are listed as being enabled on your resolver ( UNBOUND ). Look for TRANSPORT and you should see TCP which means that you are using DNS OVER TLS.
I have found that the test you mention -: https://tenta.com/test/ is not the best way of testing your DNS attributes. I believe that https://tenta.com/test/ is set up to only fully approve of and verify ( and I guess test ) Tenta DNS and its' browser.
Also, with qname-minimisation enabled your resolver ( UNBOUND ) is set up to minimise the amount of data sent from the DNS resolver to the authoritative name server and in addition with randomize_upstreams: 1 option set in STUBBY - then the DNS TLS Stub resolver aka STUBBY will instruct stubby to distribute queries across all available name servers - key word being available. So theoretically DNS name servers will respond in the fastest way possible - meaning that all the name servers may not be queried as qname-minimisation and qname-minimisation-strict limit the amount of data being sent and received between UNBOUND ( and STUBBY ) and the upstream DNS OVER TLS name servers you have configured in your /usr/local/etc/stubby/stubby.yml configuration file. Hope this helps.
Peace,
directnupe
Thanks that makes sense.
:)
-
I had some problems with repositories and had to download again the ports (they where already present) but after all I managed to get through the guide.
After that, my name resolving is not functional, aka: DNS_PROBE_FINISHED_BAD_CONFIG on every request.
Can you please help me find the problem? Could that be my ISP is "filtering" TSL?
Thanks
Edit: I solved the problem. Apparently there where a few bogus characters in the stubby.yml configuration and a couple of errors sourcing from your github hosted file, like the listening address/port that prevented the service from starting.
Now it works as expected, thanks! Anyways I'll have to study the dns providers because with yours in my location I get a noticeable latency.
-
Dear MultiCubic,
The make.conf file was not working for a while. That was due to the fact that Opnsense was based on FreeBSD 11.1 and it had reached EOL. That situation is now fixed. As far as the resolvers go - yes you can use others. However, if you configure the ones listed in this guide properly in your /usr/local/etc/stubby/stubby.yml - you should have no problems with your DNS OVER TLS resolution.
But I am glad that you got it working. Also I have found that it is best to compile your GETDNS package or port with all the hardening options omitted. You know pie relro safestack - these are not in the FreeBsd Port -so try shutting them off. Lastly use a few qname-minimisation enabled ANYCAST name servers like CloudFlare and Tenta. That should help to fix your latency issues as well.
Peace,
directnupe
-
Thank for your reply. By now your providers are working way better than anything in my country.
Seems that my installation was using a fixed opns repo and that messed my first compilation attempt.
About that last comment... Is something that I didn't understand. When I first reached the "configuration screen" I never saw that safestack option. Only two apart from docs.
When I changed repos, the screen also changed but again no safestack.
Enviado desde mi MI 5s Plus mediante Tapatalk
-
Dear MultiCubic,
Hello - first I am glad that you got it working. As far as I know, Opnsense Ports always make those options Hardening Options - as Opnsense is based on HardenedBSD see here: https://hardenedbsd.org/ and here: http://installer.hardenedbsd.org/hardened_11_stable_master-LAST/ These options pie relro safestack are on by default in Opnsense Ports.
So, make sure that you are cloning https://github.com/opnsense/ports by way of using GitHub as detailed in this tutorial above. In any event, I hope that this helped you. How are your DNS TLS Name Servers working?
Peace and God Bless,
directnupe
-
This configuration screen I was referring as lacking "safestack" option. I first made the package with all options included, and all seemed to work right.
Then I thought that you where referring to those two last options so I remade and reinstalled the package without them. But if I do it, I don't get QNAME minimisation.
So I rebuilt with those on again but I can't get minimisation back. Can you please give me a hand on that? By telling exactly what has to be disabled/modified and what not?
Thanks.
Edit: A managed to get minimisation back by rebuilding the configuration file, but still don't get what has to be disabled and where.
-
Dear MultiCubic,
Hello and I am glad that you got this working. Look as you build GETDNS just select all the " Default Settings " once you have configured the initial screen. Normally, I select all the options available on the screen you show in your screenshot.
There will be other options like under libevent - and so on. Also, as GETDNS builds against UNBOUND - I have found that since GETDNS was updated from 1.4.2 to 1.4.2_1 and 1.4.2_2 now - UNBOUND 1.8.0 is the version GETDNS builds against. This is due to the upstream FREEBSD PORT being modified. Opnsense UNBOUND version is still 1.7.3 - This caused a problem on both my Opnsense and Pfsense installations of GETDNS.
Finally - I had an old copy of GETDNS 1.4.2 - and I used that and everything worked fine. So, remember you are really compiling these packages - and a lot depends on what is in the upstream repositories - much of this is beyond our control.
So - save a package like I did on a USB stick or something just in case they change the FREEBSD ports due to a package upgrade. remember this is FREEBSD package - not Opnsense - as even Opnsense ports are synced with FREEBSD PORTS.
Lastly, maybe I was wrong about " safestack " being on the initial GETDNS " make config " screen. However, safestack does appear while compiling GETDNS dependencies.
Peace -
directnupe
-
just to let people know, if you upgrade to latest version of opnsense you will looe stubby.
they updated unbound to 1.8.1 and after update the binary for stubby gets deleted
-
Dear Nekromantik,
SEE POST HERE FOR THE SOLUTION :
https://forum.opnsense.org/index.php?topic=10062.0
Dear Community -
ALWAYS READ ENTIRE GUIDE FIRST BEFORE BEGINNING FOR BEST RESULTS
Some folks are dreading that upgrading to Opnsense 18.7.6 which ships with UNBOUND 1.8.1 breaks GETDNS and STUBBY. It ain't necessarily so ! Here are the solutions :
SECTION A
For Opnsense Ports Installation of GETDNS and STUBBY
1- If you installed GETDNS and STUBBY using Opnsense Ports - see this post :
https://forum.opnsense.org/index.php?topic=8748.0
The KEY is to remove GETDNS and STUBBY and all of the configuration files BEFORE YOU UPGRADE !
2 - Then upgrade to Opnsense 18.7.6 which will install UNBOUND 1.8.1
3 - Now re-install the upgraded GETDNS STUBBY port - which is now getdns-1.4.2_1 - this will compile being built against UNBOUND 1.8.1 - this is why the port was upgraded - that being to work with UNBOUND 1.8.1 - getdns-1.4.2 was for UNBOUND 1.7.3 and - well - you get the picture if not check the screenshot below and / or go here: https://www.freshports.org/dns/getdns/ Note: Pay particular attention to this entry:
18 Sep 2018 18:24:05
Original commit files touched by this commit 1.4.2_1
Revision:480056
dns/unbound: update to 1.8.0
Bump PORTREVISION on to consumers due to library major version change
For instance I have a PfSense 2.4.4 Edge Router set up and it uses UNBOUND 1.7.3 and getdns 1.4.2_1 will break UNBOUND - as getdns 1.4.2 is what it needs. getdns 1.4.2_1 has different library requirements which are not suitable for UNBOUND 1.7.3 - so DNS resolution fails. This why you need to upgrade getdns on Opnsense 18.7.6 as it ships with UNBOUND 1.8.1.
4 - After your upgrade your port installation to getdns-1.4.2_1 All you need to do is refer to the original post here once again: https://forum.opnsense.org/index.php?topic=8611.0 - begin with Step 7 and follow each step from there and you will be up and running with getdns-1.4.2_1 and UNBOUND 1.8.1 on OpnSense 18.7.6
SECTION B
For those who use STAND ALONE DNS OVER TLS STUBBY GETDNS PACKAGE
1 - It is necessary to reconfigure Unbound to stop using Stubby for DNS resolution. Go to System > Settings > General > and Check
option - A - Allow DNS server list to be overridden by DHCP/PPP on WAN ( Click Save ) . Then go to Services > Unbound DNS > General and then remove contents of Custom Options Box:
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053
Save and apply
2- After this you must delete the GETDNS package from Opnsense BEFORE YOU UPGRADE to 18.7.6
First - issue command - pkg delete getdns
You do that ( from command line ) then follow these commands to remove configuration files.
Remove the following files by issuing these commands: # rm /usr/local/etc/rc.d/stubby.sh
# rm /usr/local/etc/stubby/stubby.yml and
# rm /etc/rc.conf.d/stubby
3- Now upgrade to OpnSense 18.7.6 along with UNBOUND 1.8.1
Now all you need to do now is build and install your new package getdns-1.4.2_1.txz
You do that by following the guide here - https://forum.opnsense.org/index.php?topic=8759.0
As Opnsense Tools installs FREEBSD synced ports on your FREEBSD Build Server - you will also get
getdns-1.4.2_1 - which is designed to work with UNBOUND 1.8.1
After you have built your getdns-1.4.2_1.txz package on your FREEBSD BUILD SERVER- go to Step 8
Special Circumstances:
If you already have an existing FREEBSD Build Server and an outdated getdns port on it then you must remove that getdns port before building a new one. In order to accomplish that task see here : https://forum.opnsense.org/index.php?topic=8748.0 and follow and complete Step 1 and Step 2 . Now , since Opnsense Tools is already installed on your existing FREEBSD BUILD SERVER you need to update your ports collection. You do that by following these two steps: A - cd /usr/tools and B - make update - It that simple. After the ports collection and everything is updated, you proceed thusly:
1 - Go to this page : https://forum.opnsense.org/index.php?topic=8759.0 and complete procedures Step 6 and Step 7
2 - After creating your getdns-1.4.2_1.txz package on your FREEBSD BUILD SERVER simply go to Section B above in this tutorial and follow Steps 1, 2, and 3** in order to get your OpnSense Box up and running with getdns-1.4.2_1 and UNBOUND 1.8.1 on OpnSense 18.7.6
**( obviously you can skip creating another getdns-1.4.2_1.txz package in Step 3 as you have already done so earlier on in this process )
END PART B
The two major things to remember are to to either de-install the GetDns port or delete the GETDNS package PRIOR to upgrading to Opnsense 18.7.6
Then upgrade port or build and re-install upgraded package depending on which method you first used to deploy GETDNS and STUBBY on your OpnSense box.
I hope this helps and I have done this myself and it is GUARANTEED to work!
Peace,
directnupe
Parting Thoughts:
For those who in the future may worry about GETDNS and STUBBY ever being being broken due to an UNBOUND DNS version being updated or upgraded, let me say this. You were not paying attention when I told you all from the very beginning that :
For all the doubters and naysayers concerning GETDNS and STUBBY - they are developed by NLnet Labs - the same folks who bring us Unbound, NSD, OPENDNSSEC and now GETDNS ( and STUBBY ) see here: https://www.nlnetlabs.nl/ https://www.nlnetlabs.nl/projects/getdns/
So, as NLnet Labs develops both UNBOUND and GETDNS ( along with STUBBY ) I am sure that they will do their best to make sure that both of these work well together. If you notice GETDNS 1.4.2_1 has been out since mid September 2018 as has UNBOUND 1.8.0 The main issue and concern is when is the Distro that are using going to integrate and update these packages. For example, OpenWrt is on Unbound 1.8.2 and GETDNS 1.4.2_2 - while on Pfsense it's Unbound 1.7.3 and GETDNS 1.4.2
See here for further info: https://repology.org/metapackage/getdns/versions - even for FREEBSD - it lists the Maintainer as zi@freebsd.org which is correct but lists GETDNS version as 1.4.2 - which is incorrect. We know that the current version for FREEBSD ports is GETDNS 1.4.2_1 - The major point is that NLnet Labs is running " The Whole GETDNS STUBBY / UNBOUND Show " - so that is a good thing that one developer is handling all components needed for DNS OVER TLS ( aka DNS Privacy Project ).
Notice that this Commit was Submitted by jaap@NLnetLabs.nll (maintainer) in order to fix GETDNS so that it will work with new dns/unbound: update to 1.8.0 - which proves that NLnetLabs.nl is actively involved with development and maintenance of UNBOUND GETDNS and STUBBY
See here for FREEBSD GETDNS COMMIT FOR UNBOUND 1.8.1:
-
thanks
how do you confirm you are running 1.4.2_1 and not 1.4.2?
-
Dear Nekromantik,
Hello and you are welcome. As far as your question how do you confirm you are running 1.4.2_1 and not 1.4.2?
the answer is that when you first go to configure GETDNS it will indicate the version. Also, the version of GETDNS on OpnSense and FreeBSD Ports is 1.4.2_1
So you could not install 1.4.2 even if you wanted to because it is no longer in the upstream FrreBsd or Opnsense repositories.
Just do it ! The way to check the version of any package installed or available in any FREEBSD Distro - is to to tyoe - pkg info - this command will list all packaged you have installed. To see a specific program - you add the package name to the command - for example in this case - pkg info getdns which will give you all the package release information and also let you know what version is installed on your Opnsense instance. Or which version of getdns is available for you to install in your repos. You will not find GETDNS in Opnsense default repos - that is why we must use Ports and or build getdns package through ports in order to install getdns and stubby.
Peace and God Bless,
directnupe
-
I have read the whole thread but my question is that Is Changing DNS Server Settings is still working? I have found the solution and if I Reset IP Configuration I resolved the issue easily. Is it useful to do?
Resource Link: https://validedge.com/dns_probe_finished_bad_config/ (https://validedge.com/dns_probe_finished_bad_config/)
-
A more lightweight approach to DNS-over -TLS is described here:
https://forum.opnsense.org/index.php?topic=7811.0
Working fine with openSSL, needs some care on 19.1.4 with LibreSSL
https://forum.opnsense.org/index.php?topic=11657.msg55526#msg55526
-
I had been using what is described in:
https://forum.opnsense.org/index.php?topic=7811.0
since it was proposed and it worked fine until 19.1.4 and 19.1.5, but now results in DNS leaks while using VPN. The logs actually look OK, but various DNS leak test fail. I even rebuilt unbound 1.8.1 manually as proposed in the other thread but that didn't change anything. I really liked using this DNS TLS stuff, but I need to get rid of it just to fix the leak.
-
Hi all,
Using this guide, I am trying to get Stubby / GetDNS running on my machine but I have come across an issue in step # 3 which is preventing me from going further.
My fresh install:
OPNsense 19.1.10-amd64
FreeBSD 11.2-RELEASE-p10-HBSD
OpenSSL 1.0.2s 28 May 2019
Unbound 1.9.2
This is the step I am having problems with:
Step 3: - Proceed and complete Opnsense Ports install with the following commands: ( Note that is designed for Opnsense 18.7 Variants; however, I believe that it will work with all Opnsense versions - but I have not tested that proposition. )
# cd /etc
# fetch https://raw.githubusercontent.com/opnsense/tools/master/config/18.7/make.conf
Returns the following errors:
root@OPNsense:~ # cd /etc
root@OPNsense:/etc # fetch https://raw.githubusercontent.com/opnsense/tools/master/config/19.1/make.conf
fetch: https://raw.githubusercontent.com/opnsense/tools/master/config/19.1/make.conf: No address record
root@OPNsense:/etc # fetch https://raw.githubusercontent.com/opnsense/tools/master/config/19.1/make.conf
fetch: https://raw.githubusercontent.com/opnsense/tools/master/config/19.1/make.conf: No address record
As can be seen, I tried modifying the path provided in the guide but it won't work in the command line. I am not sure what is wrong. Perhaps I have missed something with all the changes.
Help please!
-
Step 1: fix your internet connectivity.
Step 2: # pkg install getdns
Step 3: (already done installing)
Cheers,
Franco
-
Hey franco,
Many thanks for your help.
I managed to get all the way through the installation phase. It's a shame the mods to this section didn't provide an update to compliment the excellent guide(s) written by @directnupe.
Now I am just trying to figure out how to select localhost on the interfaces section when the option to select it is no longer there! Another change perhaps??
Many thanks,
Amanaki