Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

From: [email-masked]
Date: Tue, 15 Nov 2016 18:41:29 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Aggressive use of NSEC/NSEC3
        Authors         : Kazunori Fujiwara
                          Akira Kato
                          Warren Kumari
	Filename        : draft-ietf-dnsop-nsec-aggressiveuse-06.txt
	Pages           : 16
	Date            : 2016-11-15

Abstract:
   The DNS relies upon caching to scale; however, the cache lookup
   generally requires an exact match.  This document specifies the use
   of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers
   to generate negative answers within a range, and positive answers
   from wildcards.  This increases performance / decreases latency,
   decreases resource utilization on both authoritative and recursive
   servers, and also increases privacy.  It may also help increase
   resilience to certain DoS attacks in some circumstances.

   This document updates RFC4035 by allowing validating resolvers to
   generate negative based upon NSEC/NSEC3 records (and positive answers
   in the presence of wildcards).

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.This document is being
   collaborated on in Github at: https://github.com/wkumari/draft-ietf-
   dnsop-nsec-aggressiveuse.  The most recent version of the document,
   open issues, etc should all be available here.  The authors
   (gratefully) accept pull requests.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 16 Nov 2016 07:09:17 +0100 (CET)

Hi,

I read the document and I believe that the document goes to far
to recommend the vendors how to implement the knobs in their
software here:

   It is recommended that resolvers that implement Aggressive Negative
   Caching provide a configuration switch to disable the feature.
   Separate configuration switches may be implemented for the aggressive
   use of NSEC, NSEC3 and wildcard records, and it is recommended to
   enable aggressive negative caching by default.

I would recommend (not strongly) dropping this paragraph.  And if not
dropping provide a rationale for such recommendation.  (And I am sorry
if this has been rehashed and the rational can be found in the archive.
In that case, the msg-id would be appreciated.)

~~~
(nit) missing whitespace in Section 5.4. third paragraph:
s/RFC2308]also/RFC2308] also/

~~~
Section 5.4, fourth paragraph, first line: should or SHOULD to match
RECOMMENDED in second paragraph same section?
~~~
(nit) Section 6: s/authorative/authoritative/

~~~
I think a small text to recommend signing domains because of increased
protection would be nice in Section 6.  I am happy to provide text if 
the authors poke me when I am not jet-lagged.

~~~
(nit) Appendix B: s/NXDOMAN/NXDOMAIN/

~~~
It's unclear what Appendix B means by "discard it".  Does it mean "proceed as normal"
or "delete it from cache and proceed as normal"?  Could you please clarify the text
in the draft?

Also 'ENT' is a abbreviation neither defined anywhere else nor explained in this
document.

~~~
I would also welcome if Sections 5.1, 5.2 and 5.3 had specific examples, either
in the respective sections or in separate Section or as a part of Appendix B.

~~~
Otherwise the rest of the document is in good shape (if not I blame lack of sleep)
and I would be happy to review next revision.  In case I am silent bug me until
I do the review.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: [email-masked]
> To: [email-masked]
> Cc: "dnsop" <[email-masked]>
> Sent: Wednesday, 16 November, 2016 03:41:29
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Nov 2016 15:15:50 +0900

I have some small concerns on 5.4.  Consideration on TTL

I think the language needs to be clearer that if you are in the
position of reading the NSEC3 state and the TTL you receive is value
<x> that the TTL you assert cannot be longer than <x> and needs very
probably to be <x> minus some period of time.

the 'maximum 3 hours' thing I worry implies you can span over the
NSEC3 projected gap by any time you like. If you get told "for the
next 20 seconds nothing exists betwewn a and b" then I don't think
this TTL can be longer than 20 seconds.

-G

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 16 Nov 2016 09:51:43 +0100

Hi Ondřej,

> In that case, the msg-id would be appreciated.)

I am in favor of dropping the paragraph, though it is already better 
than it was before (with RFC 2119 keywords).

See these messages for a previous discussion on this topic:

https://www.ietf.org/mail-archive/web/dnsop/current/msg18252.html
https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html
https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html

Best regards,
   Matthijs

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 18:10:07 +0900

> On Nov 16, 2016, at 15:09, Ondřej Surý <[email-masked]> wrote:
> 
> Hi,
> 
> I would recommend (not strongly) dropping this paragraph.

I agree. It should not be part of the standard. Recommendations like these can quickly be obsoleted by operational experience.

Paul

---

From: Ralph Dolmans <[email-masked]>
Date: Thu, 17 Nov 2016 11:36:04 +0100

Hi,

Maybe I'm missing something, but it is not clear to me whether this
document (-06) allows generation of NODATA answers using matching NSEC
records that do not have the QTYPE set in the type bitmap.

I don't see it explicitly mentioned. The RFC4035 update in section 7
seems to allow it (or at least not disallow it). However, Section 4 only
mentions covering (not matching) NSEC records. Same in section 5.1: "The
validating resolver needs to check the existence [...] and an NSEC RR
covering the query name.".

Section 5.1 does mention using NSEC to return NODATA responses, but that
might also be the result of an ENT answer. Section 5.3 seems to disallow
NODATA answers for wildcards: "If the corresponding wildcard record is
not in the cache, it MUST fall back to send the query to the
authoritative DNS servers.".

I hope the intention is to allow NODATA responses for wildcards,
otherwise random QNAME attacks are possible on wildcard records.

And some nits, for which I'll submit a pull request:
  - In the abstract: s/negative based/nagative answers based/
  - Section 1: s/with NXDOMAIN immediately/with negative answers
immediately/ (this also catches NODATA answers for ENTs)
  - Section 2: "Closest Encloser" and "Next closer name" are not used in
this document.
  - Section 3: s/starting/stating/
  - Section 4, sentence of 4th paragraph ends abruptly "(for the"
  - Section 4, last paragraph: s/the TTL of the NSEC record is the
authoritative statement/the TTL of the NSEC/NSEC3 record and the
SOA.MINIMUM field are the authoritative statement/ (and/or a reference
to section 5.4?)

Regards,
-- Ralph

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Nov 2016 21:20:32 +0900

> In that case, the msg-id would be appreciated.)

Ok (I read further downthread as well, and multiple people support this).
DONE.

> s/RFC2308]also/RFC2308] also/

Thank you.
DONE

> RECOMMENDED in second paragraph same section?

SHOULD seems right (based upon other comments too)
DONE

> (nit) Section 6: s/authorative/authoritative/

Also caught by someone else.
DONE

> the authors poke me when I am not jet-lagged.

I just added: "As these benefits are only accrued by those using
DNSSEC, it is hoped that these techniques will lead to more DNSSEC
deployment."

Additional / other suggestions welcome.
DONE

> or "delete it from cache and proceed as normal"?  Could you please clarify the text

This is originally MarkA's text (CCed). I'm assuming what was meant was:
If the NSEC record has not been verified as secure it should be
discarded, and not placed in the cache.

(as far as I can tell, non-secure NSECs should never make it into
cach.... oh, huh, an NSEC in a non-signed zone is still a valid RR,
and so it could be in the cache... so I guess it should simply be
ignored... so, proceed an normal?! I've confused myself.... Now I
think it should be "If the NSEC record has not been verified as secure
it should be ignored". Mark?

> Also 'ENT' is a abbreviation neither defined anywhere else nor explained in this

How is:
This procedure outlines how to determine if a given name does not
exist, or is an ENT (Empty Non-Terminal, see "RFC5155" Section 1.3)

> in the respective sections or in separate Section or as a part of Appendix B.

This seems like it would be really hard to capture in a readable form.
I'd welcome any assistance that people might have here (i could say
something like "Referring to the first example in Section 3, if the
resolver were to get a query for ball.example.com, and already had an
NSEC record covering albatross.example.com to elephant.example.com it
should use this information to synthesize a negative answer", but this
is a: imprecise, b: wordy and c: not (IMO) particularilty helpful).
Happy to take any donated text.

not done.

> and I would be happy to review next revision.  In case I am silent bug me until

Thank you. I have integrated these and posted a new version on Github:
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse
I have not yet pushed a new version to the IETF as I'm trying to
integrate suggestions as I get them.

Please let me know if these work for you, and I'll push a new version
once I've incorporated more comments.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Nov 2016 21:21:33 +0900

On Wed, Nov 16, 2016 at 5:51 PM, Matthijs Mekking
<[email-masked]> wrote:
> I am in favor of dropping the paragraph, though it is already better than it
> was before (with RFC 2119 keywords).
>

Ask and ye shall receive!
DONE (as part of the Ondrej set above).
W

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 22 Nov 2016 14:29:03 +0100

Hi,

This document looks almost good to me. I have some nit comments.

- Page 3, Section 1, says a DNS negative cache is used to cache the fact
that a name does not exist. But it also caches if the name is valid but
there are no records for the type. Perhaps:

"..., and is used to cache the fact that a RRset does not exist."

- On Page 4, Section 3: Now, assume that the (DNSSEC signed)
"example.org" zone contains:

The "Now" reads as, "Now what if". Perhaps:

"Another example: assume that the..."

- Page 5, Section 4 and 5 has a lot of duplication: It both quotes RFC
the same section of 4035 and both relaxes the recommendations given
there. It is even repeated a third time in Section 7. I think this
redundancy can be removed

- Page 9, Section 9, has another recommendation for implementations with
respect to configurations (for maximum ttl of NSEC records in the
NCACHE). Either remove the line or relax it.

- Page 15, Appendix B has acknowledgements to Mark which I believe
belong in Section 11 which is appropriately titled "Acknowledgements".
Also this section only gives guidance on NSEC.

I have made a PR that deals with these nits. Feel free to merge or
cherry pick:

https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/5

Best regards,
  Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Tue, 22 Nov 2016 09:39:54 -0800

At Thu, 17 Nov 2016 11:36:04 +0100,

> covering the query name.".

FWIW, I raised the same comment/question for an earlier version:
https://www.ietf.org/mail-archive/web/dnsop/current/msg17875.html

I've checked the thread, and found that while Warren replied to my
comments this particular comment didn't have any followup:
https://www.ietf.org/mail-archive/web/dnsop/current/msg17993.html

I suspect it has been simply forgotten since then rather than
rejected.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Nov 2016 15:59:41 -0500

> https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/5

Thank you VERY much - I really appreciate the help.
I merged all the changes, other than those in a17e0f1 (remove
redundant quotes from rfc4035 and recommendation updates) -- this is
because the RFC Editor really wants an "Updates to RFCxxxx" section. I
can try do some more cleanup around that section though.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 25 Nov 2016 18:42:37 -0500

> can try do some more cleanup around that section though.

Two things:

1.  Yes, the RFC editor (and the IESG) *really* do like the "Updates to 
RFCxxxx" section.  As I've learned, it pays to be very explicit there.

2. Thanks for all these updates Warren. Once we get a new version I'll 
start another WGLC to address these.

tim