Joe Abley wrote: > Hi Paul, Warren, > > On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: > >> Greetings. Warren and I have done a major revision on this draft, narrowing >> the design >> goals, and presenting more concrete proposals for how the mechanism would >> work. We welcome >> more feedback, and hope to discuss it in the WG in Toronto. > > I think there is much in the language of this draft that could be tightened > up, but this is an idea for discussion so I'll avoid a pedantic line-by-line > dissection. But I can give you the full pedantry if you like :-) > > On the pros and cons, however (crudely pasted below), see below. > > TL;DR: there are way more cons than pros to this proposal. The pros listed > are weak; the cons listed are serious. I don't see a net advantage to the DNS > (or to perceived performance of the DNS for any client) here. This proposal, > if implemented, would represent non-trivial additional complexity with > minimal or no benefit. I am not in favour of it, if that's not obvious. > > ... >
i am +1 to joe's comments above and analysis elided. i consider joe's response to be at least as good as the "because" i owe DRC after my first short answer to the -00 version of this draft. however, i want to add two other countervailing points. first, this approach was tried in freebsd, when doug barton (then freebsd's BIND9 maintainer) made it the default. all hell broke loose due to changes in firewall config. debugging cost was maximized, and the debugging skills were minimized. this config was removed with prejudice. this experience, where freebsd users are actually among the smartest of all dns users, should serve as a warning sign to others: "abandon hope all ye who enter here." so, joe's recommendation that this draft be retitled and rekerned to be "draft-ietf-dnsop-slaving-root-on-resolvers-harmful" resonates very strongly with me. second, this approach asks millions or tens of millions of rdns servers to change their config in order to actually scale the capacity of the root. (so, high cost and low benefit, as joe said.) the reason i proposed a radically different solution in my ICANN ITI contribution (now described at http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) is to allow a few dozen to a few hundred self selected highly skilled and motivated network-level admins to scale the capacity of the root for everyone. it's a plain hierarchical solution allowing the operators of any loopback network on any host, or any LAN segment, or any campus, corporate, or ISP network to add root name service as a local capability; it also allows unlimited scale at the global BGP layer. it is patterned after the success of AS112. it is apolitical since existing rootops are also expected to participate. vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
