Setup DNS over TLS on pfSense 2.4.4 p2 - Guide

[johnpoz]

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

But that's between the user and their DNS servers.

Valid point. But all I can do is base my recommendation on experience with dns.. And in all of that experience I have never seen a scenario where it makes sense to do dnssec if your forwarding... Is it possible there is some odd ball setup where it might do something. Sure ok..

Your assuming the users actually understand what they are doing... They don't or they wouldn't be here asking ;) And to be honest if they are doing some odd ball setup where forwarding and asking for dnssec actually does something worthwhile.. I would tell them they are doing it wrong ;) Why not just forward to NS that actually does dnssec without asking it to do it ;)

If a NS doesn't do dnssec unless you ask for it, how could it serve you up stuff from cache? Since if it didn't do dnssec that cache info is not validated... So It can not serve it up to anyone that asks for dnssec, It would have to do a fresh resolve. So its either doing dnssec all the time, so it only places stuff that validates in its cache, or does not have any dnssec set on it.. Or its not... So asking some NS to to do dnssec that isn't doing it all the time makes no sense really.. Because it would not be able to use its cache - which is really the point of forwarding. If your just to resolve anything you ask and do dnssec on it - might as well just run my own resolver and get the info directly, etc.

Lets just agree to disagree here I guess. I will give you the point that we can not know all possible scenarios that a user might be doing, and we are only assuming.. But I for the life of me can not fathom an actual real world scenario were it would make any sense to ask for dnssec of a NS I am forwarding too that doesn't already do it anyway. So no reason to ask in the first place.

[cmb991]

I did these same steps but used 1.1.1.1 and 1.0.0.1. My connection states show its TCP 853 traffic to 1.1.1.1.
But when I use cloudflare’s tester, it shows it failed. Ignore the 192.168.1.11, that’s a hard coded machine I have to fix.

Settings: https://imgur.com/gallery/2gbd2Il

Fail: https://imgur.com/gallery/xeclJ0W

[johnpoz]

How would they know how you talked to 1.1.1.1 - the test is not valid unless your talking to their dns..

They can only test that your encrypted or not encrypted to dns if your actually talking to them for dns.. That test should say NA unless your talking to them.. Not that your unsecured - they have no clue what port or protocol or anything on how you talked to 1.1.1.1

This is what it should say

[cmb991]

For some reason, now it shows Secure DNS. Not sure what changed to make it do it or why yours is showing a question mark....

[cmb991]

I can't tell by all of the different posts... but what block rule would you use to block any 53 traffic just on the lan network from going outbound to make sure your not leaking? I have a separate lan I still want 53 traffic to work.

[johnpoz]

If you don't want 53 outbound, then block that.. Rules are evaluated top down, first rule to trigger wins.. No other rules are evaluated..

Allow to what you want 53 to go to, below block 53 to anything else. Its that simple. Do you really need a picture?

here

I allow dns to pfsense address, and my pihole (that sits on another segment)
I then block any other access to 53, and 853 (dot)..

The top rule there blocks access to what the doh servers resolve too for doh, I have all of the known doh servers resolve to that IP.. This an attempt to block access to doh, since doh really needs to use a url to be used, and I have all of their names setup to resolve to that IP.

example snip of some of them. There are many more.

local-data: "cloudflare-dns.com. 120 IN A 172.19.19.19"
local-data: "dns.quad9.net. 120 IN A 172.19.19.19"
local-data: "dns9.quad9.net. 120 IN A 172.19.19.19"
local-data: "dns10.quad9.net. 120 IN A 172.19.19.19"
local-data: "doh.opendns.com. 120 IN A 172.19.19.19"
local-data: "doh.cleanbrowsing.org. 120 IN A 172.19.19.19"
local-data: "dns.nextdns.io. 120 IN A 172.19.19.19"

The plan is to also create an alias with all the know IPs of the doh servers, and directly log any traffic to them on 443 - but haven't set it up yet.

For them to say your using secure dns, means your asking them directly! Its pretty clear there.. where it states "you are using encrypted transport with 1.1.1.1"

[duncan.young]

Hi all,

late to the thread, but related to my current issue.

First off, to block all outgoing traffic to port 53, I have a floating rules to allow lan etc in on 53 (quick), then the next rule to block all 53 traffic including on WAN "OUT". This blocks everything including packets originating from pfsense itself. I have logging turned on, so any escapees show up. The main thing to note is that floating rules can block outgoing traffic on a network, unlike normal rules which can only block incoming so are no good at blocking connections originating from pfsense.

I have set up a NAT on the LAN to force any attemped UDP:53 from the lan to use pfsense. I have a nvidia shield which insists on using 8.8.8.8 udp 53.

I have set up DNS resolver to forward to 1.1.1.1 etc using TLS etc.

Now the problem I see is occasionally PFSense is sending out requests to UDP 53. I unblocked my floating-WAN-OUT-53 rule (or changed it to a pass ) and use a looping shell script and sockstat to locate the culprit (Please tell me a more elegant way to do this). I found things like ntpd and ntopng were causing this.

Now /etc/resolv.conf shows:
nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 1.0.0.1

I am thinking that local pfsense services are using the /etc/resolv.conf and sometimes not going to 127.0.0.1, in which case a direct UDP to 53 is being used.
It seems to me that the resolv.conf is populated from the entries in system/generalsetup/DNS server settings/DNS servers, but idealy the forwarding resolver should be using a different list. i.e. resolve.conf: 127.0.0.1 and forwarding 1.1.1.1, 1.0.0.1 with TLS etc.

My solution is to go back to the "Custom Settings" as outlined in "https://www.netgate.com/blog/dns-over-tls-with-pfsense.html" and remove all entries in general setup/DNS servers (leaving only 127.0.0.1 in resolv.conf)

I guess the other option is to just keep blocking outgoing port 53.

Comments please.

Duncan

[Gertjan]

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

I am thinking that local pfsense services are using the /etc/resolv.conf and sometimes not going to 127.0.0.1, in which case a direct UDP to 53 is being used.

That means that these services have some kind of resolver integrated.
In that case you should set up these services to use the local unbound' facilities.
But, as far as I know, such kind of services are not used by pfSense.
Some package ?

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

PFSense is sending out requests to UDP 53

Do not forget to filter TCP:53 requests.

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

but idealy the forwarding resolver should be using a different list. i.e. resolve.conf: 127.0.0.1 and forwarding 1.1.1.1, 1.0.0.1 with TLS etc.

Noop.
unbound, as any other local resolver/forwarder uses the system file /etc/resolv.conf
Check also your main unbound config file, /var/unbound/unbound.conf

[Qinn]

I've configured DoT using Quad9 and a floating rule to reject any to any on port 53,

the only difference between the first picture in this tread is my "System / General Setup" as t I have unchecked "disable DNS forwarder".

When I test https://tenta.com/test/ it tells me that tls is false?

Thanks for any help, cheers Qinn

[johnpoz]

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

as t I have unchecked "disable DNS forwarder".

Then pfsense wouldn't use itself for dns..
Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall

That should always be "unchecked" to be honest. Unless you don't want pfsense using is own local dns be it the the forwarder or the resolver. This is not a guide to how to do dns over tls - its one persons mistaken take on how to do it.. Not correct by any means.

[Qinn]

Could you tell me then what I should do to use dns over tls?

[johnpoz]

Click the little buttons in the gui ;)

You do not need to tell pfsense not to use itself.. And you don't want to use dnssec when forwarding..

If you uncheck pfsense to use itself - then it could directly try and contact what is listed in general, and its not going to use tls..

[Qinn]

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

Click the little buttons in the gui ;)

You do not need to tell pfsense not to use itself.. And you don't want to use dnssec when forwarding..

If you uncheck pfsense to use itself - then it could directly try and contact what is listed in general, and its not going to use tls..

@johnpoz ROFL ;) "mea culpa" I just had to add all screens (see below), then I could have avoided the response. As you can see those ones were checked when I performed the check at https://tenta.com/test/ and strangely false on tls?

[bcruze]

only one part missing:

Does Quad9 support DNS over TLS?

We do support DNS over TLS on port 853 (the standard) using an auth name of dns.quad9.net.

My ISP captures port 53, is there another port I can use for Quad9?

We support standard DNS queries on port 9953 as well as 53. In addition we support DNS-over-TLS on the standard port of 853 using the auth name of dns.quad9.net. For more information on the configuration of DNS-over-TLS see the DNS Privacy Project.

https://www.quad9.net/faq/

[Qinn]

Maybe someone has an idea why I still get false on tls enabled, when check pfSense ( https://tenta.com/test/ ) using the settings in my last post.

Thanks for any idea's cheers Qinn

[MoonKnight]

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

Maybe someone has an idea why I still get false on tls enabled, when check pfSense ( https://tenta.com/test/ ) using the settings in my last post.

Thanks for any idea's cheers Qinn

Hi,
Could you try run these tests:
https://www.cloudflare.com/ssl/encrypted-sni/
https://dnssec.vs.uni-due.de/
http://en.conn.internet.nl/connection/
https://1.1.1.1/help

[johnpoz]

Not sure how you think that test would show you if your using TLS for dns??

The only freaking way they could tell is if you directly asked them... There is no other way for them to know this... Its not possible..

You forward to 1.2.3.4 via tls... So your query to them is encrypted via tls... They look up something.whatever.tld in this dns test.. How does that site have any freaking clue that you asked 1.2.3.4 via encryption or not??

They cant!!! The only way they could know if your client directly talked to one of their NS via tls - which is not how it works... That test is nonsense...

Only way to show that your using tls, is a test site run by who your forwarding to via tls.. Like the cloudflare test when forwarding to them..

Or just sniff on your wan -- are you seeing any dns go out of 53??

here this took 2 seconds..

Me normally resolving

Now me forwarding to 1.1.1.1 via tls.

edit: that stupid site... Now that using clouldflare via tls is now giving me warning and saying not using tls or dnssec.

That site has one goal -- to get you to use their VPN service/browser... Nothing more..

[Qinn]

@johnpoz Thanks for your patience and time, kudos ;) an the logic is sound, the only site that knows if tls is working is dns you are forwarding to.

[johnpoz]

So now your sure your ISP doesn't know you did a query for pfsense.org or amazon.com ;) Cloudflare does - but they are really trust worthy - Just ask them ;)

[Qinn]

@johnpoz Good question, so maybe move over again to just unbound, so without TLS for outgoing DNS Queries to the Forwarding Servers of Cloudflare ;)

This guy jfb sums it up quite nicely...

https://discourse.pi-hole.net/t/general-consensus-to-use-cloudflare-proxy-or-unbound/19120/3