On 17-mei-04, at 17:41, Bill Manning wrote:
% But as long as we're dissing anycast root DNS servers: how many of
the
% root servers are being anycast now or in the future, and how many
% won't?
http://www.rssac.org/
check the 17th & 18th meeting minutes.
Result:
Unicast: A, E, H, L
Anycast: B, C, D, F, G, I, J, K, M (now or planned)
The thing that worries me is that apparently, there is no policy about
this whatsoever, the root operators each get to decide what they want
to do. The fact that .org is run using only two anycast addresses also
indicates that apparently the ICANN doesn't feel the need to throw
their weight around in this area.
Now obviously anycasting is a very useful mechanism to reduce latency
and increase capacity and robustness. However, these properties are
best served by careful design rather than organic growth. If we
consider the number of actual servers/server clusters and the number of
root IP addresses as given, there are still many ways to skin this cat.
One would be using 12 unicast servers and anycast just one address.
However, this only creates partial benefits, especially with regard to
robustness in the presence of denial of service attacks. But at the
other extreme, 13 unicast addresses, there are problems as well. For
instance, if a network enjoys good local/regional connectivity, it may
very well see the anycast instances for all roots behind some common
infrastructure. When this piece of infrastructure fails, it may take
considerable time before BGP converges and mean root reachability
reaches acceptable levels again.
It seems to me that any design that makes the root addresses seem as
distributed around the net as possible would be optimal, as in this
case the changes of an outage triggering rerouting of a large number of
root addresses is as small as possible. In order to do this, the number
of root addresses that are available within a geographic region (where
"region" < RIR region) should be limited.
(Just having the roots close is of little value: good recursive servers
hone in to the one with the lowest RTT anyway, so having one close by
is enough. However, when this one fails it's important that after the
timeout, the next root address that the recursive server tries is
highly likely to be reachable, in order to avoid stacking timeout upon
timeout. A couple 100 ms extra round trip delay doesn't mean much in
cases where the recursive server suffers a timeout anyway.)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf