[vtsingaras]

The point presented by the post is plain wrong, people were using non-ISP recursors for a long time already and this was not problem due to the fact that EDNS Client Subnet has been a thing for a while now.

The problem mentioned in the post is specific to Cloudflare, as they do not support EDNS Client Subnet anyway, even over plain UDP53

more reading: https://www.samknows.com/blog/dns-over-https-performance

[jgrahamc]

Mozilla did their own testing of DoH and its effect on performance in conjunction with Akamai:

Test announcement: https://blog.mozilla.org/futurereleases/2018/11/27/next-step... "To do that, we’re working with Akamai to help us understand more about the performance impact."

First results: https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... "The results were strong! Like our previous studies, DoH had minimal impact or clearly improved the total time it takes to get a response from the resolver and fetch a web page."

Final post: https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-... "Furthermore, we found that web pages that are hosted by Akamai–a content distribution network, or “CDN”–have similar performance when DoH is enabled."

[gsich]

And nowhere is "TCP" mentioned. I suppose the connection just builds up itself in 0ms time.

Sure if you already have <5ms latency to your DNS, the additional RTT from TCP and TLS won't matter much. For the rest: they will.

[judge2020]

That's valid, but it's also why HTTP/3 is being pushed for 1-RTT and 0-RTT connections (0-RTT is most likely going to be enabled for their DoH if it isn't already)

https://blog.cloudflare.com/even-faster-connection-establish...

[throw0101a]

And for that you need TLS tickets/cookies, don't you? (So you can resume your crypto state.) Isn't that a good way to track users?

Instead of a query coming from an IP (probably NATed with IPv4), you can identify individual browsers AFAICT.

[tialaramex]

The DoH server gets to track users if they use a resumption method, yes. As I understand it Firefox puts extra work in to ensure that it doesn't share the backend cache between your HTTPS service and the DNS resolver so there's no risk that if the DNS service and the HTTPS site you're visiting are owned by the same people they can correlate that, but they would be able to see that it's the same browser asking for say, camelporn.example and visit-arabia.example

If you disabled resumption you could get rid of this issue at a cost of one extra round trip per DNS lookup.

Nobody else gets to track users this way (at least in TLS 1.3 and I'd assume DoH implementers will use TLS 1.3 since they are of similar vintage) because the keys aren't re-used so the identifier for the key will just appear to be random noise each time.

[gsich]

That is resumption. So you still have the overhead for the first connection. Assuming that you don't DNS query every few seconds you are gonna suffer.

On a side note, last I checked Quad9 and Cloudflare (need to recheck that) almost immediateley close the connection once you finished your query. Tested with DoT but the same TLS handshake is required for that.

[tialaramex]

I think you're confused. You're correct that the first connection is 1-RTT but the resumption is a new connection and is 0-RTT using a resumption PSK.

Let's say your browser was left open when you went to work, you get home, click the bookmark for your preferred porn site, and now the browser needs to resolve the FQDN for that site. How fast is that?

So if you have TCP fast open and 0-RTT TLS 1.3 that's exactly one round trip for your answer, just like traditional unencrypted DNS.

The DNS query gets wrapped as an HTTP request, which gets wrapped as a TLS plaintext, which gets sent as TLS 1.3 early data, which all goes in the Fast Open TCP packet.

The server checks the Fast Open cookie, opens the TCP connection, matches the PSK, unwraps the early data, unwraps the HTTP request, unwraps the DNS query

The server finishes the TLS handshake on the now open TCP connection, and using the now encrypted channel it sends back the HTTP response, which wraps a DNS answer and that goes back as the first TCP packet the other way.

Same number of round trips and packets as for DNS. It's very ugly and QUIC in particular will tidy this up considerably, but it's secure and fast.

[vtsingaras]

But the original post makes not mention of anything other than non-optimal answers.

Before comparing various methods of contacting a recursor you have to decide what your threat model is; does it include your ISP snooping on you? If so then an encrypted transport of your dns queries is mandatory. If it doesn’t, stick with DNS53.

[jrwr]

DoH can use UDP, but most dont, Also most people's local DNS (Here in America) Provided by their ISP is pretty shit. In my experience working at a MSP, having a local DNS server is always best