Anycast 101

> ... 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.

  well, thats practically true, but not theoretically true.
  the DNS is running just fine thank you. ddos attacks against
  OPNs is not an attack on the DNS per se, its on the clients in
  the OPN. trying to ensure that every client has reachability
  to a given server set - FROM the SERVER side - is ultimately
  an exercise in futility.

i'm glad you said "every client" rather than "most clients". in october
2002 there was a ddos against all 13 root server addresses, and several
of them were unicast (that's as in "not anycasted") behind DS3 links, and
these "failed" in that they became unreachable by "most clients". of
course, as you also point out, it's the reachability of the "server set"
and not any particular server that matters. "long live diversity!"

                         Servers/operators can only take
reasonable and prudent steps to try and ensure the service is
generally available -- micro managing DNS availablity to a
specific server set is the way to madness.

i'm really not sure i agree. about the madness, that is. i've heard of
plans to do inside-AS anycasting of dns content, such that interested
network operators could ddos-proof their view of a given server or
server-set as long as the ddos did not emanate from within that AS, and
i'm not sure that this is a bad business model given that BCP38 is still
"madness" to many of you reading this.

Anycast is a way to make the service generally available to as
many end-systems as want/need the service. So is multi-homing.
... long term, what is important is the view that there is a
common namespace, not that there are special servers.

sorry, that's just too deep for me today.

  little, in practice, can make a DNS service ddos proof.
  it can be done, but the side effects are worse than the cure.

being "worse" begs the question "worse for whom?", and for many, the
things that can be done to ddos-proof a service are not worse than the
ddos problem. so i'll consider that you mean "worse for you" and i'll
wait to hear why that's true in your situation. (it's not true in mine.)

> Anycast is a way to make the service generally available to as
> many end-systems as want/need the service. So is multi-homing.
> ... long term, what is important is the view that there is a
> common namespace, not that there are special servers.

sorry, that's just too deep for me today.

  more eggnog. if the client can ensure that the data asked for
  came from an authentic source and arrived intact, does it really
  matter the path or intermediate nodes taken to get the data?

> little, in practice, can make a DNS service ddos proof.
> it can be done, but the side effects are worse than the cure.

being "worse" begs the question "worse for whom?", and for many, the
things that can be done to ddos-proof a service are not worse than the
ddos problem. so i'll consider that you mean "worse for you" and i'll
wait to hear why that's true in your situation. (it's not true in mine.)

  ddos proof DNS service can be had in one way - don't run
  DNS. - moving up from there, air-gaps, running the service
  on non-networked interfaces, e.g. ::1, augmenting the DNS service
  with "bodyguard" support services, e.g. ACLs, firewalls, router
  filters ad.nasusa, use of strong crypto (signed data, transaction
  signatures) et.al. ... everyone invites attacks by disaffected or
  bored, the students trying to pass Dr. JBs classes, the vaguely
  curious, the helpful, the application developers who optimise locally
  at the expense of others, and the down-right hostile. if you run
  DNS - they WILL come.

  ddos resistant is a moving target. the techniques you use are based
  on the deployment choices you make. they will not n'cssly be the
  same as i, or anyone else, might use.

  as usual, YMMV,

--bill