To forward or not to forward DNS over TLS

So I have been forwarding to quad9 using DoT for sometime now. No problems so far on 2.6.0-RELEASE (amd64) running on a generic hardware.

BUT. I have been reading the comments that make me think I do it for the wrong reasons... I wanted to hide my DNS queries. It seems that it's not doing it since the SNI of the request is still not encrypted and ESNI, that would correct this, is not fully supported everywhere.

So since it is basically useless to forward DNS over TLS for my goal, I think I should go back to the default resolver setting, and gain performance and peace of mind regarding the "neutrality" of the root DNS servers I would be contacting then.

One concern remains, doing that: How can I be sure my ISP is not covertly intercepting my DNS traffic? I've seen some users here say that they were in that situation. How they discovered that is what interests me.

Any thought would be appreciated.

jimp

@marchand-guy said in To forward or not to forward DNS over TLS:

BUT. I have been reading the comments that make me think I do it for the wrong reasons... I wanted to hide my DNS queries. It seems that it's not doing it since the SNI of the request is still not encrypted and ESNI, that would correct this, is not fully supported everywhere.

That would only necessarily be true for HTTP/HTTPS. Other protocols may not reveal the hostname, depends on how they are encrypted. For example if you used DoT to lookup a VPN service and then connected to that VPN service, the ISP wouldn't know the name you used in most cases, though they may be able to tell what the traffic is by DPI or other means.

So since it is basically useless to forward DNS over TLS for my goal, I think I should go back to the default resolver setting, and gain performance and peace of mind regarding the "neutrality" of the root DNS servers I would be contacting then.

It depends on what you want to hide and from who. Nothing is perfect, but sometimes it's good enough.

One concern remains, doing that: How can I be sure my ISP is not covertly intercepting my DNS traffic? I've seen some users here say that they were in that situation. How they discovered that is what interests me.

The main way to accomplish that is via DNSSEC. DNSSEC is a means to assure that the DNS response came from a server authorized to respond for a domain. If an ISP did something shady, DNSSEC would be broken in the response. That said, that's also another advantage of forwarding with DoT: Even without DNSSEC, so long as you're validating the cert+hostname, you know the reply you're getting is from the forwarder you asked, and not potentially something in between that altered the reply.

Ultimately if your goal is to hide your activity from your ISP, then tunneling as much of your traffic over a VPN as possible is the way to go. But then once it hits the VPN provider, it's fair game again. So you have to trust the VPN provider not to mess with things, log, etc, and trust their upstream connectivity.

johnpoz

@marchand-guy said in To forward or not to forward DNS over TLS:

SNI of the request is still not encrypted and ESNI

esni is dead, the new thing for encrypted sni is called ech (encrypted client hello).

https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08

While Jim is correct if you doing something else that uses some form of encryption to talk to where you are talking - using dot to do your dns lookup would be hidden from the isp. And as long as you don't give away the server name your talking to when you start the encrypted conversation with them after you got the ip via your dns - then the only thing the isp would know would be the IP your talking to, and whatever info they might be able to glean from the sort of conversation patterns or other dpi seen in that traffic.

But if users think they are hiding from their isp that they are going to www.somedomain.tld when they use dot to look up the IP of www.somedomain.tld they are most likely mistaken, because in the normal client hello when you start a https conversation its right there in the clear..

Just fire up your fav sniffer and look at your traffic and see for yourself, and you for sure not hiding the IP your going to, now the IP might be some IP in on some CDN that doesn't really tell them exactly "where" your going - but they for sure know the IP your going to. What info they can clean from that might vary to hey that is just cloudflare or aws it could be 1 of 100 different sites, or hey that IP is www.domainx.tld..

Not saying dot or even doh doesn't have use cases where it would be the lessor of two evils.. The problem I have with doh is the browser making the choice to use it without explicit acknowledgement from the user that is what they want to do.

And I am against the promoters of encrypted dns saying its hiding your traffic from your isp - when most likely it is not. Or is protecting your privacy - when your just handing over all your dns to company X, and your not actually stopping your isp from seeing it either. Now your isp knows where your going, and this company X gets everything handed too them on a silver platter. Is that more private?

Kind of like sex toy box you mail order, not saying sex toys on the side of the box - but if you just look at the return address clearly marked on the box it says from sex toys, inc ;)

Now if the isp wants to see where your going.. Does it make it a bit harder vs using the ISP dns, sure, does it make it a bit harder then just sniffing dns traffic - ok yeah. But pretty much every time you fire up some https connection - your isp can with not much effort glean the name of the server your wanting to talk too.. and for sure the IP you are going to - so what exactly are you hiding?

I resolve.. for starters I see no added value in sending all my dns to some company X, now if you like how they filter or some other service they provide - hey go for it. If it allows you to circumvent some gov or isp restriction on looking up something - that would be added value that makes sense for sending them all your stuff.. Or you could just do a conditional forward where if they block domainX.com records - forward that to company X to hand back to you over dot. And resolve all your other stuff. To be honest this might be more sneaky in that they would see normal dns flowing from your connection, and then just some 443 traffic, which could be hidden in all your other 443 traffic, etc.

I also use qname minimization - so normally when I do ask roots for domainx.tld, they really only see that I asked for the NS of .tld.. And they send me back the name servers for .tld, It then asks the tld NS hey what is ns for domainx.tld - they don't know that I am looking for www.domainx.tld or host.domainx.tld, etc. Only the authoritative NS for domainx knows I want the IP for www.domainx.tld..

now qname min can fail sometimes, and then unbound will fallback to sending the fqdn.. Some domains and multiple layers of cname, etc. can break this.. But in general, not always sending the roots or the gtld servers the fqdn of what looking for.

Example I asked unbound from my client for host.testingdomain.mov, I was pretty sure never looked up anything before in the new .mov tld.. So you can ask roots for just mov, it answers, then ask the NS for .mov hey testingdomain.mov - this failed, so unbound did send the fqdn, which also failed - because there isn't anything for that domain, etc. But if would of gotten back the NS for testingdomain.mov - they would of been asked for the fqdn..

I do not have a reason that makes sense to me to use dot or doh, and I don't see anything that will change my mind any time soon. If I was wanting to hide traffic from my isp, or circumvent their shenanigans they were doing with dns - then I would send all my traffic through the vpn, and just resolve through the vpn for my dns.

Also while pretty sure companyX dns is quite robust, and less likely to fail than say your ISP - they could fail.. So you using company X and Y for your dns.. This can have its own problems if one filters and the other doesn't - since you really can not be sure which NS unbound is going to forward to when you have multiple.

When you resolve - doesn't matter if company X and Y both dns fail - since just using roots and the authoritative NS for each domain. So the whole internet dns would have to be down for me to not have dns, or my connection down - if either of those things happens, doesn't matter ;)

If anyone wants to forward, good for them, more power too them. Just not for me - and yes unbound should work without issues when forwarding be it in the clear or over dot, etc. if unbound says they can forward with dot, be it over ipv4 or ipv6, etc.

I am also old networking guy, I like to sniff and see what is on the wire - encrypting everything makes it harder that is for sure to do say the above examples.. And can bring its own issues as well. And I could care less if my isp knows I go to the netgate forums or amazon ;) Stuff I don't want them to see they don't see because that traffic is encrypted.. I just don't care if they see the dns query to whatever site on the internet ;)

And I can tell you for sure there have been a few post around here that host overrides are not working - reason is their browser was doing doh and not even asking unbound. Uggh ;)

jimp

It's primarily about doing whatever is right for a person's situation and preferences.

Just need to be aware of the limitations and disadvantages of each method.

We've had reports of some ISPs doing something to break resolving, either rate limits on DNS or the # of DNS servers a client is contacting, it's not clear what. Forwarding for those people works but resolving doesn't.

Also if someone has already made the decision to forward all their DNS to company X/Y without DoT, and that company supports DoT, they may as well turn on DoT since it's potentially a little more advantageous. As long as someone is aware of what it is and isn't doing, the only real drawback there is a potential performance hit (and maybe some problematic edge cases with DoT, as happened in that other thread).

johnpoz

@jimp well put and agree..

edit: Dot doesn't rub me the wrong was as much as doh does.. If some client on my network was doing dot, I could just block 853.. Sure they might just use another port. But at least by design its easy enough to prevent some client from doing it.

Doh - while sure there might be cases where you don't want to use the local dns.. But browsers turning it on - for the good of their users is BS plain and simple.. Just ask the user if they want it, don't make it more painful to turn off then on that is for freaking sure ;)

And then hiding it in normal 443 traffic - no your not wanting to circumvent a local admin from blocking <rolleyes>

RobbieTT

Circumstances vary, especially with different ways different countries regulate ISPs, their national infrastructure, government agencies and host nation laws.

I know my ISP isn't looking at or interested in my DNS queries, what limited collection they do indulge in tends to the minimum required by law, which is very little in my case. Does my government collect my DNS queries - of course. Can they look at them, well depends on the judge. Can it be abused, on occasion yes, to the detriment of everyone.

DoT has a role in the overall footprint you leave, no matter how you view things. It is a measure of control; far from perfect but unlike DoH at least it can be managed. A smaller footprint means being better prepared for whatever come next with technology, crime, laws or regulation. Data never really goes away, so encrypt as much as you can.

I'm reasonably content that my DoT queries flow through a disinterested ISP, a nation infrastructure that may or may not have your best interests at heart, regulated by honest courts and dubious governments, on its way to a country that applies additional laws and barriers to a forwarder that keeps no logs and a court system that is belligerent when it comes to protecting individual's data above everything else.

DoT is a good thing. We should use it whilst striving for more privacy and security. Never think what you do today does not matter; even if it does not right now it may in the future and data never really disappears once it leaves your control.

️

johnpoz

@robbiett said in To forward or not to forward DNS over TLS:

whilst striving for more privacy and security

But your not hiding it from anyone - your just handing it over to someone that says "trust us"..

Your isp is bad - we are good.. Do you really think they are providing this service and not getting something from it?

Where does the privacy and security come in?

Never think what you do today does not matter.

Very true - and you forwarding to company X all your dns queries is handing them what your doing today on a silver platter. All of it..

RobbieTT

@johnpoz It is going to a company of my choosing, under legislation and auditing methods I approve of. I am not broadcasting it.

WOW! Thank you all.
I now feel a lttle better with my choices.
It boils down to this: do I trust quad9 over cloudflare or google, for example?
Yes. Based on the research I did about them. And it seems I am not the only one. But it is exactly and only that: trust.

Thanks again for all your good inputs.

UPDATE:
To try to see what is transmitted while forwarding to quad9 using DoT, I captured the traffic on port 853 (and 53 to make sure) of the WAN interface.
From a client on the LAN, doing many nslookups to many different destinations (to avoid cached results), no readable domain name destination (besides the quad9 server contacted) where shown using Wireshark.
That is what full encryption on DNS should look like.

Cheers!

SteveITS

@marchand-guy Since DNSSEC was mentioned above, just note it should be disabled when forwarding.
https://support.quad9.net/hc/en-us/articles/4433380601229-Setup-pfSense-and-DNS-over-TLS
"Disable Enable DNSSEC Support if enabled.
DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures."