[dns-operations] Too Open (Was: OpenDNS makes your Internet work better
jabley at ca.afilias.info
Thu Jul 20 18:43:54 UTC 2006
On 15-Jul-2006, at 23:04, Rodney Joffe wrote:
> Goody. Operational stuff...
Big thread latency with this one, sorry :-)
> On Jul 15, 2006, at 6:12 PM, Joe Abley wrote:
>> To pick a message more or less at random to reply to, you're
>> digging in far too deeply into a single service without enough
>> information about how it is provisioned to be able to draw any
>> useful conclusions.
>> If there's a point here about anycast-only NS sets, surely it's
>> far more general:
>> - if there's some systematic failure mode (as-yet unknown,
>> perhaps) which afflicts nameservers which are distributed using
>> anycast, and
>> - if nameservers which are not distributed using anycast are not
>> vulnerable to that same failure mode, then
>> - an NS set which includes both nameservers which are distributed
>> using anycast and those which are not would provide greater
>> reliability than an NS set which was anycast-only.
> In a mixed implementation there's something else to consider though:
> I think there are around 40 geographic instances of the f-root? If
> f was the only anycast root server, and the 40 anycast instances
> were topologically proportionally dispersed (sorry, I can't think
> of a better way of describing it but hopefully you know what I
> mean) in relation to the other 12 root servers, f would be handling
> 40/52nds of global queries (let's assume all of the recursive
> servers are running BIND and so behave properly by mostly querying
> the closest instance to them). The remaining unicast root servers
> would have to be rather well provisioned - in an edge case where
> the announcement for f is withdrawn, one of the unicast instances
> might have to be ready to instantly handle 41/52nds of global queries.
ISC provisions each of its global nodes of F with sufficient external
connectivity and processing iron to be able to handle a global load
of root server traffic on its own. I presume other root server
operators do likewise.
Your general point (that a non-anycast server address in an NS set of
anycast servers probably needs to be attached to lots of iron) is
well-made, but I think that's an implementation detail rather than a
reason not to do it.
A non-anycast server (from the perspective of the global, BGP-
speaking Internet routing system) doesn't need to be just a single
box: you could make a cluster of servers using any one of several
approaches. Such a cluster might well still be able to provide the
anycast/non-anycast diversity that I initially described, regardless
of the fact that it's not a single host.
This being the case, there's no obvious, practical limit to the
number of queries a single, non-Internet-anycast nameserver could
answer (beyond the fact that scaling to pathological extents might
challenge the availability of colo, or cooling, or power, or fibre).
More information about the dns-operations