Paul Hoffman wrote:
> On Jul 9, 2014, at 10:45 AM, Paul Vixie <[email protected]> wrote:
>
>> << Criticisms of the current and historical Root Name Server System include
>> lack of resistance to DDoS attack, noting that even with the current wide
>> scale anycasting by every Root Name Server Operator, there are still only a
>> few hundred name servers in the world who can answer authoritatively for the
>> DNS root zone. We are also concerned that reachability of the Root Name
>> Server System is required even for purely local communication, since
>> otherwise local clients have no way to discover local services. In a world
>> sized distributed system like the Internet, critical services ought to be
>> extremely well distributed. >>
>
> Apologies, but that doesn't answer the question. In the face of lack of
> resistance to DDoS attacks, why is it better to have more *authoritative*
> root servers, as compared to validating recursive resolvers that have an
> up-to-date signed copy of the root? Similarly, for purely local
> communication, why is it better to have more *authoritative* root servers?
> The last sentence above makes good sense, but it too is not related to the
> number authoritative servers.
my comparison of the recursive vs authoritative approach to scaling root
name service was given in the attached e-mail. --vix
--- Begin Message ---
Joe Abley wrote:
> Hi Paul, Warren,
>
> On 4 July 2014 at 16:50:08, Paul Hoffman ([email protected]) 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
--- End Message ---
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
