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

From: Warren Kumari <[email-masked]>
Date: Tue, 6 Dec 2016 16:56:40 -0500

On Thu, Nov 17, 2016 at 5:36 AM, Ralph Dolmans <[email-masked]> wrote:
> 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.

Yup, that is the intent, and I have just posted a new version to
Github clarifying this -
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse

Apologies for this taking so long -- I asked my co-authors for text,
they quickly provided some. I was wondering why no-one commented, and
then realized that I'd (stupidly) done that all off-list.

I *think* that I have now addressed all open questions / comments /
suggestions, *please* let me know if I missed anything.
I've gotten lots of helpful comments (thanks!), if I missed any it was
not intentional...

W

>
> 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
>
> On 16-11-16 03:41, [email-masked] wrote:
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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