North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS Anycast as traffic optimizer?

  • From: Paul Vixie
  • Date: Wed Sep 01 16:23:09 2004

> > This isn't really 'anycast' so much as 'different A records depending on
> > server which was asked'

right.

> Well, there'd be one NS record returned for the zone in question.  That
> NS record would be an IP address that is anycasted from all the
> datacenters.  So end users (or their DNS servers) would all query the
> same IP address as the NS for that zone, but would end up at different
> datacenters depending on the whims of the anycasted BGP space.

that's generic dns anycast.  it's safe if your routing team is very strong.

> Once they reached a name server, then yes, it changes to 'different A 
> records depending on server which was asked'

that's incoherent dns.  when i first began castigating people in public
for this, i coined the term "stupid dns tricks" to describe this behaviour.
cisco now has products that will do this for you.  many web hosting companies
offer this incoherence as though it were some kind of feature.  akamai at
one time depended on it, speedera at one time did not, i don't know what's
happening currently, perhaps they've flipflopped.

dns is not a redirection service, and incoherence is bad.  when you make a
query you're asking for a mapping of <name,class,type,time> to an rrset.
offering back a different rrset based on criteria like source ip address,
bgp path length, ping rtt, or the phase of the moon, is a protocol violation,
and you shouldn't do it.  the only way to make this not be a protocol
violation is to use zero TTL's to prohibit caching/reuse, which is also bad
but for a different reason.

> > I suspect you'd really also introduce some major troubleshooting
> > headaches with this setup, not just for you, but for your users as
> > well.
>
> I don't doubt that. :-)

not only is it bad dns, it's bad web service.  the fact that a current
routing table gives a client's query to a particular anycasted DNS server
does not mean that the web services mirror co-located with that DNS server
is the one that would give you the best performance.  for one thing, the
client's dns forwarding/caching resolver might have a different position in
the connectivity graph than the web client.  for another thing, as-path
length doesn't tell you anything about current congestion or bandwidth --
BGP is not IGRP (and thank goodness!).

if you want a web client to get its web data from the best possible web
services host/mirror out of a distributed cluster, then you will have to
do something a hell of a lot smarter than incoherent dns.  there are open
source packages to help you do this.  they involve sending back an HTTP
redirect to clients who would be best served by some other member of the
distributed mirror cluster.
-- 
Paul Vixie