How to enforce encryption of outbound DNS queries
-
@Jung-Fernmelder said in How to enforce encryption of outbound DNS queries:
I tought of blocking port 53 generally but it would have side effects - clients which are depending on unencrypted DNS services wouldn't be able to perform DNS lookups.
Why do the clients need to request public DNS servers directly?
The should request the DNS resolver on pfSense instead, which allows unencrypted connections.So there is no need to allow any unencrypted outbound DNS traffic.
-
This is what I do. End result is all unencrypted outbound DNS queries will be redirected to the local DNS server, which will encrypt all outbound queries. I ran a packet capture to confirm there are no WAN side outbound unencrypted DNS queries.
- DNS Resolver settings
- Add a NAT rule to redirect all unencrypted outbound DNS queries to the local DNS server, just in case some clients hard code their DNS servers.
-
V viragomann referenced this topic on
-
@viragomann said in How to enforce encryption of outbound DNS queries:
Why do the clients need to request public DNS servers directly?
@elvisimprsntr said in How to enforce encryption of outbound DNS queries:
just in case some clients hard code their DNS servers
@elvisimprsntr Why did you enable DNSSEC support? There are a lot of warnings that DNSSEC support would can cause issues with DoT. And it's unencrypted since DNSSEC verifies the DNS server's identitiy only.
-
@Jung-Fernmelder
Also I'd ponder, if you really need to enable TLS on the resolver. Do you need internal DNS to be encrypted?
DoT on local clients will further take some more configuration steps. -
@viragomann said in How to enforce encryption of outbound DNS queries:
Do you need internal DNS to be encrypted?
I want to prevent the clients connected to the pfSense from spying out each other. Without internal DNS encryption the clients can use wireshark (or comparable tools) to investigate who has looked up which domain when. They would also be able to perfom man in the middle attacks. With internal DNS encryption they could only see who has looked up how many domains in a certain period of time.
@viragomann said in How to enforce encryption of outbound DNS queries:
DoT on local clients will further take some more configuration steps.
No problem. The critical clients have to be configured to use DoT, no operating system uses DoT by default I think.
-
@Jung-Fernmelder said in How to enforce encryption of outbound DNS queries:
@elvisimprsntr Why did you enable DNSSEC support? There are a lot of warnings that DNSSEC support would can cause issues with DoT. And it's unencrypted since DNSSEC verifies the DNS server's identitiy only.
I’ve not had any issues.
-
@Jung-Fernmelder said in How to enforce encryption of outbound DNS queries:
Without internal DNS encryption the clients can use wireshark (or comparable tools) to investigate who has looked up which domain when.
WPA2 can be decrypted on the fly these days ?
But ok, one of my SSIDs is not encrypted at all, as I use that wifi network with the captive portal.
Portal authentication is done over TLS (so good luck with that).
Most (if not all) web access, mail access and everything else is done over TLS, but, correct, DNS is still open in the air.
So, in theory, I can see, and many with me, that my hotel clients visit :
Facebook, Google, Netflix, Youtube, twitter, Toctoc and so on. What they are doing there, I can't tell.
Be ware : portal users, or wifi users that have things to hide (they are the first to know ;) ) will, right after portal activation, fire up their VPN .... so even if with a Wifi network open, all traffic is still hidden. -
@Gertjan The security of WPA2 doesn't matter since the critical clients are connected by wire. But somebody could clamp the wire and sniff out the traffic. Therefore every kind of unencrypted traffic has to be avoided.
-
There is a thing called IP isolation to prevent clients from seeing each other or other parts of a network.
-
@Jung-Fernmelder said in How to enforce encryption of outbound DNS queries:
But somebody could clamp the wire and sniff out the traffic
Clamp a wire, like we did with the phone lines, ages ago ?
Way to complicated. We're in 2024 now. All my switches are L2/L3. So I can port clone any port at 'my command', and see whats on it.
It's still have that one on the "should do that ones before I go 8 feet under" list.Anyway, You will discover that people are going 'somewhere'. Again, not what they are doing.
Maybe it's age .... I'm not sure when, but I've lost that "wana see what are other do with their devices/conenction" feeling some decades ago. I just try to understand what I do with my own stuff ... and that's already hard enough.
Btw, devices like switches, routers etc aren't user accessible, right ?
-
Seems like this thread has gotten off topic. Started with how to make sure all outbound DNS queries are encrypted, which I think we provided a solution.
Client isolation is a completely different subject altogether. Suggest OP open a new thread.
-
@elvisimprsntr said in How to enforce encryption of outbound DNS queries:
Seems like this thread has gotten off topic. Started with how to make sure all outbound DNS queries are encrypted, which I think we provided a solution.
I've implemented the provided suggestion. Even I didn't run extensive tests and long-period packet captures in order to ensure that there's absolutely no unencrypted outbound DNS traffic, I highly suspect that it works. It's okay for now. The internal DNS traffic between the cleints and the pfSense is unencrypted because I didn't manage to configure the clients to use pfSense's capability to process encrypted inbound DNS queries.
@elvisimprsntr said in How to enforce encryption of outbound DNS queries:
Client isolation is a completely different subject altogether. Suggest OP open a new thread.
Yes. I will try to get into client isolation and roll it out at a rainy afternoon. I guess it will be a challenge because I will have to avoid side effects (some clients have to be able to communicate with each other, in example a computer which has to transfer a print order to the printer or a file to the NAS).
