it doesn't matter if your dns resolver leaks part of your ip address to archive.is's dns servers when you're about to connect to archive.is from your ip address anyway. the only thing dropping the edns client subnet does is prevent services you use from giving you a server that's closer to you when you do the dns lookup. this performance issue, of course, does not affect sites using cloudflare.
To circumvent this, Cloudflare would have to reverse their global stance or make a special exception to satisfy archive.is.
It’s unclear how we could draw “anticompetitive” from this.
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.
"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.
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.
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.
Indeed, my texts about possible motivation is speculations, but I do understand why webmasters block CloudFlare DNS.
I wonder why there are so few of them.
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.
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
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.
They indeed are, "for your privacy".
And our topic started exactly out of this:
From: https://webapps.stackexchange.com/questions/135222/why-does-...
``` Official Statement
archive.today had this to say about the issue:
https://twitter.com/archiveis/status/1017902875949793285
2018-07-13T1545: yes, unlike other public DNS services, 1.1.1.1 does not support EDNS Client Subnet
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)