On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor <wma...@ottix.net> wrote:
> > On Tue, 8 Jul 2014, Olafur Gudmundsson wrote: > >> >> On Jul 8, 2014, at 7:40 AM, ? Roy Arends <r...@dnss.ec> wrote: >> >>> Hiya, >>> >>> I really like this idea. Many ISPs already do this, (including some high >>> profile public recursives, like Google and OpenDNS), because it simply >>> makes sense: It reduces latency for the end user, reduces outbound traffic >>> overhead, eliminates an attack vector. > > (possibly some more questions or variations for the draft to consider) > > How can I as a user ensure that what Google does in the name of moi, can be > verified to be an untampered copy of the root zone? > > How do I as a user know if there's a stale copy of the root zone being > slaved^H^H^H^H^H^H^H supplied by my ISP? (is not being able to reach > wyle.e.coyote.acme enough to give me that hint?) > > How do I know if my ISP, etc. are running a local copy of the zone? Can I > call RSACC to complain about an outage? > > (In other words, what are the mechanisms for someone to figure this out > before calling the helpdesk, or, should the draft say to call if you suspect > something is wrong? They'd probably do it anyways...maybe. Yes, I'm > rhetorical here, DNSSEC etc for mitigation, etc.) > >>> Roy >> >> Roy >> you hit the nail on the head, this is a no brainer as a BCP. >> >> The contents of this draft may or may not be right at this point but we need >> a BCP that explains how to do this and the pitfalls to be aware off. > > BCP or informational (cautionary tales)? too early to tell. The former if possible, but that may need protocol work a better zone transfer mechanism, a zone consistency check built into the system (something like SIG(AXFR) from RFC2065 but better) > >> For an DNS resolution provider that elects to there are two ways to do it, >> forward zone >> local authoritative zone. >> both should be allowed, this document seems ?bind? specific that it assumes >> that the recursive resolver can be both authoritative and recursive which is >> not a requirement. >> >> There is no need that every recursive resolver at a Resolution Provider have >> a copy of the root zone only that the resolvers know the ?local root >> servers?. > > I see mentions of 'Resolution Provider'. Is this a BCP for only them, or can > anyone join the local auth zone party at their own risk/pleasure, at which > point it's informational or still BCP? What is the litmus test? > Litmus test, why? Root zone is not special from a serving point of view, only from fetching it and maintaining it. If I’m a Resolution Provider who can I hurt by messing up? Only my customers. >> In my mind this is not that far off from Anycast root servers i.e. >> additional server placed closer to the query generators. >> The big difference is in management and control. > > There were good intentions behind the Cymru bogon list. Every once in a > while, we start to see complaints of former bogons being unreachable because > they're no longer bogons. Is there a similar risk for that here and should > it be identified? All risks and benefits we can think of should be documented. A guide to monitoring the service should be provided > >> The root server operators believe (correctly) that they provide valuable >> service and are critical to the operation of the internet, They also believe >> that having >> close control over all root servers is essential. >> A number of people over the years have said that the current model is not >> the only possible way to provide the same service just as well, >> further diversification of root server services is enabled by DNSSEC. >> >> The open question is does the promotion of this type of service create any >> NEW attacks agains the CONTENT of the root zone, >> i.e. would this have made the it possible/easier for Turkey to restrict >> access to Google and Twitter? >> >> The technical question that needs to be answered what is the safest way to >> distribute the root zone and locally validate it before making it available >> on the >> ?local root servers?. In my mind the answer Notify and incremental XFR with >> stronger protections. >> >> I think the answer is NO thus I support the promotion of a BCP on ?locally >> provided root servers?. >> >> Olafur >> >> >>> >>>> On 04 Jul 2014, at 21:50, 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. >>>> >>>> --Paul Hoffman >>>> >>>> Begin forwarded message: >>>> >>>>> From: internet-dra...@ietf.org >>>>> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt >>>>> Date: July 3, 2014 at 2:17:46 PM PDT >>>>> To: i-d-annou...@ietf.org >>>>> Reply-To: internet-dra...@ietf.org >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : Securely Distributing the DNS Root >>>>> Authors : Warren Kumari >>>>> Paul Hoffman >>>>> Filename : draft-wkumari-dnsop-dist-root-01.txt >>>>> Pages : 9 >>>>> Date : 2014-07-03 >>>>> >>>>> Abstract: >>>>> This document recommends that recursive DNS resolvers get copies of >>>>> the root zone, validate it using DNSSEC, populate their caches with >>>>> the information, and also give negative responses from the validated >>>>> zone. >>>>> >>>>> [[ Note: This document is largely a discussion starting point. ]] >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > wfms Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
