1.1.1.1: Fast, privacy-first consumer DNS service

This is the Cloudflare resolver, right? What's the "privacy-first" part about? It's just another third party DNS host. They haven't changed the protocol to be uninspectable and AFAIK haven't made any guarantees about logging or whatnot that would enhance privacy vs. using whatever you are now. This just means you're trusting Cloudflare instead of Comcast or Google or whoever.

On the contrary, they've taken 2 big steps that are better than ISPs (not sure about Google):

* no logging

* DNS over HTTPS

Google is one of the first ones using DNS over HTTPS.

BTW if you want to use DNS over HTTPS on Linux/Mac I strongly recommend dnscrypt proxy V2 (golang rewrite) https://github.com/jedisct1/dnscrypt-proxy and put e.g. cloudflare in their config toml file to make use of it.

The whole point of encrypting DNS traffic is to hide it from the likes of Google.

For me personally it is much more important to hide my DNS traffic from my ISP instead of Google, etc., even though I don't live in the US.

I pay them to access the internet, every further information they gather about my internet activity does not mean any benefit for me.

Hiding DNS traffic from your ISP is pointless when you have to give them the IP that gets resolved anyway for them to route your traffic.

Not really. Typically the query includes much more information (the site you want to visit) than the response (an IP potentially shared by thousands or millions of sites).

Even with https, the name of the site is sent in clear when the connection to the site is established (this is SNI).

Back when they chose this design for SNI, I’m sure someone argued that it was fine because DNS had already leaked the hostname anyway :)

It's really hard to fix this. https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... is the state of the art -- note that's a Draft, and really, really not finished, help is doubtless welcome.

If it was easy, it would have been done during the TLS 1.3 process, but after a lot of discussion we're down to basically "Here is what people expect 'SNI encryption' would do for them, here's why all the obvious stuff can't achieve that, and here are some ugly, slow things that could work, now what?"

It is hard because of the TLS's pre-PFS legacy and to some extent also because of (very meaningful) intention to reduce roundtrips. The way to do SNI-like stuff is obvious: negotiate unauthenticated encrypted channel (by means of some EDH variant, you need one roundtrip for that) and perform any endpoint authentication steps inside that channel. This is what SSH2 does and AFAIK Microsoft's implementation of encrypted ISO-on-TCP (eg. rdesktop) does something similar.

Edit: in SSH2 the server authentication happens in the first cryptographic message from server (for the obvious efficiency reasons), and thus for doing SNI-style certificate selection there would have to be some plaintext server-ID in first clients message, but the security of the protocol does not require that as long as the in-tunnel authentication is mutual (it is for things like kerberos).