Different ways to setup DNS over TLS

[Operations]

@pfsvrb
I am using Cloudflare, which is kinda the best choice or one of the best choices right? Or do you prefer local resolving?

So i thought that they would handle (like u said) DNSSEC, but when i checked:

https://www.cloudflare.com/ssl/encrypted-sni/

It kinda threw me off because it doesnt check DNSSEC in my case. Any ideas why?

Putting all my trust in Google is by the way probably not happing anytime soon ;) (only if i can avoid doing so of course, without having to end up in a dark cave away from society)

[pfsvrb]

@operations
Personally, I use Quad9, I have pfSense configured in forwarding mode with DoT. I like their approach to privacy better, but take a look at all of them and make the call for yourself. I was a CloudFlare user for quite a while before I started reading up on the other providers and switched to Quad9. Regardless of which one you choose, you're still putting faith in that provider for all of your queries.

If I follow the link you posted for CloudFlare, I get a green check for DNSSEC. Which is what I would expect, even though I am using a different DNS provider.

You can also try this DNSSEC test and see if you get a thumbs up result: https://dnssec.vs.uni-due.de/

Make sure you've disabled any DNS options in your browser. FireFox supports forwarded DNS lookups and so does Chrome. This means by default they will usually bypass your router and push your DNS lookups to a provider specified in the browser. You likely have to disable this to make sure you're getting all of your queries forwarded through your pfSense box.

A final check you can do is a DNS leak test. This should come back with all of your DNS results from the DoT provider that is configured in pfSense (assuming you're using CloudFlare for DoT in this example). If you see other providers in there then you've got another setting in the browser that is bypassing DNS lookups to your pfSense box. https://dnsleaktest.com

[Operations]

@pfsvrb

What made you switch if i may ask?
When i check that DNSSEC link it tells me i am not using DNSSEC as well, so same as my Cloudflare link.

The DNS leaktest tells me i am using Cloudflare, with an 141. IP address.

So i am probably doing something wrong, but if DNSSEC is handled by Cloudflare and not locally there is not much i can do about it right? Do i need a Cloudflare account maybe?

[pfsvrb]

@operations
At this point I am not sure why the DNSSEC test is failing. Can you post screenshots of your config pages (General/Setup) and DNS Resolver General/Advanced?

When I used to use CloudFlare, I was getting DNSSEC "passed" results, so I would expect to see you get similar results. I do not have a CloudFlare account.

I personally switch to Quad9 for 3 reasons. 1) I like their malware filtering that they offer by default for the 9.9.9.9 service. 2) They have a clear privacy policy that complies with GDPR. 3) Their executive board is very active in the community and quite technical, so you'll find them posting and supporting various forums quite a bit, they seem to really care about delivering a better product.

All of the other DNS providers will work okay too, but those are the 3 big reasons I switched to Quad9. There's a pretty good thread here with Quad9 and CloudFlare people posting as well if you really want to go down the rabbit hole on this: https://www.snbforums.com/threads/cloud9-dns.56918/

[Operations]

@pfsvrb I have uploaded the screenshots. Is this what meant? Thanks for your explaination regarding Cloudflare/Quad9.

[pfsvrb]

@operations
I see a few things to try. The goal here is to just get you to a baseline config to see if DNSSEC starts working.

First off, disable Harden DNSSEC Data in advanced settings by unchecking this box:

Next, get rid of the custom options just to rule out any config issues there. Other than the included .conf, all of those other settings should already be configured for you by pfSense when you enable outbound DoT and have an IP address and DNS name specified in System/General (which you do already have setup).

[Operations]

@pfsvrb

I tried both things you said but no joy... :(

I also switched to Quad9 (9.9.9.9 - dns.quad9.net) to make our situations a bit more the same / make it maybe a bit easier to troubleshoot.

but now the first test "secure dns" also fails:

You may not be using secure DNS.

We weren’t able to detect whether you were using a DNS resolver over secure transport. Contact your DNS provider or try using 1.1.1.1 for fast & secure DNS.

after switching to Quad9.

[pfsvrb]

@operations
Based on the screenshots it looks like you're using a VPN? Is it possible to select your WAN gateway instead of the EXTRAIP tunnel, just for testing purposes?

Also, it appears that cloudflare-dns.com doesn't nslookup to 1.1.1.1 anymore. Or at least, when I check it, it doesn't show that address. Can you also try "1dot1dot1dot1.cloudflare-dns.com" for the hostname?

Rerun your DNSSEC tests after that and see?

If this continues to not work, I would try Quad9 DNS or Google DNS just to verify if it's a CloudFlare issue, or a localized issue.

Just to confirm, you've disabled the DNS services within your browser right? Otherwise the browser you test with may not use the local router for lookups.

[Operations]

@pfsvrb i have edited my previous comment :)

Plus it is not an VPN but a GRE tunnel.
Do you mean DNS over HTTPS? That is not enabled. The other things about FF using own DNS, it is coming back with WoodyNet now when i check. So that should be okee right? How do i disable FF using own DNS (network.ttr.mode = 5?)

When i do this:
Also, it appears that cloudflare-dns.com doesn't nslookup to 1.1.1.1 anymore. Or at least, when I check it, it doesn't show that address. Can you also try "1dot1dot1dot1.cloudflare-dns.com" for the hostname?

The Cloudflare test also tells me Secure DNS = not working. When i use Cloudflare-dns.com like before Secure DNS is marked green.
Just to be sure, you meant i use 1.1.1.1.cloudflare-dns.com or did you really wanted me to use "dot" ?

[pfsvrb]

@operations
Exactly, in the case of FF disabling TRR mode should do it. I almost hate to ask but, on the PC that you are doing the testing from, it is configured to use the pfSense router for DNS correct? If it's configured for an external source, obviously that will also impact the results. You'll have the same skewed results if the DHCP server is configured to hand out a DNS address other than that of the router. So if the DHCP server is handing out leases and there's a setting in that lease to use 1.1.1.1, clients will bypass using the local pfSense resolver and send their lookups directly to the DNS provider.

If the above doesn't work out then I'm really not sure what else to have you try, maybe just try a different DNS provider as a final test?

I'll past screenshots of my setup below just in case it helps. But I think we're using a relatively identical config with the exception of the different providers.

My General/Setup:

My DNS resolver/General:

My DNS resolver/advanced:

[Operations]

@pfsvrb i am using DHCP. And the computer gets the IP of the Domain Controller (+DNS) 1 en 2.

But the DNS is configured to use PFSense as a DNS forward. When i the PFSense IP directly as DNS it does not make a difference.

We have a couple of settings differently (advanced tab), why did you change them? I also did that not that it made a difference :)

By the way, "Encrypted SNI" is also not marked green. Shouldn't this option also work when using Cloudflare (or Quad9)?

[pfsvrb]

@operations
I'm not sure on SNI but my understanding is that it's only implemented at the browser level when using the browser configured DNS service. In our case, we're offloading DNS to a local resolver on our network, so I don't think we will see SNI. I could be wrong about this but, that's the basic understand that I have on the SNI part.

I only posted my advanced settings to show my full config. I've noticed a small performance bump in some DNS test scores by messing around with them but it is very slight. I did notice a nice increase by using the "serve expired" option as this serves the last known good IP while also updating the DNS cache in the background. The risk is that it could also give you stale data. Use at your own risk but, it can be helpful to speed up DNS, especially with using DoT that has more overhead.

I'm sorry I don't have any other tips for you regarding the lack of DNSSEC. I'm sort of wondering if somehow the GRE tunnel is breaking it? But I have no proof of that and I personally am not familiar with them so I don't have a way to troubleshoot it.

As a last try, maybe post the output of this command and see if we notice anything out of the ordinary: cat /var/unbound/unbound.conf

[Operations]

@pfsvrb

Okee i get what you are saying. Here is the output:

##########################

Unbound Configuration

##########################

Server configuration

server:
local-zone: ".168.192.in-addr.arpa" typetransparent
local-zone: ".168.192.in-addr.arpa" typetransparent
local-zone: "*.*172.in-addr.arpa" typetransparent

chroot: /var/unbound
username: "unbound"
directory: "/var/unbound"
pidfile: "/var/run/unbound.pid"
use-syslog: yes
port: 53
verbosity: 1
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "validator iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512
jostle-timeout: 200
infra-host-ttl: 900
infra-cache-numhosts: 10000
outgoing-num-tcp: 20
incoming-num-tcp: 20
edns-buffer-size: 1432
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: no
msg-cache-size: 250m
rrset-cache-size: 500m
qname-minimisation: yes

num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
outgoing-range: 4096
#so-rcvbuf: 4m
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: yes
use-caps-for-id: no
serve-expired: yes

Statistics

Unbound Statistics

statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes

TLS Configuration

tls-cert-bundle: "/etc/ssl/cert.pem"
tls-port: 853
tls-service-pem: "/var/unbound/sslcert.crt"
tls-service-key: "/var/unbound/sslcert.key"

Interface IP(s) to bind to

interface: 192.168..1
interface: 192.168..1@853
interface: 172...1
interface: 172...1@853
interface: 172...1
interface: 172...1@853
interface: 10...1
interface: 10...1@853
interface: 192.168..1
interface: 192.168..1@853
interface: fe80::feb6:126e%vmx1
interface: fe80::f:feb6:126e%vmx1@853
interface: fe80::feb6:126e%vmx1.20
interface: fe80::26e%vmx1.20@853
interface: fe8feb6:126e%vmx1.145
interface: fe80::250:126e%vmx1.145@853
interface: fe80::feb6:126e%vmx1.200
interface: fe80::feb6:126e%vmx1.200@853
interface: fe80::250::126e%vmx1.101
interface: fe80::250::126e%vmx1.101@853
interface: 127.0.0.1
interface: 127.0.0.1@853
interface: ::1
interface: ::1@853

Outgoing interfaces to be used

DNS Rebinding

For DNS Rebinding prevention

private-address: 127.0.0.0/8
private-address: 10.0.0.0/8
private-address: ::ffff:a00:0/104
private-address: 172.16.0.0/12
private-address: ::ffff:ac10:0/108
private-address: 169.254.0.0/16
private-address: ::ffff:a9fe:0/112
private-address: 192.168.0.0/16
private-address: ::ffff:c0a8:0/112
private-address: fd00::/8
private-address: fe80::/10

Set private domains in case authoritative name server returns a Private IP address

private-domain: ".168.192.in-addr.arpa"
domain-insecure: ".168.192.in-addr.arpa"
private-domain: ".168.192.in-addr.arpa"
domain-insecure: ".168.192.in-addr.arpa"
private-domain: "..172.in-addr.arpa"
domain-insecure: "..172.in-addr.arpa"
private-domain: "ad.domain.nl"
domain-insecure: "ad.domain.nl"

Access lists

include: /var/unbound/access_lists.conf

Static host entries

include: /var/unbound/host_entries.conf

dhcp lease entries

include: /var/unbound/dhcpleases_entries.conf

Domain overrides

include: /var/unbound/domainoverrides.conf

Forwarding

forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#Cloudflare-dns.com

Unbound custom options

server:
include: /var/unbound/pfb_dnsbl.*conf

Remote Control Config

include: /var/unbound/remotecontrol.conf

[pfsvrb]

@operations
This config file still looks weird. It has the module config as "validator iterator". Do you have any other custom options defined? It seems like something is still over riding the pfSense Web GUI selections that were made for the DNS Resolver.

Have you edited /var/unbound/unbound.conf?

[Operations]

@pfsvrb

To be completely honest, i don't even know how to do that. I have installed PFBlocker, is that maybe the source of the problem?

By the way how do i edit that or other conf files? By using SSH?

Edit; also no other custom options. Where would i do that?

[pfsvrb]

@operations
I was asking about directly editing it, such as with vi.

I don't use PFBlocker, so I'm not sure what impact it may be having here.

The "validator iterator" in the module config basically means that DNSSEC is still enabled on the pfSense resolver. This doesn't make sense because in the screenshots you show this is unchecked. But I suspect that is what is interfering with your DNSSEC test results. However I'm not sure what else might be forcing that feature to stay on.

[Operations]

@pfsvrb

I have turn it on/off plus reboot now it says:

do-daemonize: yes
module-config: "iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512

Is this correct? Cloudflare website + DNSSEC check still fails.

[johnpoz]

How are you going to do any queries when you don't have any outbound interfaces listed? Be it you forward or resolve?

[Operations]

@johnpoz

I am sorry but i am not sure how to answer / what you are asking. Could you "dumb it down" a bit? / or tell me if i made a mistake what to change?

[johnpoz]

The config you posted list no outbound interfaces - so how and the hell would unbound query anything?

Oh you prob have ALL selected..