DNS over TLS (DoT) config still shows traffic with destination port 53
-
Oh, obviously I had a misconception on how DNS works on pfsense. For me "the firewall" was actually
unboundin this scenario. I'm still not quite sure why there is a difference at all, i.e. why pfsense should do any DNS requests on its own
I'll change the DNS resoultion behaviour to Use local DNS (127.0.0.1), ingore remote DNS Servers. Thanks a lot for your help!
-
unbound is just a dns resolver/forwarder software running on pfsense. Pfsense has its own dns client.. Just like windows or any other linux or freebsd setup. Unbound is not a client its a resolver/forwarder - clients ask it to do dns queries for them which it either fully resolves or forwards.
Pfsense itself (freebsd) wouldn't be able to ask unbound for anything if it didn't have dns client.. This dns client does not understand how to do dot. So if you ask unbound and unbound is set to do dot, then dot will be used to lookup what you asked for.
But if pfsense (freebsd) just wants to look up something on its own, like the IP in its firewall log or hey should check if update available, or if there are any new packages. It would just do a normal dns query for that - if you told it via dns setting it could ask 1.2.3.4 for that - then it would via a normal dns query over 53.
-
Thanks a lot for the explanation. That makes complete sense now.
The pfsense DoT configuration recipe should be updated to reflect that information. Apparently it was not clear to me
I would assume that I'm not the only one with that misconception -
@cybis said in DNS over TLS (DoT) config still shows traffic with destination port 53:
I would assume that I'm not the only one with that misconception
Well that is the reason the options were added, because of this very thing.. Before those options were allowed to be change - it just did the default, fallback to remote..
There are many many users that have misconception about dns - part of the reason that dot and doh have gained favor is user not actually understanding how dns works.. Dot or Doh do not stop your ISP from knowing where your going.. Every connection even https still sends the sni in the clear.. So its not like that can easy get this info if they wanted it.
Trying to hide your dns via dot or doh doesn't really provide you any more privacy or security. Your just handing over all your dns queries to whoever you forward to.. What it can do is possible prevent and isp from doing any sort of dns interception, or manipulation. But your not really hiding where your going from your isp that wanted that info.. They have the sni they can look at they can look at the host hearder in normal http, they can even if using esni (dead) or its replacement ech still know the IP you going to.. While this could be less useful in the age of CDNs hosing everything from amazon to private websites. They are your isp - they can get this info really easy anyway. Problem with esni or ech is it requires the destination server to support it and set it up.. That if does happen takes YEARS and YEARS to happen.. Shit look at dnssec, and the dismal deployment percentage..
Its biggest use doh more so than dot is local dns bypass - most likely doing filtering.. Can sure let you resolve more fqdn for ad servers if you ask me, vs if it never gets asked for because the local dns is filtering it. Dot is easy enough to block at the local level, while doh on the other hand hides on normal https traffic..
Sorry to go on a rant ;) But not a fan of dot or doh.. And sure not a fan of browsers or anything else taking it upon themselves to point to some dns other than what I setup on the box or my network.. If they want to provide that feature in their software - great, but it should be 100% mandatory opt in.. I shouldn't have to go out of my way to make sure it doesn't happen.. Because its default, etc.
I personally think the default should be 127.0.0.1 - do not use remote.. But that is possible to break many a configuration that isp block outside dns, or vpns that block dns other than their own, etc.
Back on topic - yeah the recipe could prob be updated to reflect what that setting does to make it more obvious... You could put in some feedback or open a redmine.. Back in the day when docs were wiki managed could of edited for you..
-
I'm actually not trying to hide anything from my ISP as they anyways know to which IPs/services I connect to. It's just and extra step for them to query the domain names based on the destination IPs as they don't see it directly in the DNS traffic.
It's more about any 3rd parties that are potentially sniffing my traffic. Sure, they could also look up the destination IPs but they can't manipulate it and I guess it's a matter of preference. I believe that each and every communication channel should be encrypted by default. And setting up DoT was not a big effort (except of the pfsense misconfiguration
). I'm also utilizing EU based DoT servers with zero-logging, i.e. I'm trusting them at least as much as my ISP.Regarding browser and default DoT/DoH servers: I don't like that either. Users should decide whether or not they would like to use such a service and choose their servers themselves.
Thanks for the hint, I'll provide feedback regarding the pfsense documenation on DoT.
-
@cybis said in DNS over TLS (DoT) config still shows traffic with destination port 53:
Sure, they could also look up the destination IP
Its not that - where you go is in the clear in the sni or host headers, they don't have to look up anything.. If they are sniffing the traffic the fqdn your going to is right there in the sni for all to see.. If they are sniffing the traffic its not any real extra work.. Just slightly harder then you handing them the dns directly.. But if your saying they are sniffing.. Not exactly sure how they are doing that unless they are in cahoots with your isp ;)
Here..
If have a sniff of your traffic its trivial to dump out all the sni and or host headers..
edit:
If you had a large pcap of data it would be like 1 line script to parse through the pcap and just dump source IP to sni/host hearders, with timestamps, etc.. With dns - all they know is you asked for something. They don't actually know if you went there ;) With a pcap, they know exactly where you went, and when, etc.doh or dot does not protect against this at all.. If anything you could prob argue that not handing them your dns or letting them sniff just dns traffic would have them move to sniffs of your ssl traffic and get more info ;)
Until such time that some form of encrypted sni is main stream, dot or doh doesn't provide anything but handing the people running the dns more info.. While your isp or anyone sniff still has access to the info as well. Unless you have need to circumvent something that normal dns is being manipulated in some way.. I would just resolve, this way your not handing anything to anyone on a silver platter. Unless you think the roots and gtlds are spying on you as well ;)
-
Indeed, I was not familiar with the SNI header. I should do packet captures more often and get familiar with it again
Haha, well, rumor has it that certain 3-letter agencies are in cahoots with everyone and are sniffing/recording even encrypted traffic so that one day when quantum cryptography becomes available the data won't be encrypted anymore
But as mentioned previously, I'd like to have encrpyted DNS traffic simply because it helps with the data integrity, i.e. it should prevent the traffic from being manipulated.
-
@cybis said in DNS over TLS (DoT) config still shows traffic with destination port 53:
it should prevent the traffic from being manipulated.
Unless where you forward is doing the manipulation ;) hehehe
I will get my dns from the horses mouth, and hope they are doing dnssec as well. But its easy enough to spot dns manipulation.. Unless its done very very well, and at a very low level with minimal manipulation..
Dot and doh come with their own headaches and overhead as well.
-
@johnpoz said in DNS over TLS (DoT) config still shows traffic with destination port 53:
I will get my dns from the horses mouth, and hope they are doing dnssec as well.
Im not a native speaker ... whats a horse mouth and why does it offer DNSSEC
-
From the authoritative nameserver, resolve vs forward. This is what pfsense does out of the box, it resolves vs forwards.
dnssec is how you can know the dns has not been manipulated because the records have been signed by the owners of the domain.. Not all domains do this - but they should.
https://dictionary.cambridge.org/us/dictionary/english/straight-from-the-horse-s-mouth
(straight) from the horse's mouth If you hear something (straight) from the horse's mouth, you hear it from the person who has direct personal knowledge of it.https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
