Follow

I can’t think of a technology that has divided the infosec community quite like dns over https has. It’s almost as bad as vi/emacs before vi won.

@jerry the appropriate response is clearly to begin advocating for https over dns

@jerry Hah! I see what you did there.. But you know the only reason vi won was because all the emacs users have RSI now from all those "chords" they liked to type.

@jerry At the same time, I'm torn on DoH. On one hand it's nice to protect DNS traffic from snooping by your ISP, but on the other hand the acronym-inception is killing me! Oh, and the fact that my DNS proxies are going to need a complete re-think is bugging me too.

@JohnsNotHere it’s change and as an old person, I say change is bad!

@jerry
There are only two camps: those who favor DoH and those who are wrong.

@jerry Really? I don't think the community is really divided, or I suffer from self-inflicted filter bubble. Basically everybody in my timeline is against it.

@x_cli @jerry Can't talk for everyone, but I myself is divided, there are both good and bad things with DoH. I never had that problem when it came to vi/emacs

@berrot @jerry Cloudflare and Google unfair advantage as CDN is terrible for the Internet. Firefox downgrade mechanism is dumb AF. Using HTTPS instead of UDP is also dumb AF, performance-wise. Splitting view between OS and Apps will lead to terrible and painful troubleshooting sessions.

I don't see what's good about it, except doing stuff that were done better by other existing technologies (dnscrypt, for one).

@x_cli @jerry I do agree with most of what you are saying here, and sure, it moves the privacy issue away from the ISPs over to Cloudflare and Google (which is bad). Sure , there are other technologies that does the same, but non of them reached ciritical mass, but this might be the way to buypass privacy issues locally. I think I rather would let Google know what I'm doing than some f... gouvernment (I don't think I have an issue with that here in Norway,, but...)

@berrot @jerry I'm not talking about privacy, although of course it is the elephant in the room.

The Cloudflare/Google main issue that most people are missing is that they will have a knowledge of the real client IP, while other CDN won't have that info.
With EDNS0, there was the subnet-client extension that was somewhat standard. Now, only Google and Cloudflare will have that knowledge, and this will most certainly kill their competition.

@berrot @jerry (to be clearer, having knowledge of the real client IP is useful because it enables a CDN to locate the datacenter closest to the client to serve the content efficiently. Without that knowledge, you can only guess where the client is, based on the recursive server IP address... which will be the IP of Cloudflare or Google resolvers... i.e. their competitors)

@x_cli @jerry Oh, damn, I didn't even think about it in that way. Of course you are right and now I understand what you did mean with an advantage over their competitors...

@x_cli @jerry CDNs isn't something I work with, but if someone use Googles regular nameservers, wouldn't this create the same issue? There's is quite a few that use those since they are easy to remember.

@berrot @jerry AFAIK, Quad8 uses EDNS client-subnet, which is somewhat standard. I can't find anything in DoH spec that mimics what EDNS client-subnet does. It may come afterwards... or not.

Cloudflare does not honor EDNS client-subnet "for privacy reasons", and probably won't for DoH. This has nothing to do with unfair competition "of course".

@x_cli @berrot @jerry I am using DoH for over a year, and I am glad it is available. Just as I am able to select my search engine, I can select my DoH provider in Firefox. I can now browse with sufficient safety and privacy in public wifi without having to use a VPN.
Most folks who criticize DoH don't use it and don't understand how to use it.

@rudolf @berrot @jerry I have been paid to study DNS and its extensions for five years for a gov infosec agency, and I made numerous publications on my findings, which include a cache poisoning attack, a cross-implementation DoS vulnerability, and several studies of the DNS landscape, in France and worldwide. I don't need to use daily a protocol to evaluate its issues.

@rudolf @berrot @jerry Being a power user capable of hosting a DoH server or even caring enough to select one singles you out from the general population that will use the default.

@rudolf @berrot @jerry Also, you are making use of the false dilemma fallacy by stating this is either VPN or DoH. There are several other ways to encrypt DNS traffic, including DNScrypt, DNS-over-TLS and even LDAPs in some weird settings.

Finally, encrypting DNS is hardly enough to ensure your security on a public wifi. Please use a VPN for that use case.

@x_cli @berrot @jerry Listing your credentials is a silly thing to do here. And it won't make what you say any better.

I never said 'either' VPN or DoH. I said I can be safe enough with DoH so I don't need a VPN. Using a VPN makes me a person of interest, DoH is much more discreet. If I were Snowden, I would decide otherwise.

Comparing the expertise someone needs to set up a DoH server/frontend with what one needs to enter a URL in a settings menu of their browser is grotesk.

@berrot @jerry I have to admit I was wrong. Sorry about that... :(
Google already supports EDNS Client-Subnet for DoH.
Cloudflare does not.

The impact is very well studied here: samknows.com/blog/dns-over-htt

The performance hit of not supporting EDNS client-subnet is very clear and demonstrates the unfair competition I was talking about. Maybe Cloudflare is honest when they say that do not support client subnet for privacy reasons, but clearly they benefit from a "lucky" side-effect.

@x_cli @jerry Thanks a lot, a very interessting article. A bit surprised that the performance impact on DoH wasn't bigger. Sure, I didn't expect it to be extremly huge, but....

@berrot @jerry "We intentionally do not include the TLS setup time in the DoH results". That's because they assume that the cost is amortised across multiple requests. That's a fair assumption, but it misrepresents the case where the connection is shut down because the resolver could not maintain all client states in memory.

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.