All I see is a proxy service and a way for cloudflare to get access to the data

The proxy sees the client IP, but can't look at the encrypted DNS request.

The DNS server sees (deciphers) the DNS query, but not the client IP address.

It's a proxy, but with the sensible data encrypted with the server's public keys to hide it from the proxy. Cloudflare never knows who is sending the requests. How can they get access to the data?

While individual clients may not be easily identifiable, there's still a measure of identification that could be made, if you were to configure the public key DNS server to send a different (but persistent) public key to each IP address which asks for the DNS record. (Probably an ISP's caching nameserver.)

You can't tell how many people are going to be covered by that public key, but you could probably make educated guesses, or combine this with other metadata.

They run both, or buy data from the company that runs the other half?

I'm not sure I see the point,tbh. If you want to control dns, why not resolve yourself, with whatever cache you need? And if you trust a company to do that for you - assuming the two companies do log "their half" - you're just a data breach, data broker agreement or an acquisition away from a commercial entity having all the data (again)?

Do you want Google and your ISPs to see everything? Cloudflare and maybe Apple (not sure what infrastructure they’d have in this if any)? Another company like Cloudflare?

I don’t know the answer but I’m curious to hear everyone’s thoughts. Personally I’d like to prevent Google and my ISPs but Cloudflare could easily become Google in many ways.

I am guessing most if not All future Apple devices / OS will default to use Apple Proxy for DNS?

I would like someone to correct me if I am wrong, but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden, so as long as the destination IP can be observed, the server that you are connecting at can be obtained (I know a server can host many web pages, but this requires the port, which cannot be encrypted either).

So I don't know to what extent this protocol can be useful.

This is "fixed" in DoH the same way it's "fixed" for encrypted SNI: by having a small number of superproviders servicing millions of domains.

With current encrypted SNI proposal, your privacy (between you and the superprovider) is /improved/ by talking to a site behind a large aggregating provider. It sucks (since the superprovider still sees everything), but that's how it is.

edit: added clarifications in (parens)

I'm more worried about persistent, authenticated/ID-linked TCP connections (e.g. APNS) providing the client IP over time to an application service provider (e.g. Apple, Slack, Google, Microsoft, et c), that is, city-level geolocation track history via geoip, than I am the ISP or carrier snooping on what websites I connect to.

Every iPhone connects to APNS for push notifications and stays connected, and, last I looked at the protocol, the client certificate was linked to the device serial number. That's quite a geoip tracklog dataset, and AFAIK you can't turn it off.

It's to the point now that to keep my city-level location private from Apple, I'm not putting SIMs in any of my iPhones/iPads any longer, and carrying a battery powered VPN travel router (with a SIM uplink in it) for them to talk to. Super annoying that it has to come to this.

> but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden

This problem is solved in I2P (https://geti2p.net) by adding a few intermediate hops between you and destination. You will know someone is connecting to the network, but you can't find what they're doing.

> I know a server can host many web pages, but this requires the port, which cannot be encrypted either

You can host multiple web sites in the same port since the 1990s, using name-based virtual hosts (https://en.wikipedia.org/wiki/Virtual_hosting#Name-based). It's rare nowadays to use a port other than 80 (for http://) or 443 (for https://) for public web sites.

yes you CAN if you wish of course. on the other hand nowadays 95% of domains on the Internet can be identified by IP[1][2]. so ISPs still have a pretty good guess what sites do you visit even without DNS or SNI data.

[1] https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-...

[2] https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...

I think there's still pretty good worth in this protocol. DNS is one of the key areas where we voluntarily give away information on every single website we're connecting to to a third party. This protocol certainly helps that--as long as the proxy and recursive resolver do not collude, neither will be able to associate the websites you're looking up with your IP.

It does have its limitations; a MITM can still just as easily see which IP addresses you connect to and determine which websites are associated with those IPs. But ODoH isn't really meant to fix that. A VPN would be better suited to fix that particular privacy concern.

The only solution is onion routing AKA Tor and similar.

"""A key component of ODoH working properly is ensuring that the proxy and the DNS resolver never “collude,” in that the two are never controlled by the same entity, otherwise the “separation of knowledge is broken"""

Essentially this is no better than using an HTTP proxy or a VPN.

A HTTP proxy (or VPN) know exactly who you connect to, even with SSL they know the target name since SNI isn't encrypted.

In this proposal the DNS-proxy doesn't know what you've sent to the DNS resolver.

I still have doubts, 1.1.1.1 was a clear power grab and effort to control more of the internet. DoH in partnership with Mozilla was an extension of that

So I am still suspect of their motives but maybe the negative PR got to be too much