Why are there no GeoDNS solutions anywhere in sight?

Thu Mar 21 12:28:49 UTC 2013

On 2013-03-21, at 02:55, Constantine A. Murenin <mureninc at gmail.com> wrote:

> 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.

I understand that you want a packaged solution in your authoritative DNS software, but with a little work you can get close without any knowledge of global topology or address distribution (i.e. no need for a geo-IP database). You need some unused address space to burn on anycast advertisements, though.

Here's an approach using anycast DNS:

$ORIGIN example.com.
...
www CNAME www.geo.example.com.
...
; number any1 and any2 using addresses that
; are anycast between our service locations
any1 A ...
     AAAA ....
any2 A ...
     AAAA ...
...
geo NS any1
    NS any2

; serve this version of geo.example.com
; in Asia on any1/any2, make www
; something sensible for Asian clients
$ORIGIN geo.example.com.
...
www A ....
    AAAA ...

; serve this version of geo.example.com
; in Europe on any1/any2, make www
; something sensible for European clients
$ORIGIN geo.example.com.
...0
www A ....
    AAAA ....

; etc

No reason that all the variants of the geo.example.com. zone can't be signed with the same keypair, and a suitable DS RRSet installed in example.com; this doesn't break DNSSEC.

Two nameservers in the example above; this gives no site diversity for the geo.example.com zone but perhaps it's useful to incorporate server diversity within the site (if not, use one).

You need to be able to advertise an anycast route to the world from each location, and you need spare numbers to be able to make those advertisements. For v4 that means an unpolluted /24; for v6 that probably means an unpolluted /56 or /48. Anycast of a single service is not a friend of efficient address utilisation.

As with any other use of anycast, "European client" means "client whose path to any1/any2 lands in the European service location" and doesn't actually say anything about the location of the user. But if the selected exits along the path for some client land in Europe for resolving names in geo.example.com, maybe that's a good way to send the HTTP traffic.

Another approach is to anycast the HTTP server serving www.example.com, and have that server return a 3xx redirect to www.asia.example.com or www.europe.example.com, which preserves the ability for the user of making a manual choice for one or the other at the expense of making your web people all flappy about the longer URL and the potential for particular content to be bookmarked with no future potential for geo-distribution. People get animated when you suggest you anycast a TCP service, but there is no shortage of examples of this working (and the redirect transaction is brief, which is generally nerve-settling).

Lots of ways to skin this cat.

Joe