Hi Ondřej,

On 16-11-16 07:09, Ondřej Surý wrote:
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.)

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



~~~
(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:ondrej.s...@nic.cz    https://nic.cz/
 --------------------------------------------

----- Original Message -----
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: "dnsop" <dnsop@ietf.org>
Sent: Wednesday, 16 November, 2016 03:41:29
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

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/

_______________________________________________
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

Reply via email to