Setup DNS over TLS on pfSense 2.4.4 p2 - Guide

[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

[johnpoz]

Pfsense out of the box resolves and uses dnssec.. And yeah he makes all good points there about resolving vs forwarding.

Keep in mind while you can turn on the minimization to only ask roots for say .tld vs host.domain.tld, and ask the tld NS only for domain.tld vs host.domain.tls

This will for sure break some domains - can promise you that! Tested this quite some time ago - there is for sure atleast one thread here going over that - before it was even a gui option. So if you want to use that feature - be prepared for some stuff not to work.

Also just because dnssec is enabled and being used, only works for domains that actually use it.. Which is no where close to all of them ;)

The biggest point on that list is #6, complete control over your own resolver.

[Qinn]

@johnpoz Yes control is a big point, that's why I don't like DoH in browsers might become default. So I am back to using just unbound and no forwarding and thus tls. Btw which settings would you recommend?

[musicwizard]

@johnpoz Im not using Cloudflare but Quad9 they might not be better but ok.

do you know if there will be a option in pfsense to do the encrypted DNS intern and not longer rely on other parties?

[johnpoz]

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

pfsense to do the encrypted DNS intern

Huh??? That makes zero sense... You want to do encrypted dns from your local client to your local NS?

[musicwizard]

@johnpoz No to the root servers.

[jimp]

For it to work in resolver mode, that would require the roots and every other authoritative DNS server to support DNS over TLS. I'm not aware of any plans to make that happen.

[musicwizard]

@jimp Thank you that what i was wondering about.

[johnpoz]

There is no way that could ever happen to be honest, since every single authoritative NS on the planet for ever single domain would have to be listening on TLS..

Plus it would just be horribly slow as F!!!

Its been how many years since dnssec.. 2010 was when roots enabled it.. So 10 years, and have to be honest a very low deployment... For TLS to be deployed to every single authoritative NS it would be 20, 30, 40 years ;) sort of thing...

[AudiAddict]

Thanks for this guide! Four questions:

1. Can somebody confirm if you need Disable DNS Forwarder checked or unchecked in the general page? The confusing part is the guide has it checked in the beginning and later in screenshots in this topic I see it unchecked.

2. Under DNS resolver settings I followed the guide but I was wondering how this would work if I would to check Register DHCP leases in the DNS resolver and Register static mappings in the nds resolver. Would it try to register it with cloudflare (and thus not work) or would it cache it localy? For use in graphs / stats I would like to register my workstations and devices in the DNS if possible to make lookup easier. hostname.mynetwork.lan

3. Do you agree that I leave my dns settings blank at my DHCP page? Or should I put in my pfsense host or cloudlfare dns here?

4. I use ubiquiti Accesspoints and cloud key. I assign them with static IP's. So these are not getting DHCP leases. Would you recommend using the cloudlfare DNS as a setting in the ubiquiti gear to prevent any issues when pfsense is down? Primary DNS pfsense ip / 2nd cloudlfare? gateway pfsense? suffix ? no idea? home.lan (pfsense.home.lan)?

Thanks in advance for your help!

[johnpoz]

If you check "do not use Forwarder/Resolver for the firewall" then pfsense will not ask itself to then be either forwarded or resolved.. It will ask directly the NS you have listed in the general setup. It will not be able to resolve any local resources you have setup in either dnsmasq or unbound, or even if your using bind package. And it would not be able to do any sort of dot or doh.. It would just be normal dns query to what you have listed, or what NS you got from your isp via dhcp.

The only reason you might set that option is if you want pfsense to use some other NS.. Say your not really using dns on pfsense at all for your clients.. And you want pfsense to be able to check for packages or upgrades, etc.

That should pretty much always be unchecked..

[AudiAddict]

Perfect @johnpoz ! I will leave it unchecked.

Can you also help with my other questions?

[johnpoz]

2. no they would never try and register with clouldflare - dhcp registration has proved for many to be problematic since it restarts unbound anytime there is lease update.

Just use static reservation, and this will populate unbound with the names and IPs you put in your dhcp reservations.. If you have other devices that are setup static on the device you can just put in host overrides for them to resolve.

3. Default is dhcp running on pfsense to point clients to pfsense IP address for dns, this common setup. You normally never have to put something in there unless you want to point dhcp clients to something specific other than pfsense.

4. No I would not recommend pointing them to anything other than pfsense. For you to resolve them, must either setup a reservation for them, even if they do not use it.. So the names will be put into unbound via register static dns reservation check box. Or just setup a host override for them.

[phil80]

Hi,

Thank you for this great reference.

However, I did not find a really best practice exact guide to setup firewall rules to properly redirect external clients DNS requests, (53 and DOT). I understand DOH needs custom options in the unbound DNS resolver

I would need an advice about my firewall rules:

Are the two bottom deny rules really needed when we redirect with the 2 rules above them ?

Also, I added these entries to my custom options Unbound DNS resolver:

# Block DNS over HTTPS (DOH) client requests so that they are redirected to pfSense
server:
local-zone: "use-application-dns.net" always_nxdomain
local-zone: "cloudflare-dns.com" always_nxdomain
local-zone: "dns.google" always_nxdomain
local-zone: "dns.quad9.net" always_nxdomain
local-zone: "dns9.quad9.net" always_nxdomain
local-zone: "dns10.quad9.net" always_nxdomain
local-zone: "dns.adguard.com" always_nxdomain
local-zone: "dns-family.adguard.com" always_nxdomain

I tested with Firefox and also by setting a custom DNS server in Windows 10 and it seems to block properly the DNS requests and redirect them to my DOT setup in pfSense

Hope any one can answer about the rules

Best regards

[johnpoz]

Those rules are not needed.. Unless your wanting to allow downstream not lan net to be forwarded.

Rules are evaluated top down, first rule to trigger wins, no other rules evaluated. Your top rules allows any any, so no need for the allow to 53 on loopback.. Already allowed by rule above it.

What are your port forwards?

The problem with redirecting doh or dot, is your server your redirecting to is not going to have the correct cert.. You would have to know where the client is going, and then your dns would have to use cert with that fqdn on it, and your client would have to trust it.

Your reject rules would never be seen, again because you have a rule that allows any any above them... Unless you were trying to block something that is not lan net, how would non lan net source be on your lan? Do you have downstream networks? And there is a default deny anyway.. So while rejects can be useful, that traffic would be blocked anyway if not allowed somewhere above.

How is serving up nx, going to get them to talk to your pfsense? Again for redirected doh or dot to ever work, your NS would have to have the correct cert to use.. Which how have you done that?