Re: [DNSOP] Working Group Last Call

Warren Kumari <warren@kumari.net> Fri, 07 October 2016 22:58 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4058B129455 for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 15:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMV0NtMQ5Ucs for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 15:58:53 -0700 (PDT)
Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8099129431 for <dnsop@ietf.org>; Fri, 7 Oct 2016 15:58:52 -0700 (PDT)
Received: by mail-qt0-f174.google.com with SMTP id f6so27567482qtd.2 for <dnsop@ietf.org>; Fri, 07 Oct 2016 15:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BvbcGthWf9qU0MNvcX8hUoSSnCVjAqaMdvxIalP6sJE=; b=14xweOZI1420oTO4Fxt6VOBpxAZiZB/xMcU37JraefDhyzBlSHVdYmDK6Y8a5bHUrj nylO+HEUp+k6fLhy8J1c6/Ow8IkoGbR5LvzjSSLa9DXv0y5cXcqROssfwQdvon3w9l8R Hj5+yoPBCO9gN1muBHTNsgPr7p2a9Cd2pfGdbxKYxbUje77Vqo2myRjtZ1kbYXynoHEJ 4vgixNoYbghjjgi2EAB1qIadogsOPs3pmzIEIn8/1RO34dHDgk9oOB+WhPuQE6LCkLyK MSyhBiXmpL9+h1oO/4tpeqgvygaAHM4w68Nsu+uSnNCVSiUQqaOnIFTxH3xPZkgOQX8U dVTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BvbcGthWf9qU0MNvcX8hUoSSnCVjAqaMdvxIalP6sJE=; b=lpbGN1VWH6rOu+IMjjf0JhhyT9uN5NSS8hTO3MjIqcIKgDaX7Ma4hbiFol1QLnGhsd tjGGQMaBn99bDVAamRvMOXinIC4A2M9VT2ZQKL35MzamFXybA2uHfuZAoZ+buTVwYT5D qwIrGXL3CguAnnes8+c/Ew4cIH1VPLWbdUj/3piQGyJ9DzZ7ZtcRp8X8DG90YJWCphWa Ay8lTZZCW88ByqRVlxqCoNyqXxCUobes0bGFlSRbuyZ54YlIUuwDkIQZAqpkiU5I9+wp yn3tRqGaUus0+lFBNUnKbyYj/2HqJpNWp/3bzw84yc+lwreF2OzV17o1jDf3RZex2bm0 aWmw==
X-Gm-Message-State: AA6/9RkmSPrIPBc4QeTi0d3i3YJ2jftLkOkwwmLtACPsuezYA3tlMUUeqaV8trIAc38vv7UnDupm7eqW50VjcSXL
X-Received: by 10.200.40.197 with SMTP id j5mr22095164qtj.43.1475881071926; Fri, 07 Oct 2016 15:57:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Fri, 7 Oct 2016 15:57:21 -0700 (PDT)
In-Reply-To: <eda9f6f0-6ecc-9fcf-d961-d60d20831549@pletterpet.nl>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <eda9f6f0-6ecc-9fcf-d961-d60d20831549@pletterpet.nl>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 7 Oct 2016 18:57:21 -0400
Message-ID: <CAHw9_iLDY5=VS8Wc9onGZpQ9Z15k93RXrNGkv8ULS-9c9vHULA@mail.gmail.com>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VsJbN_1bRkobgRvX7cHLzzy3xXU>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 22:58:55 -0000

On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking <matthijs@pletterpet.nl> 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. :-)

>
> 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....
>
> 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,
> so I would replace 'currently' with 'at the time of writing'. But more
> importantly, where does this number come from? A reference here seems
> appropriate.

Good point on the "currently". I put in a reference to
www.root-servers.org. Many letters are posting RSSAC-002 data - I took
a few days statistics and calculated the average from this.


>
> 4. There are several bikeshedding issues/nits that I have put up a PR for
> here:
>
>   https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/1

Thank you. I incorporated those.

>
> 5. It seems that sections 5.2 and 5.3 only consider NXDOMAIN responses. Is
> it perhaps that at the end of section 5.1 NODATA answers are covered?
> I would suggest a better structure to make more explicit the scope.
> Currently it reads as if NODATA answers should always be subject to
> aggressive use of negative cache, while NXDOMAIN answers only if the
> configuration option enables it.
>
> Given these remarks, I suggest the following structure and text:
>
>   If the negative cache of the validating resolver has sufficient
>   information to validate the query, the resolver MAY use NSEC, NSEC3
>   and wildcard records aggressively. Otherwise, it MUST fall back to
>   send the query to the authoritative DNS servers.
>
>   It is recommended that resolvers that implement Aggressive Use of
>   Negative Caching provide a configuration switch to disable the
>   feature. Separate configuration switches can be implemented for
>   the aggressive use of NSEC, NSEC3 and wildcard records.
>
>   5.2 NSEC
>
>   5.2.1 No Data
>
>   If the query has an NSEC record matching the query name, proving
>   the data requested does not exist, the resolver MAY respond with an
>   empty NOERROR (No Data) answer.
>
>   5.2.2 Name Error
>
>   If the resolver has an NSEC record covering the source of synthesis
>   and an NSEC record covering the query name, it MAY respond with an
>   NXDOMAIN answer.
>
>   5.2.3 Wildcard No Data
>
>   If the resolver has an NSEC record matching the source of synthesis
>   and an NSEC record covering the query name, it MAY respond with an
>   empty NOERROR (No Data) answer.
>
>   5.2.3 Wildcard Answer
>
>   If the resolver has an NSEC record covering the query name, but no
>   NSEC record matching the source of synthesis, it MAY respond with an
>   wildcard expanded answer from the cache. If the corresponding
>   wildcard record is not in the cache, it MUST fall back to send the
>   query to the authoritative DNS servers.
>
>   5.2 NSEC3
>
>   ...
>
>
> 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


>
> 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:
>>    https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> 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