On Tue, 21 Dec 2004, Iljitsch van Beijnum wrote: > > On 20-dec-04, at 17:32, Paul Vixie wrote: > > >>> 1. There should always be non-anycast alternatives > > >> I believe there is a strong consensus about that. And therefore a > >> strong agreement that ".org" is seriously wrong. > > > i believe that icann/afilias/ultradns would be very receptive to input > > from the ietf-dnsop wg on this topic. but it's not cut and dried -- if > > you have two widely anycast'd servers plus one non-anycast server "just > > in case something bad happens to anycast" you're doing two questionable > > things: (1) treating anycast as new/unstable/experimental which it's > > not, > > and (2) limiting your domain's availability to the strength of that one > > non-anycast server. > > ??? How are things worse with two anycasted addresses and one > non-anycasted address vs two anycasted addresses?
There seem to have been a few (and paul/joe/isc/rodney have FAR more experience with this than I) different and 'interesting' failure modes for anycast DNS services to date: 1) complete dns outage (software caused problem on all devices) 2) route damping due to flaps (maybe software, maybe hardware, maybe link, maybe DoS) 3) inconsistency of dns data (perhaps not a problem at all) The trouble as I've seen it has always related to 'view' more than anything else. So, aside from a complete software basd outage, normally .ORG (to use as an example) is up for larger portions of the Internet. Often folks will report '.ORG is Down!!!' when they really mean: "The pod of .ORG tld1 nearest to my location is down." So, for most DNS applications you really don't care if the /32 is anycasted in BGP or is unicasted in BGP, you just care about reachability. Anycast provides geographic diversity, robustness through that diversity, resilience to single-network-problems (uunet can die while the anycast pod on qwest is still 'ok') and 'quick response' (close response really) to the end-users of the service. Making a mix of uni/anycast seems to not really solve the problems above, it may solve other problems, but I suppose that you'd have to scope and risk-analyze them to see how relevant they are to the entire userbase. I'd venture that the original 'out of sequence packets' problem falls down fairly low on the totem of risk/reward, but that's a guess. > Anycast can increase the number of physical servers, but this is also > possible with more traditional clustering techniques or anycasting that > stays outside BGP. look at what anycast in today BGP can get you in terms of geographic diversity, closeness to the eyeball and stability of the overall 'service'. Then think about how to provision Paul's 10,000 10gb link server farm... There is more than just 'clustering' to be done for DNS services at the TLD/Root level (and the roots do all manner of oddball versions of these things depending on their individual fancy as bill and paul point out regularly) > > What I find surprising is that every IP address gets to query the > roots, despite the fact that most addresses don't have any need to do > this or know how to do it properly. It would make perfect sense to me > that people would have to sign up for "root service" before they get to > talk to the root servers. This way, all unknown addresses can be > filtered out. (Or more practical, rate limited.) Obviously something > like this would face deployment issues, but if we're serious about DDoS > issues these kinds of options are the ones we should consider. > also keep in mind that not only the dns 'server' is under attack, as paul pointed out, and others before him, link filler attacks are also effective. So, block my /32 cable modem from quering a-m.root-servers.net, but my packet still got to the upstream link(s) for a-m.root-servers.net... the DoS was still effective in many cases :( Also, the IAB might consider 'root query service' some form of 'end to end filtering' and might not feel warm and fuzzy about that form of extortion. > Another way to approach this would be for larger ISPs to connect to one > or more roots using private peering. This gives those operators both > the means and an incentive to keep such links free of clutter. This also exists today... for many larger networks. Anycast extends that capability and provides some more close 'partnership' with the dns-service-provider and network-operator, or could in theory do that. I'm leary of the 'anycast is bad' or 'anycast is good' discussions in general. There are good applications of anycast, there are certainly horrid ones (true pplb of all links inside a IGP with IGP anycast of a TCP service could lead to some 'interesting' results) doing the risk analysis and proper engineering will help get away from the 'bad' and to more of the 'good' I hope. On the PPLB front though, that is almost always done via the IGP since BGP mostly holds a single next-hop (unless you non-default install it and deal with the multipath 'features') So, unless you have 2 instances inside your AS for an Anycast destination you really only go 1 path to the destination. Or more clearly, if you are on UUNET's network and want to get to 'tld1.ultradns.net' you have to go through Verio (on the east coast atleast) to get there and pplb really doesn't seem to matter for 'anycast', atleast no more than getting to 'www.sun.com' which is 'unicast' by sun... -Chris
