Hi, On Mon, Jul 07, 2014 at 12:27:36PM -0700, David Conrad wrote: > > This draft attempts to document a way in which organizations can > choose to be the masters of their own fate when it comes to root > name service instead of relying on a set of 12 (or 11, depending on > your point of view) volunteers who upgrade or not, buy capacity or > not, deploy IPv6 or not, deploy anycast or not, etc., based on their > own internal rationales and justifications. Further, it is opt-in: > if you're perfectly happy with the existing system, no one is > forcing you, as a resolver operator, to slave the root zone. > > In my mind, this is a much more scalable, resilient, robust, and > even rational (from the perspective of the operation of critical > infrastructure) system that the current root service architecture.
Perhaps. I haven't myself made up my mind about this draft, partly because I think the situation is somewhat more complicated than you suggest above. It's true that the draft sort of allows an operator to be master of its own fate. But it does require -- and indeed, the coherence (however loose) of the DNS requires -- that one fall back to asking a "real" root server in the event one isn't up to date. Now, the problem is that the root server operations are organized according to the work needed. That is, many of the server operators seem to do a pretty good job of ensuring capacity for their actual loads. If the proposals in this draft are widely adopted, that will by definition change the profile of the traffic the root servers see, and that will mean that such potential traffic will not be considered in the planning by root server operators. This may not be a fatal flaw (probably it isn't), but it does worry me a little. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
