[dns-operations] Too Open (Was: OpenDNS makes your Internet work better

[Joe Abley]

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


Joe