pfSense DNS OVER TLS UPDATED NOW ! DEAD SIMPLE
-
Dear Community,
I noticed on https://www.freshports.org/dns/getdns/ that ever since getdns 1.5.2_1 - stubby is included in the package by default. PLEASE TAKE SPECIAL NOTE UNDER Commit History : - Update to 1.5.2 - Build with STUBBY by default due to popular demand. This got me to thinking about how to install DNS Privacy DNS OVER TLS on pfSense ( Special Thanks and Kudos to Ryan Steinmetz aka zi - the port maintainer and developer getdns on FreeBSD ). This is an updated guide / tutorial which explains how to setup adding DNS-Over-TLS support for pfSense - Please disregard and do not use any guides and / or tutorials which pre-date this one which covers installation and configuration of DNS Privacy on pfSense FireWall.1 - There are four dependency packages required before actually installing the getdns package. Two are available in the pfSense package repositories and two from the FreeBSD repository. Lastly the getdns package itself is also in the FreeBSD repository. So to begin enter these commands below in the order :
A # pkg install libuv B # pkg install libyaml - Go to https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/ as pfSense is based on FreeBSD 11 - C # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libev-4.24,1.txz D # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/libidn-1.35.txz Lastly, install getdns along with stubby E # pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/getdns-1.5.2_1.txz
GetDNS and Stubby are now installed on pfSense FireWall. In order to configure UNBOUND along with stubby ( and getdns ) follow the steps below.
1 - Now Ryan Steinmetz aka zi - the port maintainer and developer of this port was kind enough to include a start up script ( stubby.in ) for this package. See the stubby.in here in the raw : https://svnweb.freebsd.org/ports/head/dns/getdns/files/stubby.in?view=markup. All I had to do was ask him and he did for any and all who elect to use this great piece of FreeBSD software.
2 - Now to put all of this together, The stubby.in file is located here - /usr/local/etc/rc.d/stubby by default. First though Stubby needs Unbound root.key - run this command before getting started:# su -m unbound -c /usr/local/sbin/unbound-anchor Then - A - Issue this command : # mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh Make it executable - I run two commands - it works for me: # chmod 744 /usr/local/etc/rc.d/stubby.sh # chmod a+x /usr/local/etc/rc.d/stubby.sh B - Yes must enable Stubby Daemon in the file - open file by : nano /usr/local/etc/rc.d/stubby.sh go to line 27 - : ${stubby_enable="NO"} change the setting to : ${stubby_enable="YES"} - that is all you have to do to this file. It comes pre-configured. Save and exit.
Now you must configure Stubby to resolve DNS OVER TLS - nano /usr/local/etc/stubby/stubby.yml
VERY IMPORTANT UPDATE: After checking, rechecking and the triple checking on this website mentioned above : https://www.immuniweb.com/ssl/?id=Su8SeUQ4 I have made some very serious discoveries regarding which DNS Privacy Test Servers to use. The bottom line that I strongly suggest you only choose to deploy servers which support the TLSv1.3 protocol. See here for information and importance of TLSv1.3 : https://kinsta.com/blog/tls-1-3/
I will save you some considerable leg work and post below the best configuration for your stubby.yml file. Here it is:nano /usr/local/etc/stubby/stubby.yml resolution_type: GETDNS_RESOLUTION_STUB dns_transport_list: - GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED dnssec_return_status: GETDNS_EXTENSION_TRUE tls_query_padding_blocksize: 128 edns_client_subnet_private : 1 idle_timeout: 60000 listen_addresses: - 127.0.0.1@8069 tls_connection_retries: 5 tls_backoff_time: 900 timeout: 2000 round_robin_upstreams: 1 tls_ca_path: "/etc/ssl/" upstream_recursive_servers: # IPV4 Servers ### DNS Privacy Test Servers ### #The DNS Warden DNS TLS Primary Server uncensored-dot.dnswarden.com - address_data: 116.203.70.156 tls_auth_name: "uncensored-dot.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= #The DNS Warden DNS TLS Secondary Server adblock-dot.dnswarden.com - address_data: 116.203.35.255 tls_auth_name: "uncensored-dot.dnswarden.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: aPns02lcGrDxnJQcRSHN8Cfx0XG+IXwqy5ishTQtzR0= ### Test servers ### #The BlahDNS German DNS TLS Server - address_data: 159.69.198.101 tls_auth_name: "dot-de.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: sYrnkH4aRY6M9eP1Uut38GNTXK0xg7wD+Euy/xdW9xc= #The BlahDNS Japan DNS TLS Server - address_data: 108.61.201.119 tls_auth_name: "dot-jp.blahdns.com" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: 427fIEGdHRXL9C6i+PzEk+CstsrmNGXJaAnu9ECu+Hk= ## The Surfnet/Sinodun DNS TLS Server - address_data: 145.100.185.18 tls_port: 853 tls_auth_name: "dnsovertls3.sinodun.com" tls_pubkey_pinset: - digest: "sha256" value: 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= # The securedns.eu DNS TLS Server dot.securedns.eu ads-dot.securedns.eu - address_data: 146.185.167.43 tls_auth_name: "dot.securedns.eu" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= #The dns.seby.io - Vultr DNS TLS Server - address_data: 139.99.222.72 tls_auth_name: "dot.seby.io" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: 8A/1KQQiN+aFWenQon076nAINhlZjGkB15C4E/qogGw= #The Primary appliedprivacy.net DNS TLS Server - address_data: 37.252.185.232 tls_auth_name: "dot1.appliedprivacy.net" tls_port: 443 tls_pubkey_pinset: - digest: "sha256" value: MXKR+t7INx/SPe6RgmkIzRA2FvX+EDqTzTbhZcSBjas= #The Secure DNS Project by PumpleX DNS TLS Server - address_data: 51.38.83.141 tls_auth_name: "dns.oszx.co" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: yevnTQfRqEOU1W8rUBABZRgToMgAwRn0eH7zJeBcq0s= #The ibksturm DNS TLS Server - address_data: 178.82.102.190 tls_auth_name: "ibksturm.synology.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: TjpalBJr0Ir27Dr59lXky4PXN0yTAoW92ddF8lBxYBQ= #The dot.tiar.app DNS TLS Server - address_data: 45.32.105.4 tls_auth_name: "dot.tiar.app" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: s5xofhW7O9egEANpOxvH7vRYndoDZOvNeq4i/91uopE= #The dns-gcp.aaflalo.me DNS TLS Server - address_data: 35.231.69.77 tls_auth_name: "dns-gcp.aaflalo.me" tls_port: 853 tls_pubkey_pinset: - digest: "sha256" value: sj5tpBVTMXBI7NtATG//ENUSVugQ1OiioIlb4Tp4v48= Save and Exit 4- Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS.
UNBOUND GENERAL SETTINGS
Network Interfaces = Select ALL !Under Custom options enter the following :
server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr: 127.0.0.1@8053END OF ENTRY
Outgoing Network Interfaces = Select ALL !
Make Sure to NOT CHECK - DO NOT CHECK - the box for DNS Query Forwarding. Save and Apply Settings
Next -Under System > Settings > General Settings
Set the first DNS Server to 127.0.0.1 with no gateway selected /
Make sure that DNS server option
A - Allow DNS server list to be overridden by DHCP/PPP on WAN - Is Not I repeat - Is Not Checked !
and DNS server option
B - Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not - I repeat - Is Not Checked !
I now **only run 127.0.0.1 ( Localhost ) configured as the only DNS SERVER on my WAN interface**. If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried. I only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.
- Save and Apply Settings
C'est Fini C'est Ci Bon C'est Magnifique
-
huh?
You understand you can do dns over tls in the ubound gui right? I don't see how any of that long drawn out process makes any sense when it can be done with 2 clicks in the gui.
-
Dear johnpoz ( Sir ),
I have seen that option, and I recognize that DNS OVER TLS is activated via the method you suggest. My reasons for preferring to use getdns and stubby is that I get to have more granular control over which DNS NameServers I use along with all the adavantages and features that The DNS Privacy Project offers. Unbound/Stubby combination
Some user combine Unbound (as a caching proxy with other features such as DNS Blacklisting) and Stubby (as fully featured TLS forwarder). For one all name servers have their own keys, I use only QNAME Minimisation enabled DNS servers - padding - and I can choose location - TLSv1.3 - also I can check if certificate is expired on server and so on. I do not know - I am not sure if checking those boxes in pFsense GUI will provide me with this level of certainty regarding how my encrypted DNS SERVERS are behaving when running on pfSense. I do appreciate the work that pfsense does ; I hope that this is not seen as an intrusion - but merely as another option for those who may select to go done this path.
The outdated - much more complex solution - I wrote here : https://forum.netgate.com/topic/130832/solution-posted-dns-tls-getdns-stubby-from-pfsense-freebsd-ports/2 - had over 3K hits - and folks contacting me as to how to get this working. So, I had them in mind with this is all. Again - no hard feelings and
Peace and Grace,
ubernupe -
Unbound supports qname Minimization directly.. And with your setup its pretty pointless anyway.. Your forwarding.. Ok the resolver your forwarding to is doing qname. Don't see how that buys you any sort of privacy - since all it does is hide from the roots what fqdn the resolver IP (not you) is asking for..
Tell what that will do for damn sure is break resolving some domains ;)
As to your tls 1.3... How is that? Are you overwriting the openssl on pfsense.. Since pfsense is only running
OpenSSL 1.0.2o-freebsd 27 Mar 2018So how that stubby could do tls 1.3? Not supported in openssl of 1.0.2
Suggesting that users install non pfsense supported packages is never going to be a good idea..
Just seems all like a waste of time and effort to me when if user does want to forward over tls, all they have to do is click couple of check boxes and list the ones they want to forward to in the general setup area.
You also are forwarding to multiple servers doing blocking... Yeah that BAD idea right out of the box.. Since their lists are not going to be the same.. You query 1 time you blocked, you query for something next time and resolves, etc. Pointing to multiple NS that will not return the same thing is asking for issues with dns plain and simple... Oh this didn't work, oh wait tired it hour later it did, oh wait now its not working again, etc.. Well which freaking caching server did you get the info from?
-
Dear johnpoz,
Thank you for helping me to understand what I am doing better. I will attempt to set up via GUI as per your instructions. I will also make sure that I do not include any servers which use any blocking. I did not realize that I could list the ones they want to forward to in the general setup area. Again, I meant no harm and thank you for your time, expertise and thoughtfulness in helping me to comprehend exactly how pfsense natively handles DNS OVER TLS.
Peace and God Bless,
ubernupe -
No harm really... Just seems like a lot of work for nothing... Reinventing the wheel so to speak..
The whole point of forum is to exchange information... You have idea X, might be good might be bad... We are here to discuss the plus or minuses of doing ABC..
I personally see no reason at all for any of this nonsense.. If my isp wants sniffing my dns?? Don't really give 2 shits... What I do give 2 shits about is them messing with it!!
But if a someone wants/needs to forward their dns over TLS... The ground work has already been done for them, all they have to do is check a couple of boxes ;)
If that helps them sleep at night.. Ok.. Most of these users don't understand any of the buzz words you are throwing in... And the ones that do, and concerned or tinfoil as tight as yours it seems will have already done whatever they want to do on their own... Like run a pi on their network or vm running stubby, and forwarding to whatever new NS service that wants their queries seems good to them.
I can tell you for sure some idiot user not knowing any better is going to find this thread and dick up their whole system trying to walk through your "dead simple" instructions :) heheeheh
-
Make sure that the ports in stubby yml and UNBOUND match - in this tutorial stubby is on port 8069 and UNBOUND forward port is 8053 - I was stopped by false spam alert which kept me from amending matching the ports-
so make both ports 8053 -
I know this is a quite late response, but I would just like to chip in as I don't believe anything has really changed since the original discussion occurred.
The main reason why it still makes sense to set up Stubby (or other DoT solutions), even though Unbound has DoT support, is that unfortunately Unbound seems to be VERY inefficient at doing DoT.
While eg Stubby (getdns) reuses connections, avoiding unnecessary TLS handshaking, Unbound so far does not. (See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089)Unbound seems to effectively sit there handshaking all day, and as a result is notably slow in comparison.