Setup DNS over TLS on pfSense 2.4.4 p2 - Guide

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.

jimp

I recall digging into it a while back and you had to have DNSSEC enabled to get that behavior (at least from Google public DNS servers). I didn't think it was that long ago, though. Maybe it was before 2013. I still wouldn't say it's pointless to ensure you are requesting it.

DNS over TLS still only covers privacy and first-hop validation (Assuming you are checking the hostname/cert), though.

johnpoz

no its pointless.. Your forwarding, how is your forwarding even going to validate the records it gets back.. Does it have the anchors? How is it actually going to do the validation?

So I ask 4.2.2.2 +dnssec - still get a freaking answer. I get back the rrsig

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; 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
www.dnssec-failed.org.  7200    IN      RRSIG   A 5 3 7200 20191002174442 20190925143942 44973 dnssec-failed.org. cJnvSoQfMtWHg4KWySkDAEaHaqtcw+BlHNC2+MuT1BSJDpn5fv3fIEyG HuPYJ4Pd9N38QgBDA4Bcdfc0O/P5qzvP6+ixCwLNJ9FppRrNVuPG6QCB pIApBzleHvfwKPZUQ1FKXjOaCEb/vQJhJ/QvwSSmz4LLF3sh0M3s8nvK hK8=

;; Query time: 96 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Sep 26 08:10:46 Central Daylight Time 2019
;; MSG SIZE  rcvd: 259

Means nothing.. How is it validated by the forwarder? If the forwarder did some sort of validation? You clearly trust this where you forwared, and you picked it to do dnssec for you.. What is the point in trying to doublecheck what it sends you.. It could send you anything it wanted to be honest..

If you want dnssec, run your own resolver (unbound) if you want to forward and have dnssec, then pick a NS you forward to that does dnssec for you. Its that simple - if you forward there is no reason for the forwarder to ask about dnssec. If you want to forward with dot or doh and dnssec - pick a NS to forward to that does what you want to use. Enabling dnssec on a forwarder, that is forwarding to something that doesn't do dnssec is pointless. Having dnssec enabled on your forwarder using forwarding to a resolver that does dnssec is pointless.

If you forward to something that is suppose to be doing dnssec, and you get back an answer for something that should be failing dnssec - then where you forwarding to is broken, so you asking for dnssec is not going to fix their broken setup even if you did get back rrsig for that record..

jimp

It's not about the client validating it locally but about telling the server "yes, I would like this validated" if the server does so conditionally. Sure, you can pick a forwarder that does what you want 100% of the time but that may not be in your control.

It's not an absolute situation. You can't say it's worthless 100% of the time because you do not know what the servers are doing. Sure, the ones you checked behave that way, but that doesn't mean everyone's always will. You can't make those assumptions.