Paul, On Jul 6, 2014, at 9:14 PM, Paul Vixie <[email protected]> wrote: > there are far more errors encountered below .com or .de than by their > siblings in the root. any argument in favour of wide scale slaving of the > root zone begs the question, why not every tld and every pseudo-tld (such as > no-ip.org)? the root isn't special in regards to a goal of preventing junk > queries.
The operators of the authorities for .com and .de and others have a natural incentive to augment their systems to deal with issues such as errors or DDoS or whatever. As we have seen multiple times in the past, most individual root operators simply do not have this incentive. > that's why query minimization is the preferred solution to this problem. This isn't either/or. > right now, root name servers are part of an explicit, hand-maintained NOTIFY > tree. thus, all internet actions depending on root zone content have > up-to-the-minute data if not up-to-the-second data in many cases. we should > treat this as an invariant, I'm a bit (ok, a lot) skeptical of this claim, particularly given arguments made by some root server operators during the ICANN root scaling discussions about having instances at the end of long, thin, and fragile pipes and thus the size of the root zone must be limited. However, ignoring that, one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you (cue Vijay Gill's talk on the cost of customer calls in relation to the profit that customer will bring over their lifetime of being a customer). As a customer, you can also always choose to run your own resolver (which is, of course, the right answer for other reasons). Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
