Cloudflare (Matthew Prince personally, here on Hacker News few months ago) said that they do reverse that their global stance for Netflix and some other megacorps.
So this is a super-premium feature unavailable to small players.
CloudFlare just changed how DNS behaved and charge corps to make it work as it worked before CloudFlare entered the stage.
Do you have a citation for that? Sourcing from https://news.ycombinator.com/item?id=19828702 , they don’t reverse their global stance for large providers. Their stance is ~”Including client IP via EDNS violates our goal of maximizing user data privacy”, and what they’re working on with other large-scale providers is a way to improve geo-resolution without weakening user privacy.
"We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation".
Well, I might be inaccurate in saying "exactly the same protocol as before", but it is clear that what was available to every webmaster via EDNS, now available only to members of a closed club, via good old EDNS or a proprietary alternative. The latter is more likely, not because of privacy-caring, but because they could now charge it as license fee for using private protocol.
EDNS is an optional field. Client subnet is an optional part of that optional field. It’s relatively new compared to DNS as a whole, and most “webmasters” don’t make active use of it.
The quote you pulled is about Cloudflare’s efforts to build a better standard. They’re talking to the people with the expertise and interest to build that standard. You’ve inferred “proprietary” and “closed club”, and a ton of motive besides, and you’ve copy-pasted that speculation as if it were fact into multiple comment trees.
1. EDNS is needless when you are using your provider DNS. It is needed for public DNS servers. So it is optional, as is needless most of the time. Before launching Cloudflare DNS, the biggest public DNS service was Googles, who developed and implemented EDNS. Then comes Cloudflare and "the people with the expertise and interest" to rethink that.
2. I assume that commercial companies are here to make money, not "a better future" (besides the better future for the shareholders).
If they implement something, the first question is how do they make money with it.
I’m not going to debate your stance on how you assess someone’s motivations, but it does seem like you shouldn’t attempt to present your speculation as fact.
I think they mean they're working on an alternative standard, not anywhere near "we give you an API to match DNS requests to origin city". These talks might have been as simple as "we'll give you [and everyone] geoip information for the datacenters we request from based on IP, and you can load balance off that".
I do not think it has much sense if the standard is the good-old-EDNS or something new, for example supplying city name in a text form instead of hiding last bits of IP as EDNS does.
Google's 8.8.8.8 provides client-ip via EDNS to every webmaster. Zeroing at least 8 bits for privacy - it was made with privacy in mind too. The privacy could be tuned by zeroing 10+ instead of 8+ bits, etc. There is nothing wrong with EDNS and privacy, which would require to abandon ENDS with privacy stancas.
And Google provides that FOR FREE. To everyone.
How can I - as webmaster - get similar info from 1.1.1.1?
Not being a Silicon Valley megacorp.
Again, you keep presenting this as something Cloudflare provides to “megacorps” for money. There’s no evidence this is the case, it’s just your speculation.
I’m really sorry that you somehow depend heavily on EDNS Client Subnets, a feature that was only standardized 5 years ago. But it’s optional, per the spec, and Cloudflare has published their rationale for not enabling it on their resolvers.
Please, tell me - not a megacorp webmaster - how can I opt-in to Cloudflare program available to Facebook/Netflix, to get what is available freely as the source IP of UDP packet in the absence of planet-wide public resolvers and what Google gives for free trying to mitigate the inconvenience caused by the planet-wide resolver.
Indeed, my texts about possible motivation is speculations, but I do understand why webmasters block CloudFlare DNS.
“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 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.
They're not forwarding it at all. A request from LA will come from the LAX Cloudflare DC, and thus plugging in the requesting IP address into some geoip service will show Los Angeles, California. All you have to do to get this working is to fallback to the incoming IP if ECS is absent.
Or time travel to 2010 and try to respond to DNS queries while no servers are sending ECS.
2018-07-15T1958: "Having to do" is not so direct here. Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.
```
> Or time travel to 2010 and try to respond to DNS queries while no servers are sending ECS.
That is exactly what `archive.{*}` does.
It responses to
[+] requests from IPs with geo-information (as in 2010, and it seems to be the most of requests still)
[+] AND to requests from public global resolvers with EDNS, which supply information to which region the server IP will be forwarded (as in 2015)
[-] But not requests from a public global resolver which conceal the source region (as it does a single privacy minded megacorp in 2019)
> 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.
So this is a super-premium feature unavailable to small players.
CloudFlare just changed how DNS behaved and charge corps to make it work as it worked before CloudFlare entered the stage.