zlacker

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-...).

>>vavrus+(OP)
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?

>>breaki+cc
Hi, I answered it in another comment below.

>>vavrus+(OP)
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.

>>vavrus+(OP)
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)?