Re: [DNSOP] Working Group Last Call

Matthijs Mekking <> Fri, 14 October 2016 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEF6E12981F for <>; Fri, 14 Oct 2016 05:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XeLHESfuvvI8 for <>; Fri, 14 Oct 2016 05:44:51 -0700 (PDT)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45700129818 for <>; Fri, 14 Oct 2016 05:44:51 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:d9d4:42e4:a681:d4bf] (unknown [IPv6:2001:981:19be:1:d9d4:42e4:a681:d4bf]) by (Postfix) with ESMTPSA id 148DDAE76; Fri, 14 Oct 2016 14:44:49 +0200 (CEST)
Authentication-Results:; dmarc=none
To: Warren Kumari <>
References: <> <> <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Fri, 14 Oct 2016 14:44:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] Working Group Last Call
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Oct 2016 12:44:54 -0000

Hi Warren,

On 08-10-16 00:57, Warren Kumari wrote:
> On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking <> wrote:
>> All,
>> I reviewed this draft and while it is shaping up nicely, I don't think it is
>> quite ready for publication:
>> 1. As John pointed out earlier, the document makes an inconsistent use of
>> RFCC 2119 keywords, and we need to decide whether to use MAY or SHOULD.
>> Looking at the definitions of the keywords again I am leaning towards MAY,
>> but given the described benefits I could see how SHOULD would be
>> appropriate. Either way, it should be consistent. Also, the used keyword for
>> NSEC should not be different than that for NSEC3.
> Ok, I *think* that I have this correct, but it MAY still be muddled. :-)

It is still muddled :(

In Section 5: [SHOULD]

   If the validating resolver's cache has sufficient information to
   validate the query, the resolver SHOULD use NSEC/NSEC3/wildcard
   records aggressively.

In Section 5.1 NSEC: [SHOULD]

   Implementations which support aggressive use of NSEC SHOULD enable
   this by default.

In Section 5.1 NSEC3: [MAY]

   A validating resolver implementation MAY support aggressive use of
   NSEC3. If it does support aggressive use of NSEC3, it SHOULD enable
   this by default.

In Section 5.2 Wildcards: [MAY]

   As long as the validating resolver can determine that a name would
   not exist without the wildcard match, it MAY synthesize an answer for
   that name using the cached deduced wildcard.

   An implementation MAY support aggressive use of wildcards.

>> 2. In addition to the first point, I don't think it is appropriate to use
>> RFC 2119 keywords to dictate name server configuration. Mentioning it would
>> be useful to have configuration options for enabling and disabling this
>> functionality seems okay, but drop the RFC 2119 formalities.
> I think that we came to agreement further down-thread that it is OK to
> have this. If you disagree with this, please provide some text....

The argument for this being OK is that there exist other RFCs that do
that. Personally I find that is not a very convincing argument :)

There is PR with suggested text:

In here everything in Section 5 is a SHOULD, and key words related to
configurations are downgraded to lower case.

>> 3. In section 6 on Benefits, it says "currently around 65% of queries to
>> Root Name servers result in NXDOMAIN responses." This is quickly outdated,
>> A similar layout for NSEC3 should be provided, and I am willing to provide
>> that if this layout is accepted.
> So, I have incorporated a number of changes around this section, and
> much of it has been rewritten. I *think* that this is now clearer, and
> covers your concern -- however, I've been staring at the same text for
> many hours, and shuffling text back and forth, and so I may simply be
> confused. Please let me know if you still think it needs changing.
> W

Yes, this is indeed much clearer, and takes away my concerns. The
mentioned PR has some minor changes with respect to this though.

Best regards,

>> Best regards,
>>   Matthijs
>> On 22-09-16 14:19, Tim Wicinski wrote:
>>> All
>>> This draft has been worked on and it seems that the Working Group is
>>> happy with the updates that have been made and I feel it's ready for the
>>> next step.
>>> This starts a Working Group Last Call for:
>>>     "Aggressive use of NSEC/NSEC3"
>>>       draft-ietf-dnsop-nsec-aggressiveuse
>>> Current versions of the draft is available here:
>>> Please review the draft and offer relevant comments. Also, if someone
>>> feels the document is *not* ready for publication, please speak out with
>>> your reasons.
>>> It's currently marked as "Proposed Standard", so if folks feel
>>> differently then please speak up.
>>> This starts a two week Working Group Last Call process, and ends at
>>> midnight 7 October 2016 UTC.
>>> thanks
>>> tim
>>> _______________________________________________
>>> DNSOP mailing list
>> _______________________________________________
>> DNSOP mailing list