On Wed, Mar 20, 2013 at 11:55:41PM -0700, Constantine A. Murenin wrote:
On 20 March 2013 20:43, Andrew Sullivan <asullivan@dyn.com> wrote:
On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote:
Any plans to make DNS itself GeoDNS-friendly?
No. And I say this as someone working for a vendor that provides that service.
Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in particular, narrowly-scoped ways because of the loose coherence of the DNS. But as a matter of protocol, you can't really standardize it, because it's actually taking advantage of certain flexibilities in the DNS and its interaction with the routing system. Turning that operational fact into a protocol feature would be a bad idea.
You are coming to this from the perspective of the existing conventions, and the current way that GeoDNS is done through a Split-Horizon DNS hack.
But this is not what I want.
What I want is an ability to specify multiple A and AAAA records, and their locations, and make it possible for the web-browser to automatically select the best location based on the presumed location of the user. Browsers might have a couple of rules, e.g. that Europe and parts of Asia are currently not directly connected to Asia, but NA is, and such rules would influence browser's decision to choose a Quebec server for a user in Japan, since it'll likely be much closer than the one in Moscow.
Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin.
C.
peice of cake. add loc records to your rrset. /bill