On 2013-03-21, at 02:55, Constantine A. Murenin <[email protected]> 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
