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

神明達哉 <> Wed, 17 August 2016 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 477FB12D7D1; Wed, 17 Aug 2016 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u_iWZcrRRAb3; Wed, 17 Aug 2016 11:18:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 586D612D74A; Wed, 17 Aug 2016 11:18:23 -0700 (PDT)
Received: by with SMTP id v123so10869590qkh.3; Wed, 17 Aug 2016 11:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c2m1vR3AnAl3IMrWeyORd/G718o0FAynCt6nFSd7WWs=; b=xqWOhOijxxG2UrRVmH1vL8gdZlldnJSs1ff9iFJeVlPKb56dgpzB9FDgD+0M0Z5sVI vCRw8vb8d/sr3vE9DsX5RJSTMn0U5m1rW+se3AMJT/zLqftoEf5yySFxzmC/ENDFuWqS WLaGhIM917Gk6dTnzdzeRox1WVoCRRlEECpTFBEtHo/NVmmIzwRep3kE2Xd8owAtJJI6 +Xjksx61va4DjxpYX84blsIjZp/069nHgRoJWtppJh9DsmOgmOy7ptodNME6nk756cpW Ad+YvplaQNO4zyorRvb0SaFD5MSPs3NSNalUAgsbXPK4K38UWGDjYFkb96yzAzoq2ovp XCdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c2m1vR3AnAl3IMrWeyORd/G718o0FAynCt6nFSd7WWs=; b=PBGrxkG7QroTq8Kc1VwQlaaRFL343+WlT1/KpYww105KiHXkWPnCDDIXtldt+3/fDN Bto0dOyymRItyQIY9hYYPxfX8Y37c5V722NGu4LQHXy4GCZ9aZLC4hcE2ZPpbFGvC64J cTLzzXAWd6rqdBBk3XITU5DUH87q3zJVvTHXIbnl+wYFhSnPT68WjFk5QEvqI7vIT1FE hFfzBb8LC8t5RtBGoQYDkEsZYvAyRlys5G5mMmSStk+gqhM0z1Cg0MRjs2DCyuaKaNQD kLAPBlNWnzcUXAv1FemqQ5jh8e/m1N4qNYCKVeDzAicNRbgYSKMxs6LhMKQZp+fJerf+ IQJQ==
X-Gm-Message-State: AEkooutGBtUp+2LKi8rd5PlDfYsW9YT8xNs7vXFjeZCFVTsHJl3Q05M0uA4ps1fLJArZ7+xOlQlqO4EOkyspWQ==
X-Received: by with SMTP id k3mr46185205qkk.86.1471457902216; Wed, 17 Aug 2016 11:18:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 17 Aug 2016 11:18:21 -0700 (PDT)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Wed, 17 Aug 2016 11:18:21 -0700
X-Google-Sender-Auth: wgJWi-IwpkGkjVJ5uHKY1xX01w0
Message-ID: <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: dnsop <>,
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-01.txt
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: Wed, 17 Aug 2016 18:18:25 -0000

At Wed, 3 Aug 2016 13:32:56 -0700,
Warren Kumari <> wrote:

> We have updated this document with comments and feedback from Berlin.
> We have also gone through and done another editing pass, removing a
> significant amount of text which was intended to drive the discussion,
> but would not really be useful in a published RFC.
> Please review it, we believe that the document is ready (or almost
> ready) for WGLC.

I see draft-ietf-dnsop-nsec-aggressiveuse-01 has been improved a lot.

Some comments on this version:

- general: there still seem to be a (IMO) misleading claim as if this
  technique were a strong mitigation against DoS attacks rather than a
  possible performance optimization.  I'll point out some specific
  cases below, but independently from whether/how to address these
  points, we might want to follow the style of
  draft-ietf-dnsop-nxdomain-cut-04.  It has a dedicated section (sec
  4) that discusses the benefit, and mentions its attack mitigation
  effect as a secondary benefit.  I think the same logic applies to

- general: I suggest removing/rephrasing the phrase "full-service
  resolver".  As far as I understand it, nsec-aggressiveuse is totally
  irrelevant to whether the resolver is "full-service" (which I
  interpret as performing recursive resolution from the root) or not.
  The only critical point for it to work is that the resolver has/uses
  cache and it performs DNSSEC validation.  As long as a resolver
  meets this condition, nsec-aggressiveuse should be equally
  usable/effective even if it only uses an external forwarder.  Since
  the use of cache is probably too obvious, a better terminology would
  be "validating resolver".

- general: I wonder whether we also want to use NSEC/NSEC3 for
  NOERROR-NODATA type of negative cache information.

- Abstract

   This increases resilience to DoS attacks, increases
   performance / decreases latency, decreases resource utilization on
   both authoritative and recursive servers, and also increases privacy.

  I suggest rephrasing it to be less misleading, e.g.,

   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 DoS
   attacks to some extent.]

  The second sentence could simply be removed, but I added it in case
  if we really want to say something about it in the abstract.

- Section 1

   [...]  This method of negative caching requires
   exact matching; this leads to unnecessary additional lookups, which
   have negative implications for DoS survivability, increases latency,
   leads to extra resource utilization on both authoritative and
   recursive servers, and decreases privacy by leaking queries.

  I suggest removing "which have negative implications for DoS
  survivability" to be less misleading.

- Section 5.2

   [...] It SHOULD provide a configuration switch to
   disable aggressive use of NSEC and allow it to be enabled or disabled
   for specific zones.

  I suggest s/specific zones/specific domains/ since it's not trivial
  for a recursive server operator to know whether a particular domain
  name is a zone apex or not at the time of configuring the server.

- Section 5.4

   and it may be justified for performance and other benefits.  (Note
   that, so far, this is orthogonal to "when aggressive use (of NSEC) is

   Furthermore, when aggressive use of NSEC is enabled, the aggressive
   use of cached deduced wildcard will be more effective.

  This text seems to be derived from a prior review comment of mine,
  which was a bit too casual.  I suggest revising this part as

   and it may be justified for performance and other benefits.

   Such aggressive use of cached deduced wildcard can be employed
   independently from aggressive use of NSEC.  But, it will be more
   effective when both are enabled since the resolver can determine
   the name subject to wildcard would not otherwise exist more

JINMEI, Tatuya