OPNsense Forum
English Forums => Tutorials and FAQs => Topic started by: directnupe on October 13, 2021, 06:42:51 pm
-
Dear Community,
First you all know the drill by now - " The Intro " - two throwbacks - https://www.youtube.com/watch?v=m5FCcDEA6mY - lyrics - https://genius.com/Neil-young-southern-man-lyrics - and don't you know - https://www.youtube.com/watch?v=wkA7ok5MySk - https://genius.com/Funkadelic-if-you-dont-like-the-effects-dont-produce-the-cause-lyrics - OK - now that our long standing tradition of public elucidation has been fulfilled - let's get down to the business at hand.
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 predate 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. However, there has been a minor change ( yet little known ) in UNBOUND on OPNsense 21.7.1 with regard to configure it to work with Stubby for DNS Privacy DNS OVER TLS. So, let's get started strait away. See here for previous more in depth guide concerning the benefits of DNS Privacy : https://bit.ly/3j0QT1l
So here we go. So go ahead and issue command :
A - # pkg install getdns
in order to get started. After installing getdns which includes stubby follow the steps below.
1 - 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:
A - # su -m unbound -c /usr/local/sbin/unbound-anchor Then -
B - Issue this command : # mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh
Make it executable - I run this command - it works for me:
C - # chmod 755 /usr/local/etc/rc.d/stubby.sh
D - Yes must enable Stubby Daemon in the file - open file by :
E - # 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 already configured. Save and exit.
2 - Now you must configure Stubby to resolve DNS OVER TLS - enter command below :
A -# nano /usr/local/etc/stubby/stubby.yml - make your file match some thing similar to this
################################################################################
######################## STUBBY YAML CONFIG FILE ###############################
################################################################################
# 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).
#
# For more information see
# https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby
#
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
idle_timeout: 9000
listen_addresses:
- 127.0.0.1@8053
- 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"
dnssec_trust_anchors: "/usr/local/etc/unbound/root.key" # add the right path
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
- address_data: 2a04:b900:0:100::38
tls_auth_name: "getdnsapi.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
## 2 - The Surfnet/Sinodun DNS TLS Servers #3 A+ ( NLD )
- address_data: 145.100.185.18
- address_data: 2001:610:1:40ba:145:100:185:18
tls_port: 853
tls_auth_name: "dnsovertls3.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=
## xx - The The Surfnet/Sinodun DNS TLS Server A ( NLD )
- address_data: 145.100.185.15
- address_data: 2001:610:1:40ba:145:100:185:15
tls_auth_name: "dnsovertls.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
## xx - The The Surfnet/Sinodun DNS TLS Server #1 A ( NLD )
- address_data: 145.100.185.16
- address_data: 2001:610:1:40ba:145:100:185:16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
## 3 - The dns.cmrg.net DNS TLS Server A+ ( CAN )
- address_data: 199.58.81.218
- address_data: 2001:470:1c:76d::53
tls_auth_name: "dns.cmrg.net"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
## 4 - The BlahDNS Japan DNS TLS Server A+ ( JPN )
- address_data: 139.162.112.47
- address_data: 2400:8902::f03c:92ff:fe27:344b
tls_auth_name: "dot-jp.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: /llFOsnvj7GcXasKrojhZl6nRnnn4D8sRuDUKEdiZzM=
## xx - The BlahDNS German DNS TLS Server A+ ( USA Hosted In DEU )
- address_data: 78.46.244.143
- address_data: 2a01:4f8:c17:ec67::1
tls_auth_name: "dot-de.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: c6xmf1GsYo1IFyxc+CWfjYo+xpSV9i98H7InJTDylsU=
## xx - The BlahDNS Finland DNS TLS Server A+ ( FIN )
- address_data: 95.216.212.177
- address_data: 2a01:4f9:c010:43ce::1
tls_auth_name: "dot-fi.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: EVL610kmcSvN01nzJkkzl94IHiIVvW0PovbB5En2QfU=
## xx - The BlahDNS Singapore DNS TLS Server A+ ( SGP )
- address_data: 192.53.175.149
- address_data: 2400:8901::f03c:92ff:fe27:870a
tls_auth_name: "dot-sg.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: B+aX4NBLfDsKlOWf8RM6rjL8yOCF9sZlHQnarDNrrWM=
## xx - The BlahDNS Switzerland DNS TLS Server A+ ( CHE )
- address_data: 45.91.92.121
- address_data: 2a05:9406::175
tls_auth_name: "dot-ch.blahdns.com"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: cxti1XR6uW483xAioP3d1ZaoGSy+obY6WaE4fW1A6Nk=
## 5 - 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=
## 6 - The Foundation for Applied Privacy DNS TLS Server #1 A+ ( AUT )
- address_data: 146.255.56.98
- address_data: 2a02:1b8:10:234::2
tls_auth_name: "dot1.applied-privacy.net"
tls_port: 443
tls_pubkey_pinset:
- digest: "sha256"
value: xhQVPE+X85b9LkORuEhxfsxE1X2EbOm8v5ytxCqg5BI=
## 7 - 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: Am37BK5eBKSafYNJupWsoh5pokR3wwJ5zs7xvniF6XE=
## 8 - 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=
## xx - 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=
## 9 - 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/
## 10 - The ibksturm.synology.me DNS TLS Server A+ ( CHE )
- address_data: 213.196.191.96
tls_auth_name: "ibksturm.synology.me"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yrMslOFXpWeLoNw0YgQk/pA5vl2mqXfBOASYLLeqDxc=
## 11 - 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: b9sJFKc+wycfm4FHB9ddNopdeKceru+sZk0w5nz4xfQ=
### Publicly Available DOT Test Servers ###
## 12 - 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: ugm6mY2NNKi0I/Q+pofAgx0c31tbcW6xYAImZXr5Oqo=
## 13 - 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: sS2Atff8wMigRVTxmS36FbMaXiCWsxLgD3AOtTA9eeU=
## xx - 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: /jchI7afFvSaVm4DCTksJcPHyK7uvbcwNUtTNNV4Bek=
## 14 - 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=
## xx - 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: /3AxvvuWCQmYQ4/mqHJzPL1rPC7KxaahVPmUkoSVR5A=
## 15 - The Digitale Gesellschaft DNS TLS Server #1 A+ ( CHE )
- address_data: 185.95.218.43
- address_data: 2a05:fc84::43
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: sAH7JR5A8WA+hs1ZGXPS/uq3Y1wufBi2wQ8Crk+oR2Q=
## xx - The Digitale Gesellschaft DNS TLS Server #2 A+ ( CHE )
- address_data: 185.95.218.42
- address_data: 2a05:fc84::42
tls_auth_name: "dns.digitale-gesellschaft.ch"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: Fpgt86sGjlL4sbgNmd1WX0BYEIEJ7yQk9rp+uQKxI+w=
## 16 - 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: Dn58VD18MLkmmG9wvzvSs30Tu1Rd65igDLpp1odYaAc=
# 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
When I get some time - next day or two - I will post a separate Forum entry which lists
many more DNS OVER TLS servers that are publicly available for. However, these are more than
enough to get you started.
3 - In order to have OPNsense 21.7.1 use default start up script ( /usr/local/etc/rc.d/stubby.sh )
at boot time it helps 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 755 /etc/rc.conf.d/stubby
4 - Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
This is where there has been a ( major ) change to UNBOUND on OPNsense 21.7.1 .
The bottom line is that there is no longer any option whatsoever for you
to configure UNBOUND Custom Options via OPNsense 21.7.1 WEBGUI.
A - See here for the changes - https://bit.ly/3vfx1MT - then scroll down to Advanced Configurations.
There you may read about the changes I alluded to earlier.
So here is how we go about configuring Unbound/Stubby combination for OPNsense 21.7.1
Some user combine Unbound (as a caching proxy with other features such as DNS Blacklisting)
and Stubby (as fully featured TLS forwarder). This is what we are out to achieve.
Advanced Configurations
Some installations require configuration settings that are not accessible in the UI. To support these,
individual configuration files with a .conf extension can be put into the
/usr/local/etc/unbound.opnsense.d directory.
Now theoretically - you should be able to create the need file by doing the following below :
B - # touch /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
C - # nano /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
enter the following in the new file as detailed below :
####################################################
### Unbound Advanced Configuration
server:
tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt"
hide-trustanchor: yes
harden-glue: yes
harden-dnssec-stripped: yes
num-threads: 4
rrset-cache-size: 256m
msg-cache-size: 128m
so-rcvbuf: 1m
val-clean-additional: yes
minimal-responses: yes
harden-referral-path: yes
aggressive-nsec: yes
prefetch: yes
qname-minimisation: yes
qname-minimisation-strict: yes
rrset-roundrobin: yes
target-fetch-policy: "0 0 0 0 0"
max-udp-size: 3072
harden-below-nxdomain: yes
ip-ratelimit: 300
ip-ratelimit-factor: 10
incoming-num-tcp: 100
edns-buffer-size: 1472
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053
forward-addr: 0::1@8053
##################################################
*** Note that the file you create must end in .conf in order to be automatically
included by the UI generated configuration. Also, Name collisions with plugin code,
which use this extension point e. g. dnsbl.conf, may occur. So be sure to use a unique filename.
unbound_srv.conf is a unique filename on OPNsense 21.7.1 for sure - trust me.
5 - Now, I have one caveat - when I created this file ( as described above ) via SSH - there was
an issue where DNS OVER TLS did not work at all or as it should - the resolvers did not connect.
Perhaps the file needs permissions - you can try -
chmod 664 /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
and see how this works out for you
GUARANTEED SOLUTION:
What I did was use WINSCP in order to have this setup perform as intended. Use your
favorite text editor ( I use EditPad Pro ) and copy Unbound Advanced Configuration above -
into a new file labeled - unbound_srv.conf - Save this file to a local directory on your
computer. Next, follow the steps below :
A - WINSCP into your OPNsense 21.7.1 Firewall via SFTP protocol - SCP will not
connect on OPNsense. Make sure to use SFTP protocol.
Go into ( open ) the directory below on the right side of WINSCP interface :
/usr/local/etc/unbound.opnsense.d/
B - Go into the directory on your computer where you have the unbound_srv.conf file
which you previously created and filled out with the Unbound Advanced Configuration.
This will be on the left side of WINSCP.
C - Drag and Drop unbound_srv.conf ( on the left side of WINSCP ) into the
/usr/local/etc/unbound.opnsense.d/unbound_srv.conf ( directory which is open )
on the right side of of WINSCP. Done - close and exit
This WINSCP method is GUARANTED to work !!! - I strongly suggest that you choose to
make this your preferred Unbound Advanced Configuration option for OPNsense 21.7.1 !!!
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Easiest Method To Bring Back Unbound Advanced Configuration
For OPNsense 21.7.1 WEBGUI Special Thanks to
cookiemonster from the OPNsense forum.
You can add the mimugmail / opn-repo to your OPNsense 21.7.1 Firewall
found here ( https://tinyurl.com/4r4xdrtp ) see details below :
A - # fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.conf
B - # pkg update
Then either add plugin os-unboundcustom-maxit from WEBGUI
C - or issue command # pkg install os-unboundcustom-maxit
Then go to Services > Unbound DNS > Custom Options - you may enter your
Unbound Advanced Configuration entries here - enable Custom Options -
then restart Unbound DNS and then issue command
F - # /usr/local/etc/rc.d/stubby.sh restart
FYI - os-unboundcustom-maxit plugin while adding Custom Options to WEBGUI - creates
a file named custom-maxit.conf in the /usr/local/etc/unbound.opnsense.d/ directory
ALTERNATE METHOD TO INSTALL mimugmail /opn-repo
Sometimes you may get an error with fetch command ( SSL ) when trying to add
mimugmail /opn-repo . This is a workaround to add mimugmail /opn-repo manually.
touch /usr/local/etc/pkg/repos/mimugmail.conf
nano /usr/local/etc/pkg/repos/mimugmail.conf
Then enter the contents contained between the lines below :
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
mimugmail: {
url: "https://opn-repo.routerperformance.net/repo/${ABI}",
priority: 190,
enabled: yes
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Next after manually adding mimugmail /opn-repo to OPNsense 21.7.1
continue as normal :
# pkg update
# pkg install os-unboundcustom-maxit
You are then all set
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
6 - Next -Under System > Settings > General Settings
A - Set the first DNS Server to 127.0.0.1 with no gateway selected /
Make sure that DNS server option
B - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked !
and DNS server option
C - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked !
D - Save and Apply
Reboot your router or run command # /usr/local/etc/rc.d/stubby.sh restart
You are all set up and now. You are now running DNS OVER TLS with GETDNS plus STUBBY
( a fully featured TLS forwarder ) along with an Unbound DNS Caching Server.
-
Thank you for keeping posting these directnupe.
I have used your previous post as the basis for my setup. It was and still is, very useful.
One note in case you've missed it. For point 4 with the Unbound advanced configuration, an alternative is to install the mimugmail repo and plugin os-unboundcustom-maxit . Once installed, we can add the advanced options there.
Your recommended method is more aligned with the OPN recommended ways so it's just an alternative.
P.S. SCP does work without problem, it is a standard *nix facility. I guess for windows users winscp makes it easier and *nix users won't have an unsolvable problem with it. If you want, I can help you troubleshoot separately the issue you encountered.
-
Dear cookiemonster,
Hello and I hope that you are both safe and well. Thank you for your kind words, and I appreciate you telling me about mimugmail / opn-repo and I have added that option to this tutorial. Re:
If you want, I can help you troubleshoot separately the issue you encountered. - well, since everyone should be able to get this working by now - I really do not want to put you out. However, I would like to find out why the SSH commands -
B - # touch /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
C - # nano /usr/local/etc/unbound.opnsense.d/unbound_srv.conf
seem to not work - at least at the time I attempted this
Do you think it has do with file permissions or some issue issue - yes I would like to know - just for future reference.Thanks again for your feedback and kindness
Peace -
directnupe
-
I've Direct-messaged you.
-
Question regarding this configuration, will this survive OPNsense release upgrades and will the stubby package automatically be upgraded if a newer version is available?
-
To start with I am not in any way knocking you for posting these instructions, I'm sure you took a lot of time to write them up and for that you should be commended. But what I find incredible is that you have to go through all this in the first place. I am sorry, but this is just WAAAAAY too difficult for any average user (and maybe some readers think only technically minded people use OPNsense, but that's not necessarily true). This kind of reminds me of the method you had to use to set up an Internet connection back in the very early days of Windows, until Microsoft came out with a version of Windows that made setting up network connectivity relatively painless.
What OPNsense needs is a page specifically for enabling DNS over TLS, that would be used by both OPNsense itself and by any device on the local network that uses the OPNsense IP address for DNS (including devices that use DHCP to get their network connectivity information). And that page should have exactly two things:
- A checkbox to enable or disable DNS over TLS
- A textbox with a list of servers capable of receiving DNS over TLS queries (and/or alternately, checkboxes to enable or disable certain popular and well-known servers)
And that's ALL. If anything else is needed then OPNsense should assume sensible defaults, and not trouble the user about them. For those that simply must have the ability to tweak, you could have an Advanced Settings section, but this should be pre-populated with a working configuration.
Features that are hard to use don't get used, except by a very small minority that actually has the knowledge and patience to use them. OPNsense is really bad about making some features much harder to use than they should be. Another example of this is intrusion detection - that's another one that ideally should be "just click on a checkbox to turn it on and done (unless you really have a burning desire to tweak the advanced settings)." When you need an article this long to explain how to do something that should be drop-dead easy, that's a real design failure. Look at how easy it is to turn on DNS over HTTPS in Firefox - you go to the Network Settings and click one checkbox at the bottom of the Connection Settings pane, and either use the default provider or use a custom one. That's how easy it should be in any decent router software! And I HOPE that is how easy it will be in some future version of OPNsense.
-
Your post seems a bit off topic given that with the 21.7 series, the developers actually added a separate DoT section in Unbound. Input the IP, DNS name, and port and that's it. It doesn't get much easier than that. Both OPNsense and pfSense do a good job at mainstreaming DoT and not having a huge technical barrier in place.
The more complex configuration you see in this thread would be for users that wish to try something a bit more performant than Unbound DoT. Thus we have to setup a separate resolver for DoT and forward internal Unbound queries to that resolver (Stubby/getdns).
The reason this is complicated is that there really isn't a single solution for all of the examples that you give. If you want IPS/IDS, there's no way to know for sure that your traffic will be the same as another use case. That's why a) its complicated to configure and b) you need to know your traffic and device use cases. These cases rarely fit in to the "I just want a checkbox and done" crowd.
-
opnfwb - spot on.
If someone wants to use DoT, OPN devs have done a wonderful job for simplicity.
What makes this post a little long is there is a very long list of resolvers. If we were to see past that, it is very simple. Credit to the OP for making it look simple.
-
Your post seems a bit off topic given that with the 21.7 series, the developers actually added a separate DoT section in Unbound. Input the IP, DNS name, and port and that's it. It doesn't get much easier than that. Both OPNsense and pfSense do a good job at mainstreaming DoT and not having a huge technical barrier in place.
The more complex configuration you see in this thread would be for users that wish to try something a bit more performant than Unbound DoT. Thus we have to setup a separate resolver for DoT and forward internal Unbound queries to that resolver (Stubby/getdns).
The reason this is complicated is that there really isn't a single solution for all of the examples that you give. If you want IPS/IDS, there's no way to know for sure that your traffic will be the same as another use case. That's why a) its complicated to configure and b) you need to know your traffic and device use cases. These cases rarely fit in to the "I just want a checkbox and done" crowd.
Thank you for explaining all that. I took a look at the Unbound configuration and saw what you are talking about, the only thing I don't really understand is that there is a field for "Verify CN" (the help tip is "Verify if CN in certificate matches this value") but I am not sure what you are supposed to put there. If you look at the list of servers in the top post there is nothing indicated as a "CN"; I do see that most have "tls_pubkey_pinset" entries but I assume that's not the same thing.
The other thing is there are no default or suggested entries; in a way I can understand the logic behind that but in the OP's list I see no servers that look even remotely familiar, so basically someone with no experience or background with this is still left scratching their head wondering what to do. What would be ideal for me is to have settings for one or two good DNS over TLS providers in the USA, or somewhere in North America. I'm not necessarily saying they have to be Google (if Google even runs a DNS over TLS server) but it would be nice to not be going to somewhere completely unknown. My goal here is to bypass my ISP's DNS servers, which not only are frequently down, but also if I use those then my ISP can track where I go on the Internet more easily. But I don't want to replace those with something even less reliable, or that may also be tracking where I go and selling that data who knows where, so that why I wish there were some list of recommended DNS over TLS providers and you could select one or more just by clicking a checkbox. Or failing that, a link to an article somewhere that contains that information.
Maybe DNS over TLS is too new, or there really are that few servers that support it, if so I apologize if I am asking for too much, but I am just trying to understand if this is something that is possible. As for the comment about the article being for those "that wish to try something a bit more performant than Unbound DoT", I guess I would say that while I suppose everyone would like maximum performance (however they define that), not everyone has the time, patience, or ability to learn how to tweak things to the very max (that's as true of computer networking as it is of mechanical things such as car engines). I would just be happy if it works reliably and doesn't become a bottleneck to network traffic.
And again, I am not in any way knocking the OP's post, I am sure there are people who like having that level of detail and the ability to fine tune their networks in ways I could never hope to understand.
-
Thank you for explaining all that. I took a look at the Unbound configuration and saw what you are talking about, the only thing I don't really understand is that there is a field for "Verify CN" (the help tip is "Verify if CN in certificate matches this value") but I am not sure what you are supposed to put there. If you look at the list of servers in the top post there is nothing indicated as a "CN"; I do see that most have "tls_pubkey_pinset" entries but I assume that's not the same thing.
With all due respect and I don't mean this negatively but this shows you haven't look in to how DoT works. You'll either need a pinset or ideally, avoid using a pinset and instead have the TLS connection match with the dns name issued to the certificate so that the resolver can verify that the queries are actually coming from an intended source (dns.quad9.net, one.one.one.one, etc. etc.). This is no doubt more complicated than "regular" DNS, but then again so is an Unbound resolver (which OPNsense ships with by default) compared to a dnsmasq based forwarder configuration in most consumer gear.
The other thing is there are no default or suggested entries; ..... Or failing that, a link to an article somewhere that contains that information.
Stubby ships with a default config. The DoT providers that you wish to use will need to be your own decision. It's quite normal to not ship a list of defaults because people may not want them or even worse, they could end up being monetized and not in a user's interest for privacy. Again the rule here is if you're going to enable DoT, you'll need to do a small amount of searching to understand it and make the choice which provider you think has your best interests in mind. I wouldn't expect OPNsense devs, or anyone else for that matter, to do that for me.
Again not trying to sound like a "let me google that for you" post but this is all covered extensively here in the forums over many years (DoT was first launched with an Unbound update back in April 2018).
Basic info here and some config examples (note, the config isn't needed because new OPNsense does that for you with the DoT GUI page): https://www.ctrl.blog/entry/unbound-tls-forwarding.html
A discussion about the two major DoT providers, CloudFlare and Quad9, and additional input from Quad9's management. CloudFlare also posts in that thread with their input.: https://www.snbforums.com/threads/cloud9-dns.56918/
Maybe DNS over TLS is too new, or there really are that few servers that support it, if so I apologize if I am asking for too much, but I am just trying to understand if this is something that is possible. As for the comment about the article being for those "that wish to try something a bit more performant than Unbound DoT", I guess I would say that while I suppose everyone would like maximum performance (however they define that), not everyone has the time, patience, or ability to learn how to tweak things to the very max (that's as true of computer networking as it is of mechanical things such as car engines). I would just be happy if it works reliably and doesn't become a bottleneck to network traffic.
If you just want working and reliable DoT with minimal configuration, the built in DoT GUI page in OPNsense is the way to go. Choose a DoT provider, input their port, IP, DNS name and you're up and running.
You also need to be aware of the differences between a resolver and a forwarder. Anytime you go DoT, you're always putting all of your trust in the provider you choose to forward your queries to. You're essentially abdicating the resolver portion of Unbound and just having it forward all of its queries to a chosen provider. Yes, they will be encrypted so that your ISP can't see them, but the provider can still decrypt and see them. So you're exchanging anonymity at the DNS level for anonymity between your ISP and your DNS traffic.
OPNsense ships by default in resolver mode, which means all of your DNS queries are sent in plaintext so that your ISP (or anyone else) in the middle can potentially see them, but the queries are sent randomly to hundreds of various root servers and the local Unbound service within OPNsense resolves them and caches them. OPNsense also has two easy check boxes during the initial setup to enable DNSSEC in resolver mode, which adds an additional layer of security from the root resolvers (there's those nice check boxes again ;) ) The likelihood that a single DNS provider would be able to get enough metadata on your network activity would be reduced, at the expense of everyone else being able to potentially see it on the wire. It's always a trade off. You need to educate yourself and decide. And yes, most people just give up and use consumer gear or just use the defaults at this stage in the game.
-
EDIT: Never mind, I got a clear and easy to understand explanation in a different part of this forum. I am leaving this post up, but probably won't be checking back for a while so no further response is necessary.
OMG. You sound like a person who, if your child asks why the sky is blue, would haul out a physics textbook... I honestly did not understand half of what you wrote!
I thought I was asking a simple question in my first paragraph. If you set up DNS over TLS in Unbound, there are three fields to fill out (not counting the checkbox that enables it). The first two are pretty much self explanatory, all I was wondering was what are good servers to use in the USA, and you did answer that when you wrote about CloudFlare and Quad9, both of which I have heard of. But my other question was about the "Verify CN" field and in that regard your answer was not at all helpful. No, I haven't looked into how DoT works, because I would not understand anything more than the most superficial of explanations anyway. What I have deduced out is it's more secure than regular DNS (or at least not LESS secure), and it bypasses your ISP's DNS. And that's really all I need to know.
My specific question was in regard to the "Verify CN" field. This seems to be something newly added in OPNsense and all I really need to know is if it's necessary to put anything in that field, and if so, what. I really don't need a long technical explanation. With all due respect, your reply was rather condescending and pretty much designed to tell me what an idiot I am when it comes to this stuff. Well, I already know I'm an idiot when it comes to this, if I weren't then I wouldn't need to ask this question. But it just astounds me that you would make the effort to write all that verbiage and still not answer the one simple question of what, if anything, I need to put in the "Verify CN" field (assuming I am going to use CloudFlare and Quad9). And yes, I am aware that they can see my DNS queries, but I'd rather have them seeing them than my ISP, particularly if their servers are more reliable (which is a pretty low bar). But then again, can't any DNS over TLS provider that you might use see your queries?
As for your last paragraph, you said "OPNsense ships by default in resolver mode, which means all of your DNS queries are sent in plaintext so that your ISP (or anyone else) in the middle can potentially see them, but the queries are sent randomly to hundreds of various root servers and the local Unbound service within OPNsense resolves them and caches them." And I am guessing you think that's a GOOD thing. What if I don't want my DNS queries sent to random root servers all over the globe, particularly in plaintext? I do not see how that is in any way an advantage. Honestly, I read everything you wrote, and understood some of it, but really wish you'd skipped most of that and just told me about the CloudFlare and Quad9 servers (thank you for that, at least), and what to put in that "Verify CN" field, if I need to put anything at all there.
-
With regard to plaintext resolver queries, I don't think that's a good or bad thing. Just something you'll need to decide. Plenty of people use plaintext queries with DNSSEC and it just works. I included that detail because you seem concerned with having to put too much technical effort or understanding in to any of this. And that (default) solution out of the box fits most of your requests perfectly a)easily implemented/default b)checkbox for additional security (DNSSEC) c)doesn't rely on the ISPs DNS.
If you do nothing else, at least read the snbforums thread comparing the two DNS providers and you'll get a much better understanding for how Quad9 and CloudFlare DNS operate as a business. For me personally, that thread made the decision of choosing a DoT provider much easier. Also the first link I posted (ctrl.blog) has the reasoning for why we'd want to use the CN plus the IP address and port for DoT.
-
Question regarding this configuration, will this survive OPNsense release upgrades and will the stubby package automatically be upgraded if a newer version is available?
The answer to will this survive OPNsense release upgrades is
YES
The answer to will the stubby package automatically be upgraded if a newer version is available is
NO
However, getdns and stubby on FreeBSD have not been updated / upgraded for a couple of years - why not - I have no idea. Check out my new tutorial OPNsense AdGuardHome TOTAL CONTROL MODE ! ( DOQ )
found here : AdGuardHome is DOH DOT and DOQ supported
Peace
-
opnfwb - spot on.
If someone wants to use DoT, OPN devs have done a wonderful job for simplicity.
What makes this post a little long is there is a very long list of resolvers. If we were to see past that, it is very simple. Credit to the OP for making it look simple.
Thanks cookiemonster for the defense - check out my new work
https://forum.opnsense.org/index.php?topic=25614.0
-
Question regarding this configuration, will this survive OPNsense release upgrades and will the stubby package automatically be upgraded if a newer version is available?
The answer to will this survive OPNsense release upgrades is
YES
The answer to will the stubby package automatically be upgraded if a newer version is available is
NO
However, getdns and stubby on FreeBSD have not been updated / upgraded for a couple of years - why not - I have no idea. Check out my new tutorial OPNsense AdGuardHome TOTAL CONTROL MODE ! ( DOQ )
found here : AdGuardHome is DOH DOT and DOQ supported
https://forum.opnsense.org/index.php?topic=25614.0
Peace
-
To start with I am not in any way knocking you for posting these instructions, I'm sure you took a lot of time to write them up and for that you should be commended. But what I find incredible is that you have to go through all this in the first place. I am sorry, but this is just WAAAAAY too difficult for any average user (and maybe some readers think only technically minded people use OPNsense, but that's not necessarily true). This kind of reminds me of the method you had to use to set up an Internet connection back in the very early days of Windows, until Microsoft came out with a version of Windows that made setting up network connectivity relatively painless.
What OPNsense needs is a page specifically for enabling DNS over TLS, that would be used by both OPNsense itself and by any device on the local network that uses the OPNsense IP address for DNS (including devices that use DHCP to get their network connectivity information). And that page should have exactly two things:
- A checkbox to enable or disable DNS over TLS
- A textbox with a list of servers capable of receiving DNS over TLS queries (and/or alternately, checkboxes to enable or disable certain popular and well-known servers)
And that's ALL. If anything else is needed then OPNsense should assume sensible defaults, and not trouble the user about them. For those that simply must have the ability to tweak, you could have an Advanced Settings section, but this should be pre-populated with a working configuration.
Features that are hard to use don't get used, except by a very small minority that actually has the knowledge and patience to use them. OPNsense is really bad about making some features much harder to use than they should be. Another example of this is intrusion detection - that's another one that ideally should be "just click on a checkbox to turn it on and done (unless you really have a burning desire to tweak the advanced settings)." When you need an article this long to explain how to do something that should be drop-dead easy, that's a real design failure. Look at how easy it is to turn on DNS over HTTPS in Firefox - you go to the Network Settings and click one checkbox at the bottom of the Connection Settings pane, and either use the default provider or use a custom one. That's how easy it should be in any decent router software! And I HOPE that is how easy it will be in some future version of OPNsense.
See if this is simple enough for you
https://forum.opnsense.org/index.php?topic=25614.0
and if command line work is to daunting a task for you - you can configure AdGuardHome through WEBGUI
Peace
-
Thank you for explaining all that. I took a look at the Unbound configuration and saw what you are talking about, the only thing I don't really understand is that there is a field for "Verify CN" (the help tip is "Verify if CN in certificate matches this value") but I am not sure what you are supposed to put there. If you look at the list of servers in the top post there is nothing indicated as a "CN"; I do see that most have "tls_pubkey_pinset" entries but I assume that's not the same thing.
With all due respect and I don't mean this negatively but this shows you haven't look in to how DoT works. You'll either need a pinset or ideally, avoid using a pinset and instead have the TLS connection match with the dns name issued to the certificate so that the resolver can verify that the queries are actually coming from an intended source (dns.quad9.net, one.one.one.one, etc. etc.). This is no doubt more complicated than "regular" DNS, but then again so is an Unbound resolver (which OPNsense ships with by default) compared to a dnsmasq based forwarder configuration in most consumer gear.
The other thing is there are no default or suggested entries; ..... Or failing that, a link to an article somewhere that contains that information.
Stubby ships with a default config. The DoT providers that you wish to use will need to be your own decision. It's quite normal to not ship a list of defaults because people may not want them or even worse, they could end up being monetized and not in a user's interest for privacy. Again the rule here is if you're going to enable DoT, you'll need to do a small amount of searching to understand it and make the choice which provider you think has your best interests in mind. I wouldn't expect OPNsense devs, or anyone else for that matter, to do that for me.
Again not trying to sound like a "let me google that for you" post but this is all covered extensively here in the forums over many years (DoT was first launched with an Unbound update back in April 2018).
Basic info here and some config examples (note, the config isn't needed because new OPNsense does that for you with the DoT GUI page): https://www.ctrl.blog/entry/unbound-tls-forwarding.html
A discussion about the two major DoT providers, CloudFlare and Quad9, and additional input from Quad9's management. CloudFlare also posts in that thread with their input.: https://www.snbforums.com/threads/cloud9-dns.56918/
Maybe DNS over TLS is too new, or there really are that few servers that support it, if so I apologize if I am asking for too much, but I am just trying to understand if this is something that is possible. As for the comment about the article being for those "that wish to try something a bit more performant than Unbound DoT", I guess I would say that while I suppose everyone would like maximum performance (however they define that), not everyone has the time, patience, or ability to learn how to tweak things to the very max (that's as true of computer networking as it is of mechanical things such as car engines). I would just be happy if it works reliably and doesn't become a bottleneck to network traffic.
If you just want working and reliable DoT with minimal configuration, the built in DoT GUI page in OPNsense is the way to go. Choose a DoT provider, input their port, IP, DNS name and you're up and running.
You also need to be aware of the differences between a resolver and a forwarder. Anytime you go DoT, you're always putting all of your trust in the provider you choose to forward your queries to. You're essentially abdicating the resolver portion of Unbound and just having it forward all of its queries to a chosen provider. Yes, they will be encrypted so that your ISP can't see them, but the provider can still decrypt and see them. So you're exchanging anonymity at the DNS level for anonymity between your ISP and your DNS traffic.
OPNsense ships by default in resolver mode, which means all of your DNS queries are sent in plaintext so that your ISP (or anyone else) in the middle can potentially see them, but the queries are sent randomly to hundreds of various root servers and the local Unbound service within OPNsense resolves them and caches them. OPNsense also has two easy check boxes during the initial setup to enable DNSSEC in resolver mode, which adds an additional layer of security from the root resolvers (there's those nice check boxes again ;) ) The likelihood that a single DNS provider would be able to get enough metadata on your network activity would be reduced, at the expense of everyone else being able to potentially see it on the wire. It's always a trade off. You need to educate yourself and decide. And yes, most people just give up and use consumer gear or just use the defaults at this stage in the game.
Thanks for taking the time and patience to try to explain things to do guy. God Bless You. Check out my new work :
https://forum.opnsense.org/index.php?topic=25614.0
Peace
-
@directnupe first of all, great job for the nice guide !
Quick one: I noticed in both Stubby config file and Unbound conf file, you mentioned the round robin mechanism: is it necessary or perhaps is redundant?
Tia.
-
Probably too late but to your question, it is optional.
In roundrobin, stubby will distribute the calls to the different resolvers. Of course it assumes more than one.
If roundrobin off, it would only move to another resolver if one fails.
-
Reading through this partially answered may questions, so the only difference between this and the built in method is speed? You can do all of this using unbound, is the point of this a speed increase, and if so, what kind of increase do you see? Thank you!