Andrew, On Jul 7, 2014, at 12:44 PM, Andrew Sullivan <[email protected]> wrote: > 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.
If you're defining a "real" root server to include the "zone delivery servers", I'd agree, however I feel the "zone delivery servers" have sufficiently different performance requirements as to put them in a different class than the name servers that respond to non-XFR queries. > Now, the problem is that the root server operations are organized > according to the work needed.[...] 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. Joe has already indicated that the normal query flow is essentially inconsequential in relation to capacity planning for the root server operators since they have to build based on DDoS/flash crowd loads, not on steady state. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
