North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: DNS Anycast as traffic optimizer?
> > 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