Nice investigations, this one and the others you shared before.
Some complementary thoughts on this one:
- A few years back, someone did a study on “DNS watersheds”. I.e., showing which geographic areas are being served from which locations of some of the big anycast providers. Both the slides as well as a recording of the talk are available online. Would be interesting to see whether there is any follow-up investigation, or updates since then.
- For some anycast providers, the watersheds are not so relevant, because they pass the user’s IP address to the authoritative geoservers, i.e., those should detect rather well the location of the client (mostly limited only by MaxMind data quality). But others, e.g., Quad9 and Cloudflare, in their default services, do not support so-called DNS ECS for transferring the client’s IP address. So here, the pool has no other choice but to use the IP address of the recursor that is querying it as approximation for the client location. Given the watersheds, the recursor might be in another country, so give inaccurate client location. But since many of the big services are run by companies based in the USA, experience shows that many of the addresses they use are geo-located to the USA, even if they are actually being used elsewhere (MaxMind data quality).
- Caching plays a big role. It needs to happen ECS-aware. That would be interesting to investigate, whether the big services are. I guess Google likely is, but with, e.g., Cloudflare not collecting nor forwarding ECS information, how are they supposed to do caching ECS-aware? And what about other, ISP-run recursors, do they do ECS-aware caching?
- Ask is running the so-called “mapper”, which was subject here recently. It’s purpose is to precisely collect data about how the geo-location of clients works. Not sure Ask himself has already analyzed that data, but maybe you can get access to it for your investigations.