Subject: Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Tue, 8 Jul 2014 10:28:32 -0400 (EDT)

On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:

>
> On Jul 8, 2014, at 7:40 AM, ? Roy Arends <[email-masked]> 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)?

> 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?

> 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?

> 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-masked]> 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-masked]
>>>> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt
>>>> Date: July 3, 2014 at 2:17:46 PM PDT
>>>> To: [email-masked]
>>>> Reply-To: [email-masked]
>>>>
>>>>
>>>> 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-masked]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

wfms

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 8 Jul 2014 12:51:59 -0400

On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor <[email-masked]> wrote:

> 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

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) 

> 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. 

> 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 

Olafur

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Jul 2014 12:11:48 -0700

William,

> 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?

The same way you can do so now: you validate the response yourself.

> How do I know if my ISP, etc. are running a local copy of the zone?  

Assuming they don't tell you, perhaps reduced latency, particularly in non-existent TLD cases.

> Can I call RSACC to complain about an outage?

Heh.

> BCP or informational (cautionary tales)?

Personally, I'd prefer informational until there is more publicly discussed deployment experience. There are undoubtedly quirks, tricks, and gotchas that will come out as people discuss what they've been doing more publicly. Perhaps a second iteration would fit into BCP.

> 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…

I'm not sure there can be a litmus test. What's being discussed is a technique anyone running a resolver can implement. It's not like an informational RFC or BCP on the topic would be creating a new capability. It would, as Ralf points out, be documenting an existing practice.

> 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 r…

Isn't this a variation of the "stale data" problem? In the worst case (where a resolution provider does not refresh), you can always point to a different resolution provider (or do it yourself). 

Regards,
-drc