Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC

[occamsrazor]

So I was quite keen to try out DNS-over-TLS and after looking at the different options settled on Quad9. Previously for normal DNS I was using OpenDNS but they don't support DNS-over-TLS. The Quad9 response times in my location were better than GoogleDNS, Cloudflare etc, plus I like their privacy policy and malware domain blocking (although doing that with pfBlockerNG-devel as well).

Pretty sure I have everything working. This is my setup:

System > General Setup:

Services DNS Resolver:

Rules > LAN:

These two rules are what I used before DNS-over-TLS to block DNS requests from not going through Unbound. My thinking is they should still be applicable as-is even though pfSense is now forwarding requests on port 853, because the requests from my client machines to pfSense are still port 53..... is this correct or do I need to change something?

I did a packet capture and see the requests going out and back the WAN on port 853, and nothing on port 53, so think it is working correctly but just wanted to check.

[jimp]

If you do not want clients behind pfSense to talk to DNS over TLS on their own, you might want a similar pass/block setup for tcp/udp port 853 to the LAN address and nowhere else. Some clients like the most recent Android release support DNS over TLS natively, and you might want to control that.

You might also want to have unbound act as a local DNS over TLS server for those clients as well.

[occamsrazor]

@jimp said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

If you do not want clients behind pfSense to talk to DNS over TLS on their own, you might want a similar pass/block setup for tcp/udp port 853 to the LAN address and nowhere else. Some clients like the most recent Android release support DNS over TLS natively, and you might want to control that.

Never thought of that - i.e. clients initiating DNS-over-TLS requests themselves. It's a home setup so not really critical, but might as well for the heck of it. So to prevent them being able to bypass my DNS server I would do like this?

You might also want to have unbound act as a local DNS over TLS server for those clients as well.

That's this option in DNS Resolver settings, right?

What is exactly does the warning "Activating this option disables automatic interface response routing behavior, thus it works best with specific interface bindings" mean and what are the implications of having "automatic interface response routing" disabled? Thanks......

[jimp]

Those rules are OK, but they could be better, for example a port alias containing 53, 853 would let you do that in two rules. Technically you could do it in one (block tcp/udp from any to ! LAN Address port <dnsports>)

That is the correct checkbox as well. The warning there is about unbound's behavior when bound to multiple interfaces, especially bound to all. With that box active, it responds back to the client from the closest interface routing-wise for UDP. With it inactive, unbound is smart enough to always reply back to the client from the address to which the original query was sent. That behavior doesn't matter for most. Primarily things like DNS over IPsec tunnels are affected.

[occamsrazor]

@jimp said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

Those rules are OK, but they could be better, for example a port alias containing 53, 853 would let you do that in two rules.

Nice, yes that is simpler.....

Technically you could do it in one (block tcp/udp from any to ! LAN Address port <dnsports>)

Wouldn't that block request from getting to pfSense? Or does the "!" mean invert match? Not sure quite how to do that in the GUI, but in any case I think I prefer having two rules, somehow seems easier to understand to me.

That is the correct checkbox as well. The warning there is about unbound's behavior when bound to multiple interfaces, especially bound to all. With that box active, it responds back to the client from the closest interface routing-wise for UDP. With it inactive, unbound is smart enough to always reply back to the client from the address to which the original query was sent. That behavior doesn't matter for most. Primarily things like DNS over IPsec tunnels are affected.

Thank you for the explanation.

[jimp]

@occamsrazor said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

Technically you could do it in one (block tcp/udp from any to ! LAN Address port <dnsports>)

Wouldn't that block request from getting to pfSense? Or does the "!" mean invert match? Not sure quite how to do that in the GUI, but in any case I think I prefer having two rules, somehow seems easier to understand to me.

The "!" inverts the match, there is a "not" checkbox in the firewall rule destination network options to make that happen. If you find it confusing, don't worry about using that syntax. Clarity is better than being concise, so if using two rules is easier for you to understand, that's just fine.

[occamsrazor]

@jimp said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

@occamsrazor said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

The "!" inverts the match, there is a "not" checkbox in the firewall rule destination network options to make that happen. If you find it confusing, don't worry about using that syntax. Clarity is better than being concise, so if using two rules is easier for you to understand, that's just fine.

Thanks I understand now, I just didn't know the "!" referred to the invert match checkbox. That's much cleaner. Also, for some reason I thought I needed to explictly allow the DNS to reach LAN Address original rule I had, but now I see that was only necessary because of the way the "block all requests except those above this rule" was written. So basically I can delete the two rules and only use this:

[Forsaked]

@occamsrazor said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

@jimp said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

@occamsrazor said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

The "!" inverts the match, there is a "not" checkbox in the firewall rule destination network options to make that happen. If you find it confusing, don't worry about using that syntax. Clarity is better than being concise, so if using two rules is easier for you to understand, that's just fine.

Thanks I understand now, I just didn't know the "!" referred to the invert match checkbox. That's much cleaner. Also, for some reason I thought I needed to explictly allow the DNS to reach LAN Address original rule I had, but now I see that was only necessary because of the way the "block all requests except those above this rule" was written. So basically I can delete the two rules and only use this:

This rule should be in the Wiki, instead of those other 2 rules there.

https://www.netgate.com/docs/pfsense/dns/blocking-dns-queries-to-external-resolvers.html

Am i am right that the only change to the redirect rule in the Wiki, would be Port 853 added as Destination and Redirect Target Port?

[occamsrazor]

@forsaked said in Quad9 DNS-over-TLS setup with Unbound & forwarding in 2.4.4-RC:

Am i am right that the only change to the redirect rule in the Wiki, would be Port 853 added as Destination and Redirect Target Port?

Oh I forgot about that rule that I also had in my NAT > Port Forwards. So if you want to block requests from going outside pfSense, but also to forward those requests to pfSense, then do you need to have both these rules? Don't they sort of cover the same thing? Or it just makes it extra sure?

I followed the good advice of @jimp and created a "DNSPorts" alias which does make setting these up easier, so now my port-forward rule looks like this:

When using an alias containing two ports 53 and 853 for Dest. Ports and NAT Ports, is the system smart enough to realise that 53 should go to 53 and 853 to 853?

[Forsaked]

I did the same thing, but since i don't have a client which natively supports DNS over TLS, i can't check if it works with just the Block and Redirect rule.

[occamsrazor]

@forsaked Yes I don’t have a way to test either. Just figured I’d set it up in case a device was used on my network that did (eg a visitor).
PS - unrelated, but I have the exact same hardware as you, I like it.

[italnsd]

@occamsrazor The single rule that encompasses the four simple rules is definitely a nice way to compact the Firewall rule set. On the other hand, it gives less detailed information about what is going on, which can help debug issues. For example if the rules on port 853 are never hit, you know that there are not internal DNS over TLS queries. In general, the more compact the rules are, i.e., the more situations they cover, the less visibility into the system they provide.