Comment by akerl_
5 years ago
“We publish the geolocation information of the IPs that we query from”, from the linked comment above. They publish the same info to you and Netflix and me and Amazon.
You keep presenting a difference between what “you” get and what a “megacorp” gets, without any evidence that they’re getting something different from you. You also sidestep here into a complaint against “planet wide resolvers”. To a rounding error, nobody is running their own recursive resolvers. Everybody uses either their ISP’s DNS provider or one provided by a large network entity, virtually all of which are companies. This has been the case for decades. So anybody relying on the source IP of the UDP packet is just out of luck, and has always been out of luck. It’s clear you wish this wasn’t the case, but Cloudflare and Google aren’t really changing the game here, and they don’t owe you optional features because you really want to see user IP data.
I guess you just do not understand what EDNS is, and why it is optional and why its optional-ness is not a pro-CloudFlare argument.
It is very simple:
Query(source IP is an ISP in Paris, no EDNS): gimme IP of "website.com"
WebsiteComDNS: IP of the server closest to Paris
Query(source IP is Google, no-EDNS): gimme IP of "website.com"
WebsiteComDNS: Hm, it is likely Google Cloud, or GoogleBot, answer with IP of own server on Google Cloud
Query(source IP is Google, EDNS: I am acting on behave of an user in Paris): gimme IP of "website.com"
WebsiteComDNS: IP of the server closest to Paris
Query(source IP is Cloudflare, no-EDNS): gimme IP of "website.com"
WebsiteComDNS: where the fuck is CloudFlare? Africa? answer with something random
I appreciate that you’ve moved from assuming what Cloudflare is doing to assuming what I understand. I think this thread has run its course.
I concluded that from sentences like "they don’t owe you optional features because you really want to see user IP data" which reveal misunderstanding on who is sending queries and who decides what to answer to those queries.
From your text it looks like webmasters are sending requests to CloudFlare to get user's IP.
This is totally wrong.
It is CloudFlare wants to see server IP and in the query it has to explain how they will use this info, to which region they will forward my server IP.
That is what EDNS-client-IP for.
If the requester refuses to explain why they need the server IP address for (and their goal cannot be derived from the source IP of the UDP packet, like in the case of local ISP resolvers), they may be denied the privilege of the honor of receiving responses.
2 replies →
> You keep presenting a difference between what “you” get and what a “megacorp” gets, without any evidence that they’re getting something different from you.
I read it in Mattew Prince sentence above
>> You also sidestep here into a complaint against “planet wide resolvers”. To a rounding error, nobody is running their own recursive resolvers. Everybody uses either their ISP’s DNS provider or one provided by a large network entity, virtually all of which are companies. This has been the case for decades. So anybody relying on the source IP of the UDP packet is just out of luck, and has always been out of luck.
1. It is not sidestep. It is my main point. EDNS-client-ip has sense only for planetwide resolvers, and it is "optional" only because of it. EDNS-client-ip was designed especially for Google DNS. When you use recursive DNS of your ISP in your city, the source of UDP packet is in your city. When Google zeroes 8 bits of IP, the EDNS-client-ip is still your city. It is needless to know your exact IP to select the best server for you. CloudFlare refuses to disclose even that approximate location, which gives their anycast CDN an advantage.
2. There is no "decades" of "5 years" history. There is only two points on this timeline: the first: launching Google DNS - which introduced ENDS-client-IP to mitigate caused inconvenience to webmasters, the second: launching Cloudflare DNS - you know the story. The rest (Quad9, ...) are negligible. Yandex DNS might be comparable big and, like CloudFlare, it does not send EDNS-client-ip - for no privacy-caring stances (my speculation: just out of lazyness), but it is regional, all requests from there can be safely rounded to Moscow. So we can consider there are only three cases over there: Google, CloudFlare (commonly referred as "planetwide resolvers"), and all the rest are regional businesses, whose very network ownership discloses location.
>> It’s clear you wish this wasn’t the case, but Cloudflare and Google aren’t really changing the game here,
This is ridiculous. The IP I will know from HTTP logs few miliiseconds later, we are talking about getting origin city from DNS query to answer with IP of the nearest HTTP server.
>> and they don’t owe you optional features because you really want to see user IP data.
So webmasters do not owe to answer when CloudFlare want to see server IP data, ok?
The divorce of indy webmasters with CloudFlare DNS is very natural, I just wonder why it is no massive.
Likely because DNS worked just fine without EDNS client IP (and indeed DNS) for decades. For example, I remember the use of the 4.2.2.2 server, which was globally accessible but US-based. The responses though were 100% usable wherever you were on the planet. Equally, a national ISP running DNS servers would get you a country at most; a /24 gives you city or better location, carrier-grade NAT aside. Latency between the client and server may be slightly higher, but that's the end user's problem and not an issue for the site. In any case, it sounds like the Cloudflare source IPs for recursive DNS lookups are locatable via GeoIP, so I fail to see the problem.