Comment by ikeboy
7 years ago
Just like we consider it the kernel's fault if user applications break due to a change, I think it's the DNS resolver's fault if they're using a protocol that some popular sites don't support.
As soon as I realized they were causing this issue I just switched away. Other DNS providers don't have this issue.
It doesn’t really seem to be the resolvers “using a protocol that [archive.is] doesn’t support”; it seems that archive.is responds to queries from Cloudflare’s systems with an incorrect response. How is Cloudflare meant to work around that kind of behavior?
https://twitter.com/archiveis/status/999788186904576002 claims that cloudflare isn't supporting a protocol that would enable it to work with their servers.
That’s not an accurate read of archive.is’s behavior. EDNS is an optional feature.
archive.is has configured their nameservers to return invalid (127.0.0.0/8, from the looks of it) responses to Cloudflare requests because they’re protesting Cloudflare’s lack of EDNS, not because EDNS is somehow required to handle the requests.
For context: EDNS sends the origin IP address of the DNS client through the resolver. Cloudflare has it disabled because of the privacy implications of sending it along.
9 replies →
Archive.is does not appear to specify in detail what operational issues result from the missing client subnet EDNS data. We can speculate, though. Is it for data harvesting purposes, or for global load balancing concerns? Are users complaining due to some unknown side effect? Are localized in-country-firewall servers receiving traffic from out-country clients?
>"it seems that archive.is responds to queries from Cloudflare’s systems with an incorrect response."
What makes the response incorrect? I was under the impression that DNS implementations were under no "practical" obligation to return consistent queries to differing requester IP addresses (hence stuff like split-horizon DNS and EDNS: https://developers.google.com/speed/public-dns/docs/ecs )
Sorry, to clarify: when archive.is receives a DNS lookup from Cloudflare’s resolvers, they reply with an IP in the 127.0.0.0/8 range, so the origin client is unable to connect (since those IPs aren’t routable over the internet).
Thanks for the clarification on here + and the other posts, that makes perfect sense.
It is deliberately invalid.