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