When 184.108.40.206 or other resolvers make upstream DNS requests they decide (or not) to include the client IP address network in the EDNS field to provide de authoritative DNS server with a hint about the client location.
This causes a privacy leak and Cloudflare’s 220.127.116.11 has decided to avoid sending this information upstream as it leaks the client’s IP. This brokes some DNS answers, i.e. https://webapps.stackexchange.com/questions/135222/why-does-1-1-1-1-not-resolve-archive-is/135223#135223
I propose the following solution:
- Client makes DNS request to 18.104.22.168
- The Cloudflare PoP in the anycast network that handles this DNS request includes its own IP in the EDNS field.
- The authoritative DNS server sees a subnet in the EDNS field that kinda matches the client’s location.
- The authoritative DNS server can use this location info to provide custom answers without seeing the user subnet.
This is an option, other would be just spoofing the EDNS field with a random IP subnet with the same GeoIP location of the client.
If the user makes a DNS request to 22.214.171.124 from Madrid (Spain), Cloudflare just needs a random subnet GeoIP located in Madrid to pass along. Not the user’s network but any that has the same geolocation.
This preservers the privacy while providing GeoIP location upstream.
About the spoofing, this could go extremely wrong, the judiciary system is very weak when analyzing IP data, imagine pinning a crime on someone else.
Breaking poorly analyzed evidence procedures is a feature, not a bug. DNS requests are extremely unreliable in terms of proving activity because there are a number of ways a third party can cause your system to generate requests (the most obvious being, convince someone to visit your site and load 1x1 images from other domains just to trigger DNS lookups).
Providing further examples of how this doesn’t actually prove anything can only help to improve the justice system by forcing it to use actual evidence (which is less likely to railroad someone who is being targeted).
Ok, this could be a problem, but they could just use their IP ranges.
You described what’s always been happening, except the information is not within the EDNS option… but the point is that authoritative nameservers see the address from the Cloudflare datacenter closest to you. (typically? I don’t really know for sure if they use some kind of “cache transport” among their PoPs, but I don’t think so.)
When sending queries upstream, the resolvers can not use an anycast address as the source to send from (say 126.96.36.199), because they wouldn’t even know if the answer from upstream would come back to the same place. The source address is of course a natural default when the EDNS option is missing.