North American Network Operators Group

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

Re: Anycast 101

  • From: Paul Vixie
  • Date: Mon Dec 20 12:20:33 2004

> > but at that point, the only thing anycast would buy you is ddos
> > resistance and the ability to have more than 13 physical
> > servers... which is all the
> Is that true?  I'm failing to see how anycast helps expand a network's
> DDoS survivability.  At best a dumb attacker would attack the IP
> address of the server and it would be distributed to all the
> participating anycast nodes.

as it turns out, some attackers really are idiots, and it's considered
socially acceptable to pander to them even while also attempting to guard
against real attacks coming from experts.

> What prevents the attacker to hit just a few nodes from the anycast
> network to hurt percentages of the dns queries?

nothing, of course.  but we like that the percentage isn't always 100%
(as it would be in the non-anycast case.)

> Obviously health checking would prevent some of the problems but then
> the attacker can just shift from site to site as the health checks
> happen.

there are some million-bot drone armies out there.  with enough attackers
you can just attack everything the defenders might try to use -- no need
to shift from site to site in response to anything.

> With that thought process, an anycast network is only as it's most
> beefed up node.  As the smaller nodes fail the one left standing will
> be what prevents the attack, not anycast.

i admit that this appears true on the surface... but if you dig into it
you'll see that even a root name server with 10,000 direct 10GigE
connections (one for every autonomous system in the internet) would
still be vulnerable to congestion based attacks, since a congestion
based attack is against OPN's (other people's networks) where even
infinite point-source provisioning cannot help you.

> For an example, let's look at f.root:
> is

that's .org not .net. is just a web server.  you want

> If an attacker wanted to be violent and have complete disregard for
> the anycast design, he/she would hit either each node independently
> and at the same time hit the upstream routes of both nodes.  That
> would isolate each node from the anycast primary "VIP" of
> and introduce problems into the design.  Then, as those
> sites were failed out, he/she would shift the attack to the current
> operating sites.

an effective attack doesn't need to be nearly that subtle.

> Eventually this cat and mouse would cause such a problem that the
> saving grace of the anycast design would be the strongest node in the
> cluster and the operators would have to fail each site in and out as
> the attack shifted around.

i suppose that you could do it that way, if you wanted to be more artful.

> If they were really violent they would include a randomized valid
> query attack in the mix.

you mean they aren't?

> Can you explain to me how anycast would prevent this?

i knew, at the time i wrote the words "ddos resistant" in this thread,
that at least one person would think i meant "ddos proof".  in wristwatches,
"water resistant" means you can shower or bathe while wearing the device,
but only "water proof" means you can scuba dive with it.  anycast makes a
dns service more ddos resistant.  nothing can make a dns service ddos proof.