Colleagues,
We have two drafts on the general topic of wider distribution for the root zone, and the draft agenda says we'll devote some time to both of them. The drafts discuss different methods, which may or may not be complementary, each having strengths and weaknesses to consider. It's no surprise that people have strong feelings about them. To me at least, one important question is what problem we're seeking to solve, or document existing solutions for? I'm not suggesting a full requirements analysis, and I think there is a fairly simple underlying problem statement to be had (at least one!), but I'd like to take a step back from the specifics for a moment: we have now one document that some people seem to want to call a BCP and others want labeled strictly cautionary, and another document that we still haven't really looked at. I'd like to see as much agreement as possible, or at least as much clarity as possible, on how we'll judge what work we want to commit to as the WG: do we want a BCP out of this? a document describing methods, without judgment? a suggestion for IANA or others, which of course they can take or not? All of those things? The kernel of a problem statement to me looks like: A few hundred root name servers behind a handful of IP addresses for a network of millions of servers used by billions of people constitutes a weakness; reliable access to the contents of the root zone should be more widely available. What people seem to want to discuss is how to scale the existing capacity within the constraints provided by the protocol, resource availability, and prevalent operational models. If that's a reasonable question, pros and cons of a given solution spin out from there. Please review both drafts, discussion welcome here and at IETF 90. best, Suzanne On Jul 8, 2014, at 8:03 AM, Olafur Gudmundsson <o...@ogud.com> 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. >> >> This specific document shouldn’t be a discussion point at all. Folks are >> doing this right now. What we need is a BCP that describes: IFF you are >> going to do it, here is how. >> >> I would also like to see some facilitation around this as well: a notify >> service of new versions, a zone distribution service (xfer service), >> possibly out of ICANN or VeriSign. >> >> Personally, I’m interested in what operators of large recursives have to say >> about this. >> >> Hope this helps. >> >> 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. > 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”. > > 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. > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
