zlacker

In the post the archive.is says that it caused "many troubles".

We really dont know the site works in the backend. So I guess the admin did not want to spend time to fix issues cloudflare created.

>>miyuru+(OP)
That was my original question - if it's not about slow requests, what's the reason?

>>miyuru+(OP)
> issues cloudflare created.

But that's the thing, Cloudflare didn't really create any issues. If I live in the US and I decide to use some random public DNS server in Australia, it will be an unpleasant setup, but it's a perfectly valid one.

There's no rule that your DNS server must be on the same network as you, or send your subenet if it isn't. When that's the case it allows for some nice performance optimizations. (I.E. sending you to a closer cache.) But it's just that - an optimization. If your service is completely unreachable without performance optimizations, you've created a very fragile service.

>>profmo+H
> There's no rule that your DNS server must be on the same network as you, or send your subenet if it isn't.

It's the default configuration. 99% of internet users follow this configuration (at least, until web browsers start shipping DoH as a default). It's honestly a fairly reasonable assumption to make.

>>roblab+V6
It's an even more reasonable assumption for CDN latency-minimisation geo-IP/DNS purposes. Even if it's not on the same network, your DNS server is usually on the same continent!

>>roblab+V6
Can't you argue the inverse as well? Cloudflare isn't sending EDNS Client Subnet to any other authoritative name servers, is anyone else having problems? Or are 99% of people working just fine without this optional EDNS information? So isn't it archive.is who is the 1% who isn't following the standard configuration? Which is to still resolve correctly even without the option EDNS information? Sure, it might not be the best possible answer for a client, but you can still return an answer?