Setup DNS over TLS on pfSense 2.4.4 p2 - Guide

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.

johnpoz

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

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

This could be confusing.. if your forwarding - then you do not need to enable dnssec on the forwarder.. Its makes no sense to do so.. Its just going to cause extra traffic in your dns query. If where your forwarding is doing dnssec - the forwarder doesn't matter for any sort of dnssec settings. The resolver your forwarding too either does dnssec or it doesn't

jimp

Your forwarder can validate DNSSEC for you, provided it supports that function. Assuming you trust the server you are forwarding to.

johnpoz

The resolver would of have already validated it if doing dnssec, if it didn't validate it wouldn't give you an answer..

It is pointless to have a forwarder do anything with dnssec.. Unless you want some eyecandy in say pihole or something on which records were validated via dnssec and which were not. But makes no difference - if the resolver is running dnssec, and something doesn't validate - you wouldn't get an answer.

jimp

Maybe in a perfect world if the upstream forwarder unilaterally did DNSSEC for everything. But in reality, if you don't request validation, it won't outright deny the query like that. At least with some forwarding services like Google public DNS, you have to send the AD/DO flag in the query or they won't drop responses that fail DNSSEC tests.

johnpoz

no that is not the way a dnssec resolver works.

here I asked quad 9 for a fqdn that fails validation

; <<>> DiG 9.14.4 <<>> @9.9.9.9 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39214
;; 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: 230 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Thu Sep 26 08:02:01 Central Daylight Time 2019
;; MSG SIZE  rcvd: 50

I did not ASK for any dnssec - it just does it..

Now if I ask a non dnssec resolver - say 4.2.2.2, I get an answer

 <<>> DiG 9.14.4 <<>> @4.2.2.2 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38029
;; 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: 38 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Sep 26 08:03:45 Central Daylight Time 2019
;; MSG SIZE  rcvd: 82

google does dnssec

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

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

;; Query time: 80 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep 26 08:04:33 Central Daylight Time 2019
;; MSG SIZE  rcvd: 50

https://www.internetsociety.org/blog/2013/05/confirmed-googles-public-dns-now-performs-dnssec-validation-for-all-queries-by-default/

you do not have to ask - when you forward asking for dnssec is pointless!!! Other than maybe your tool providing some eyecandy on which ones pass and which ones don't have it.