zlacker

[parent] [thread] 13 comments
1. miyuru+(OP)[view] [source] 2019-10-04 06:42:20
They are taking about Geo load balancing via DNS.[1]

Just try one of the akamai endpoints to test it. (E.g media.steampowered.com)

For me 1.1.1.1 serves akamai singapore IPs, while 8.8.8.8 serves IPs of my ISPs akamai cache in Sri Lanka.

If your ISP has a bad route to 1.1.1.1, this just gets worse.

[1] https://en.wikipedia.org/wiki/GeoDNS

replies(2): >>profmo+w >>virapt+d1
2. profmo+w[view] [source] 2019-10-04 06:49:36
>>miyuru+(OP)
Blocking a user because the site might load more slowly for them doesn't make any sense to me. If the user is choosing to use a DNS server that returns sub-optimal CDN IPs, isn't that their problem?
replies(2): >>oarsin+Kc >>wander+kJ
3. virapt+d1[view] [source] 2019-10-04 07:02:35
>>miyuru+(OP)
Yeah, but... why does it matter? They're not some massive retailer where every ms potentially translates to some proportion of lost sales that add up to a significant number. They're serving archived pages.

In what case would some extra delay be worse than no access at all?

replies(2): >>michae+z1 >>miyuru+Y1
◧◩
4. michae+z1[view] [source] [discussion] 2019-10-04 07:09:03
>>virapt+d1
> Yeah, but... why does it matter?

Seems pretty anti-competitive if Cloudflare's DNS stops Akamai's local caching at your ISP from working, no?

replies(1): >>virapt+9F1
◧◩
5. miyuru+Y1[view] [source] [discussion] 2019-10-04 07:12:59
>>virapt+d1
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.

replies(2): >>virapt+u2 >>profmo+F2
◧◩◪
6. virapt+u2[view] [source] [discussion] 2019-10-04 07:23:30
>>miyuru+Y1
That was my original question - if it's not about slow requests, what's the reason?
◧◩◪
7. profmo+F2[view] [source] [discussion] 2019-10-04 07:25:12
>>miyuru+Y1
> 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.

replies(1): >>roblab+T8
◧◩◪◨
8. roblab+T8[view] [source] [discussion] 2019-10-04 08:49:40
>>profmo+F2
> 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.

replies(2): >>jlokie+to >>luncha+5z
◧◩
9. oarsin+Kc[view] [source] [discussion] 2019-10-04 09:49:06
>>profmo+w
> If the user is choosing to use a DNS server that returns sub-optimal CDN IPs

How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand?

replies(1): >>dwild+qJ
◧◩◪◨⬒
10. jlokie+to[view] [source] [discussion] 2019-10-04 12:25:05
>>roblab+T8
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!
◧◩◪◨⬒
11. luncha+5z[view] [source] [discussion] 2019-10-04 13:42:59
>>roblab+T8
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?
◧◩
12. wander+kJ[view] [source] [discussion] 2019-10-04 14:42:03
>>profmo+w
This kind of blows my mind about this, and I'm surprised that everyone seems to be focused on conspiracy theories about Cloudflare instead of the apparent situation that archive.is is intentionally breaking fundamental behavior of the internet because they don't they aren't getting information they want from Cloudflare.

Internet protocols were designed to be redundant and resilient, so that things still work when things break and traffic takes other paths. When people do shit like this, we get a less reliable, less functional internet. Demanding to know the exact subnet a request originated from, and returning incorrect results when that information is not given, seems to me a thoroughly hostile behavior on the part of archive.is.

◧◩◪
13. dwild+qJ[view] [source] [discussion] 2019-10-04 14:42:36
>>oarsin+Kc
> How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand?

Not sending anything at all doesn't solve any of this. If a message was shown explaining the situation, sure, but archive.is solution doesn't answer your question at all.

◧◩◪
14. virapt+9F1[view] [source] [discussion] 2019-10-04 20:51:34
>>michae+z1
Akamai caching wouldn't stop working. Depending on how it works, you'd either hit the cache/edge in a different country, or a local one with a matching bgp route anyway. There's nothing anti competitive here.
[go to top]