On Jul 8, 2014, at 7:40 AM, đź”’ Roy Arends <[email protected]> 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 <[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.
>>
>> --Paul Hoffman
>>
>> Begin forwarded message:
>>
>>> From: [email protected]
>>> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt
>>> Date: July 3, 2014 at 2:17:46 PM PDT
>>> To: [email protected]
>>> Reply-To: [email protected]
>>>
>>>
>>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
