On Wed, Jul 9, 2014 at 5:17 PM, Paul Vixie <[email protected]> wrote: > > > Paul Hoffman wrote: > > On Jul 9, 2014, at 1:47 PM, Paul Vixie <[email protected]> wrote: > > i don't know how to state the case more clearly. my answer is not "no" as > you surmise. the cost of the recursive solution is high and the benefit low. > the cost of the authoritative solution is low and the benefit high. > > a) You didn't actually calculate the cost of the recursive solution, you > simply pulled a large number of servers needed out of thin air. > > > about 20M IP addresses answer as "open recursive". most of these are low > quality CPE and other servers without skilled operators. i don't believe > that the rdns-root proposal is aimed at this set of users, but if it is, > we've got a NOTIFY problem as well as a debugging problem. > > to the best of my knowledge opendns and google dns already operate as > stealth secondaries for the root, not that they can answer AA for root data, > but that they don't need to ask a real root name server for any TLD > information, and they can generate NXDOMAIN without having to swim upstream > to get a purpose built NXDOMAIN for the root. if not, both should. if the > rdns-root proposal is aimed at this set of users, then that's great, it just > needs an applicability statement similar in concept to the one i suggested > up-thread. > > the middle of the market is where we lose cognitive traction. from my point > of view this set of operators is not skilled enough, and is not ever going > to be skilled enough, to both configure and operate and audit and debug a > stealth root slave.
True -- which is why this isn't a stealth root slave. "Configuring" this involves the operator turning on or off a single option -- "an example name for this option could be "transfer-and-validate-root [yes|no]"". If there is a failure (for example, the firewall admin decides that all DNS is UDP53 and so it is unable to transfer / retransfer), the solution fails back to legacy operation instead of returning SERVFAIL. > the freebsd experiment proved this to my satisfaction, > though i was previously informed on this topic by selling BIND support for a > decade or two. Yup. This is different to the FreeBSD experiment - failures result in messages in your log file, not inability to resolve. > but if we imagine that the skills gap could be closed with > good documentation and good software, the portion of the internet that can > be isolated from root name server reachability errors using this approach is > still very small -- and the roll out time for vendors like nominum, > microsoft, infoblox, ISC and others to inform their customers of this option > is measured in years. Yup. 'm fine with years. No one said we needed this tomorrow.... > and the total mass of held state in terms of software > revisions, version numbers, stored content has a multiplier in the tens of > thousands if not hundreds of thousands. > > there's no thin air here. > > based on the freebsd experiment with stealth root zone service, it can't > scale. (the freebsd community is Very Smart in the grand scheme of things.) This is different to the FreeBSD experiment -- both in terms of the complexity of enabling it, and the failure modes when things end poorly. > whereas based on the AS112 experience with unowned anycast, that approach > can scale -- Errrr... how many AS112 nodes are there? The 2012 survey discovered 72 (https://www.as112.net/2012-survey.html) -- there could be more, there could be less. Screwing up the dist-root solution (not quite sure how, it's designed to fail open, but I'm sure someone will manage) will affect those folk using this resolver. Screwing up an AS112 type solution screws up the folk using that resolver, *and* everyone who listens to the BGP route that will inevitably leak... > all we needed was DNSSEC so as to erase the temptation of local > root operators to amend the zone content in any way. Yup. In either solution we need DNSSEC to prevent folk from futzing with the zone contents. > > > > b) You didn't say why would need any fewer authoritative servers to get the > same benefit. > > > i said why fewer authoritative servers would have a greater benefit. > > ... > > If the goal is to get the correct answers for root queries closer to more > users, both proposals do that. > > > i'd like a small number of operators to be able to effect internet-wide > improvement, and specifically, i'd like a moderate number of edge network > operators to be able to offer root name service to their rdns-running > populations without them having to pirate the address space of an existing > root name server operator. > > i want to avoid having this burden shift to every single rdns operator who > wants the benefit of better access to root zone content, because (a) the > world's supply of rdns operators motivated and skilled enough to do that is > insignificant; (b) the complexity of configuration and monitoring and > debugging will scale with the affected population; and (c) the affected > population will be extremely small compared to the size of (for example) the > affected population of the AS112 system. > > so my goal is different -- both more broad and more narrow -- than the goal > you're describing. > > i'll stop here. feel free to have the last word. > > vixie > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
