% 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf