This is not the privacy concern, check out the https://tools.ietf.org/html/rfc7871#section-11.1 discussing it. Yes, if you open a connection to the target IP, then all transit networks between client and the target IP (including the target itself) know who is talking. These are on-path parties. The main (privacy) issue with ECS is not this, but that it shares client's subnet with potentially every nameserver on the referral path (including transit networks between the recursive and nameserver), for every name client looks up (even when it might not support ECS). The client is also not in control of the prefix length. /24 for IPv4 is a recommended default, but the recursive may use however much it wants and there's no way to prove to the client that it didn't. Opt-out is also difficult (afaik only getdns and Firefox clients support an opt-out).
Disclaimer: I work on 1.1.1.1. You might not consider your /24 as personally identifying, but others might. The original RFC discusses these problems fairly well (https://tools.ietf.org/html/rfc7871, Privacy notice and privacy considerations). Frank Denis also wrote a good summary on ECS (https://00f.net/2013/08/07/edns-client-subnet/). There's a multitude of ways to fix this - use a whitelist of nameservers to send ECS to to avoid spraying the source prefix everywhere, encrypt the whitelisted connections, or aggregate the source prefix into a largest covering server scope (e.g. if the client is in /24 but nameserver serves the same answer for /16, then using any address in the /16 would do). We're evaluating all of them as there's different trade-offs (see https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...).
I haven't really looked into EDNS, but can't you send fake the EDNS that points to a Cloudflare PoP close to the user (thus giving them a Cloudfare address)?
How about looking up the client's AS via BGP or whois and broadening the scope so that it matches its net block? Then if a CDN peering with a particular ISP wants more granular DNS load balancing they could ask the ISP to announce their routes by region or something like that.
What do you say to the very often heard criticism that the exact IP address will be leaked the moment the user establishes a TCP connection to the domain they just looked up?
This is interesting as a lighter alternative to DNS over Tor. Where is the padding going to be? Basic clients won't add EDNS padding by default, but intuitively there has to be padding somewhere. It reminds me of https://odns.cs.princeton.edu (I haven't seen a working implementation of that one yet). The most difficult challenge is how to present the ultimate choice - use the relay and maybe get slower Internet, or don't use the relay and maybe get tracked. What hasn't been much explored yet is using resolvers just to obtain the delegation (nobody needs to know who the client is for that), but that itself is not without problems.
From operational perspective, it may be easier to maintain a certificate (after all, that's what you already do for an HTTPS service) than a DNSSEC signed zone. It is also easier if you have a multiple DNS providers, since you don't have to coordinate zone resigning. On the other hand, DoT doesn't provide the same properties (like client-side revalidation) as record level DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect solution that isn't deployed. I see the two technologies as complementary, a fairly good DNSSEC deployment at the TLD level can provide a safe way for key discovery at SLD level. There are many facets to this, and it is still fairly early in resolver-to-authoritative DoT standardization process, this is just one of the first steps to show that it's feasible in real world.
I wrote a not very well known LuaJIT to BPF compiler as a part of bcc precisely because of this. It doesn't depend on anything besides LuaJIT (no LLVM, no C, no libbpf, etc). Caveats: it's Lua, it doesn't fast track all the latest from bcc as it's a "for fun" project.
Let me be more specific: they might be fined out of existence and/or executives do prison time if they don't comply. They'll also be told to lie to preserve both the collection method and their businesses' success. Read the Lavabit case records to see FBI doing that. So, they'd be forced to comply and lie to you about it in that scenario. In such a scenario, faking transparency reports would support the lie and/or do some good showing they're stopping other threats. It's not all or nothing despite forced backdoors.
So, you basically have to believe the US-based company you trust won't take 8-9 digit bribe, will accept bankruptcy, and/or has people who will do time for your privacy. I don't trust anybody running for-profit companies to do that except for maybe Levison. Even he might change after weighing damage he received vs probably no benefit of principled stand. Maybe he'll stay in the fight, too. Who knows. I do know Cloudfare has financial incentives to take massive investments and/or avoid massive losses. Might work against users at some point.
To be clear, Im a big fan of Cloudfare. They're awesome. There's just upper limit of trust since they're profit-motivated operating in a quasi-police state (ie a Dual State).
It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks.
ISP can still see the target IP address and SNI. The IP address is sometimes meaningful (single website), but not if it's a CDN or a multi-tenant server. The SNI is being worked on (encrypted SNI, ORIGIN frame, CERTIFICATE frame). The point is none of that matters without encrypted DNS.
> It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks.
That’s why we all have DNSSEC enabled on our domains, right? Right?
DNSSEC is orthogonal to this. Its goal is to prove integrity of records between authoritatives and the closest validator. The validator is most often the resolver doing the recursion, not the client. The client can either revalidate all the answers and/or establish a secure channel between the itself and the resolver (with the added privacy bonus). The reason why many clients don't revalidate is because it's time consuming (basically same complexity as recursor), and fragile (recursive operators can work around DNSSEC screwups by adding negative trust anchors), so it's a tradeoff between convenience and risk.
There's an ongoing work to make revalidation easier - the client would basically ask the recursive to not only provide answer, but also a whole trust chain from a known trust anchor (so it would revalidate the answer without additional queries) https://tools.ietf.org/html/rfc7901
