Setup DNS over TLS on pfSense 2.4.4 p2 - Guide

LaUs3r

Getting aware that more and more DNS providers offer DNS over TLS, I decided to try a setup with my pfSense.
As the netgate guide for DNS over TLS with pfSense does not cover the latest pfSense release 2.4.4 p2, I’d like to share my experience and setup.

In my case, I use the Quad9 DNS servers.

Step 1:
Ensure Quad9 DNS servers are used. Go to System > General Settings and under DNS servers add IP addresses for Quad9 DNS servers and select the WAN gateway.
Make sure the DNS Server Override is unchecked as we don’t want the Quad9 DNS servers being changed by the ISP.

Step 2:
The DNS resolver needs to be changed accordingly. Navigate to Services > DNS Resolver.
Make sure the DNS resolver is enabled at all. Verify that you selected ALL network interfaces. Enable ~~DNSSEC Support~~, DNS Query Forwarding and check the usage of SSL/TLS.

UPDATE: Leave DNSSEC UNCKECKED as it's simply no neccessary as pointed out by @johnpoz in his post below - thx for that!

With the DNS Query forwarding the Quad9 DNS servers of step 1 will be used.

Et voila, that’s it!

Step 3:
The setup is pretty straight forward, but no setup without verification.

Therefore go to Diagnostics > States, filter for the Quad9 DNS Server IP (9.9.9.9) and you will see that the DNS protocol is now TCP (whereas default DNS on port 53 is UDP) and the port is 853.
Don’t get confused here by my interface name (TGINTERFACE). I use a VPN provider and the DNS queries are not send through WAN, but the VPN interface.

An additional verification is to use Package capture. Go to Diagnostics > Packet Capture. Select your interface (probably WAN if you do not use a VPN provider or something similar) and enter for example the port 853.
Press “start” and browse a website. Hit the stop-button and you will see a packet capture looking similar to this.

As you can see, the DNS queries go to the Quad9 DNS Servers over port 853.
I also put in the default DNS port 53 to double-check if queries go the default port. The packet capture came up empty, so everything looks fine.

As I am a very careful person, I also added some floating firewall rules to prevent DNS resolution over port 53 and I only allow DNS resolution over Quad9 server using port 853.
I don’t know if this is actually necessary.

In a second step, we are going to verify the DNSSEC support. Simply go to https://dnssec.vs.uni-due.de/ and hit “start test”.

Now if everything works as planned, the little guy gives us a thumb up

Otherwise you’ll get a:

Make sure to use private browsing or clearing the cache during toggling DNSSEC on/off and testing.

That’s it.

Let me know if I missed anything here. I'd appreciate as well some feedback on the floating rules that block DNS over port 53. I really don't know if this is necessary. If I remembered right I saw some queries going to port 53 even though I had TLS activated. I just tried to reproduce this now, but the package capture on port 53 keeps being empty while I deactivated the floating rules.

LaUs3r

@laus3r said in Setup DNS over TLS on pfSense 2.4.4 p1:

Let me know if I missed anything here. I'd appreciate as well some feedback on the floating rules that block DNS over port 53. I really don't know if this is necessary. If I remembered right I saw some queries going to port 53 even though I had TLS activated. I just tried to reproduce this now, but the package capture on port 53 keeps being empty while I deactivated the floating rules.

I remember now the reason for the floating rule for DNS over port 53 - DNS leak prevention! :-)

Making sure that absolutely no DNS queries go out on port 53 and only over TLS on port 853, DNS leaks are prevented. This aspect is especially important if you use a VPN provider.
You can check for DNS leaks on several sites, for example
https://www.dnsleaktest.com
http://dnsleak.com/

When running a test, you should never see your ISP's WAN IP. If that's the case you have a dns leak.

johnpoz

You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

dnssec works

$ dig @9.9.9.9 www.dnssec-failed.org

; <<>> DiG 9.12.3-P1 <<>> @9.9.9.9 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5771
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 24 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jan 23 05:50:43 Central Standard Time 2019
;; MSG SIZE  rcvd: 50

non dnssec dns server.

$ dig @4.2.2.2 www.dnssec-failed.org

; <<>> DiG 9.12.3-P1 <<>> @4.2.2.2 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17404
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN      A       69.252.193.191
www.dnssec-failed.org.  7200    IN      A       68.87.109.242

;; Query time: 34 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Wed Jan 23 05:51:46 Central Standard Time 2019
;; MSG SIZE  rcvd: 82

So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.

bcruze

so your custom options within DNS resolver is left.. blank?

i am still following the directions posted from https://www.netgate.com/blog/dns-over-tls-with-pfsense.html

bepo

@bcruze this custom option was necessary on previous version of pfSense. Now you have a checkbox for this. "Use SSL/TLS for outgoing DNS Queries to Forwarding Server"

LaUs3r

@johnpoz said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

dnssec works
$ dig @9.9.9.9 www.dnssec-failed.org

; <<>> DiG 9.12.3-P1 <<>> @9.9.9.9 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5771
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 24 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jan 23 05:50:43 Central Standard Time 2019
;; MSG SIZE  rcvd: 50
non dnssec dns server.
$ dig @4.2.2.2 www.dnssec-failed.org

; <<>> DiG 9.12.3-P1 <<>> @4.2.2.2 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17404
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN      A       69.252.193.191
www.dnssec-failed.org.  7200    IN      A       68.87.109.242

;; Query time: 34 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Wed Jan 23 05:51:46 Central Standard Time 2019
;; MSG SIZE  rcvd: 82
So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.

@johnpoz , yeah you are 100% right. Thx for the explanation. I'll update the post accordingly and put the DNSSEC-checkbox to "Unchecked"

no_jah

I have a couple of questions,

Is it still possible to use internal DNS on port 53 when you use this setup, and I also would like to know on what interface the floating rules are applied?

LaUs3r

@no_jah said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

I have a couple of questions,

Is it still possible to use internal DNS on port 53 when you use this setup, and I also would like to know on what interface the floating rules are applied?

yes, it is possible to use port 53. Just make sure that the port is open.

Regarding the interface: I use a VPN connection for my whole traffic. That's why the interface in my case is called TGINTERFACE and not WAN. The most common setup is to use the WAN interface for the internet traffic. If this is the case for you, select the WAN interface.

Cheers

bcruze

This post is deleted!

LaUs3r

@bcruze said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

why isn't the top option checked : Respond to incoming SSL/TLS queries from local clients

well, you could check it. I simply wasn't aware about that option, but it could make sense depending on your config

@bcruze said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

i've followed this step again. and states still shows :

(192.168.1.246:40971) -> 1.1.1.1:53
that is somehow strange. Do you use a local config maybe for this client? can you post it please?

TAC57

@LaUs3r
When I turn on the floating rule to block port 53 I can do google searches but can't get to any other websites. If I disable the port 53 blocking rule then I can get to any site but the pfSense packet capture report shows traffic on port to 8.8.8.8. I'm really not sure where Googles DNS is coming from. Do you have any suggestions on how I might change the port 53 blocking rule?

Packet Capture on port 53 give me:
15:23:28.505900 IP 75.xxx.xxx.xxx.32041 > 8.8.8.8.53: UDP, length 33
15:23:28.535878 IP 8.8.8.8.53 > 75.xxx.xxx.xxx.32041: UDP, length 49

TAC57

@LaUs3r

With this rule why would I be seeing any port 53 traffic with packet capture?

johnpoz

packet captures have nothing to do with what actually shows up on the interface.. Just tells pfsense what to do with traffic sees on the interface, either allow it and process it, or block it (drop it without doing anything with it).

TAC57

@johnpoz so you don't agree with @LaUs3r that Package Capture can be use to verify that ALL DNS traffic to the outside world is going out over TLS (port 853) and there is no leakage on port 53? Per the guide above, I'm seeing 9.9.9.9:853 TCP traffic with Diagnostic | States and 9.9.9.9:853 traffic with Diagnostic | Packet Capture. But I am also seeing 8.8.8.8:53 traffic.

Per your comment just because I'm seeing some 8.8.8.8 traffic with packet capture doesn't mean it's going out on the WAN?
Packet Capture on port 53 give me:
15:23:28.505900 IP 75.xxx.xxx.xxx.32041 > 8.8.8.8.53: UDP, length 33
15:23:28.535878 IP 8.8.8.8.53 > 75.xxx.xxx.xxx.32041: UDP, length 49
.
.
.

Is there a feature in pfSense that I can confirm I have DNS over TLS with no leakage or should I just assume if the floating firewall rule I've shown above will assure that no port 53 traffic is getting out of my network.

Thanks for all you comments.

p.s. Could I setup the floating DNS port 53 blocking rule on either the WAN or LAN interface, assuming I didn't care about my DMZ?

johnpoz

Huh? Where did I say that? My point is you can block all day on LAN, and then sniff on Lan and see packet captures with it.

You can block all day on LAN for 53, and you could still see outbound on your wan for 53... Maybe pfsense itself was set to directly ask 8.8.8.8 in its general settings vs JUST loopback..

As to floating rules for 853.. Why would think you need those in the first place?

And you can not stop pfsense from talking outbound, you can put rules all day long on floating tab.. Traffic generated by pfsense can not be blocked... There are HIDDEN rules.. So you could create an any or out rule on your wan for 53 in floating, make it quick - and still pfsense would be allowed out.

So why don't you actually open up the sniff of that to 53 traffic and see what the query was actually for.. Which should give you some clue to its origin.

But yes you can sniff on your wan, for port 53 to catch any traffic that was going out of your network to validate your setup is working..

TDJ211

@johnpoz said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

dnssec works

So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.

Does the same hold true DNSSEC is unnecessary when in forwarding mode for cloudflare 1.1.1.1 ?

Gertjan

Rule of thumb : when forwarding, dnssec is useless/won't work/has no sense.

Repo

@LaUs3r

Having DNSSEC enabled not only is not necessary but it breaks the function of TLS.

Cloudflares DNS checker shows it not working if DNSSEC is running at least.

johnpoz

having dnssec enabled shouldn't break dot.. But when your forwarding - dnssec is pointless.. If you forward and where you forward their resolver is doing dnssec, you get it by default... If not, then you asking for it doesn't get you anything..

When you forward - dnssec should be OFF, no matter how you look at it.

jimp

DNSSEC is for validating authenticity (prevent spoofing, hijacked authoritative nameservers, etc).

DNS over TLS is for encrypting transport (privacy).

They do different things and are both are useful, especially together, for increased security and privacy.

There is no reason you can't run both, unless whatever you are forwarding to does not support one or the other.