DNS over TLS (DoT) config still shows traffic with destination port 53
-
Hi,
so I configured DoT on all my interfces according to the pfSense configuration recipe (except of the OpenVPN interfaces). I also created port forwards according to this configuration recipe. When resolving domain names I do see traffic to my configured DoT name servers with destination port
853
.However, occasionally I still observe DNS traffic to port
53
which I do not understand. There are no corresponding firewall states indicating that this traffic originates from any of the local interfaces. I'm also not actively requesting anything to be resolved, it seems to happen randomly and initiated by the router itself. A traffic capture on the WAN interface shows following communication (xxx.xxx.xxx.xxx
is my WAN IP andaaa.aaa.aaa.aaa
andbbb.bbb.bbb.bbb
are my DoT servers):No. Time Source Destination Protocol Length Info 1 0.000000 xxx.xxx.xxx.xxx aaa.aaa.aaa.aaa DNS 86 Standard query 0x5613 PTR 144.94.64.125.in-addr.arpa 2 0.022667 aaa.aaa.aaa.aaa xxx.xxx.xxx.xxx DNS 86 Standard query response 0x5613 Server failure PTR 144.94.64.125.in-addr.arpa 3 0.022831 xxx.xxx.xxx.xxx bbb.bbb.bbb.bbb DNS 86 Standard query 0x5613 PTR 144.94.64.125.in-addr.arpa 4 0.063841 bbb.bbb.bbb.bbb xxx.xxx.xxx.xxx DNS 86 Standard query response 0x5613 Server failure PTR 144.94.64.125.in-addr.arpa 5 0.064231 xxx.xxx.xxx.xxx aaa.aaa.aaa.aaa DNS 86 Standard query 0x5613 PTR 144.94.64.125.in-addr.arpa 6 0.081720 aaa.aaa.aaa.aaa xxx.xxx.xxx.xxx DNS 86 Standard query response 0x5613 Server failure PTR 144.94.64.125.in-addr.arpa 7 0.081810 xxx.xxx.xxx.xxx bbb.bbb.bbb.bbb DNS 86 Standard query 0x5613 PTR 144.94.64.125.in-addr.arpa 8 0.124475 bbb.bbb.bbb.bbb xxx.xxx.xxx.xxx DNS 86 Standard query response 0x5613 Server failure PTR 144.94.64.125.in-addr.arpa
Does anyone have a clue why this is happening? This specific IP seems to belong to
a.root-servers.net
andnstld.verisign-grs.com
.BR
-
What do you have set for pfsense to do, what version of pfsense are you running.
Old versions before they added the option.. Could have some weirdness depending on your exact configuration.
Why are you hiding the destination IP there?
If those are you dot servers, then asking for the PTR of an IP to your dot servers is what should happen.. But if pfsense asks the remote servers itself, it wouldn't use dot - it would use 53... This is why you have to make sure pfsense ONLY ever asks itself (loopback).. Anything listed in general that it asks directly would just be over 53.
-
Thanks a lot for your inputs!
@johnpoz said in DNS over TLS (DoT) config still shows traffic with destination port 53:
What do you have set for pfsense to do, what version of pfsense are you running.
Apologies, I forgot to provide the basic info. I'm running the Community Edition v2.5.2-RELEASE, so latest/greatest as of now.
Old versions before they added the option.. Could have some weirdness depending on your exact configuration.
I have the default behaviour configured, i.e. Use local DNS (127.0.0.1), fall back to remote DNS Servers as my understanding is that if the local DNS server cannot resolve the request it should ask the remote DNS servers, im my case the DoT servers. Is this not the correct setting?
Why are you hiding the destination IP there?
Because my WAN IP is also a destionation IP for the DoT server responses. As mentioned in my post,
xxx.xxx.xxx.xxx
is my WAN IP andaaa.aaa.aaa.aaa
andbbb.bbb.bbb.bbb
are my DoT servers.If those are you dot servers, then asking for the PTR of an IP to your dot servers is what should happen.. But if pfsense asks the remote servers itself, it wouldn't use dot - it would use 53... This is why you have to make sure pfsense ONLY ever asks itself (loopback).. Anything listed in general that it asks directly would just be over 53.
I'm not sure if understand that. The snippet above shows only traffic between my WAN interface and my DoT servers. However, I wouldn't expect any traffic to destination port
53
, only853
-
@cybis said in DNS over TLS (DoT) config still shows traffic with destination port 53:
I wouldn't expect any traffic to destination port 53, only 853
And again.. When pfsense does a query it would NOT do dot, it would just do standard query over 53.. So your setting to fallback to remote dns, would allow pfsense to do queries to those IPs over 53..
If you want pfsense to NEVER do normal dns query to what you have listed in general, ie your dot server IPs. Then you need to set the local 127.0.0.1, and ignore remote dns..
Now pfsense will only ever ask unbound, which unbound will forward via dot to what you setup.
-
Oh, obviously I had a misconception on how DNS works on pfsense. For me "the firewall" was actually
unbound
in 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 ownI'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