3 ms·

> What you mean by distance ? I believe the person you're responding to meant miles. Physical distance. > It's not so easy as it sounds. Their point was not

> What you mean by distance ? I believe the person you're responding to meant miles. Physical distance. > It's not so easy as it sounds. Their point was not that it isn't easy (and I think they realize that) but that the article seems to imply that out-of-country is suboptimal, and they're questioning that assumption. (Hence the SF vs. Toronto from upstate NY example.) DNS resolvers are already computing some form of location to determine whether a query is in or out of country, and presumably the resolver knows its own location, so it effectively is already solving (to a degree) the problem of computing distance; the poster's point was just that "in country" is not necessarily "closest", "fastest" or "best" (or even that those three are the same).

lossolo 8y ago
> DNS resolvers are already computing some form of location to determine whether a query is in or out of country Most of it is based on publicly available IANA databases (RIPE, ARIN etc) which are not always accurate, as IPs are traded and moved between AS's all the time + dynamic IPs that are given to users from example both coasts of USA. > the poster's point was just that "in country" is not necessarily "closest", "fastest" or "best" (or even that those three are the same). And I wrote it's not easy to solve because you do not get accurate GPS positions to most of IP clasess, which means it's a lot easier to point to the same country and that's why almost every provider does that. Some use geo coordinates of IPs but only for certain classes that have accurate positioning and are inside the same country. PS. I am building globally distributed anycast GEO-DNS service/system at the moment.