Re: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

神明達哉 <> Mon, 23 November 2015 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 248811AC3F3 for <>; Mon, 23 Nov 2015 10:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.322
X-Spam-Level: *
X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wGAoQ-PfLtNM for <>; Mon, 23 Nov 2015 10:08:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3E481AC44D for <>; Mon, 23 Nov 2015 10:08:51 -0800 (PST)
Received: by iofh3 with SMTP id h3so196131146iof.3 for <>; Mon, 23 Nov 2015 10:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IZ/h0dTVKcI+yae40J7Qjgq10Zy8BCPukOWg+y9wx6Q=; b=kePo7MdAG6PfQSkBs2x16WymkCbgZyLowx0PloYUjgo3/a8huDyI4TvhQDwIXSmKB5 K5ZAhsDdC2KTX1+CNe7AiQxSN0JHtjS9WNdnLMxOJ0gxW4+IJFnrktz9fHHG0a3vNruN qArCsnF4QuJ7mwHDUbc9tkWCYZxhMC4hlfwgWCkWvveUQacidWt/M5z59maJIa1Gn7oE crHbEALFtFSQciCTWnHossufWF4cuxTE7pKbDfAuIY4GK1FY0Y5lGaoK/Lqllrs/AZBW 99XDiBYWtqFJZDenEdRw+mcGz+v7IgG5B9Za5rynXofffaVwl9qVFPsIQ3ws9pFH/rTh 0Nwg==
MIME-Version: 1.0
X-Received: by with SMTP id g82mr24931540ioj.178.1448302131351; Mon, 23 Nov 2015 10:08:51 -0800 (PST)
Received: by with HTTP; Mon, 23 Nov 2015 10:08:51 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 23 Nov 2015 10:08:51 -0800
X-Google-Sender-Auth: LLtbolU_iVt26TvfCDBE-Fu3TbI
Message-ID: <>
From: 神明達哉 <>
To: Stephane Bortzmeyer <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2015 18:08:54 -0000

At Sun, 22 Nov 2015 14:52:34 +0100,
Stephane Bortzmeyer <> wrote:

> > I've read draft-bortzmeyer-dnsop-nxdomain-cut-00
> Do note that -01 will be out in the next days and there are
> substantial changes. So, readers may prefer to wait 48h :-)

Okay, I'm now referring to 01.

> >   I suspect this is highly implementation dependent and so the
> >   RFC2119 'SHOULD' is not really appropriate.  First off, what
> >   "delete" means isn't very clear.
> It is now defined. ' "Deleted" means that subsequent requests for
> these names will yield NXDOMAIN. '
> >   But even if the resolver doesn't really "delete" the memory, it
> >   could look as if it did as long as the resolver doesn't use it for
> >   subsequent query handling
> Correct, but this is a general rule with IETF protocols: we mandate
> the external behavior, not the implementation.

That was exactly my point, and in that sense I'd say "SHOULD delete"
is redundant (and possibly imposes unnecessary restrictions on
implementations).  The revised wording in 01 now looks even more

   When an iterative caching DNS resolver stores an NXDOMAIN in its
   cache, all names and RRsets at or below that node SHOULD be deleted
   since they will have become unreachable.  "Deleted" means that
   subsequent requests for these names will yield NXDOMAIN.

as it's already covered in the first paragraph:

   When searching downward in its cache, an iterative caching DNS
   resolver SHOULD stop searching if it encounters a cached NXDOMAIN.
   The response to the triggering query should be NXDOMAIN.

(Strictly speaking it does not use a 'SHOULD' about returning NXDOMAIN
for these queries, but that should be a natural consequence of the
SHOULD about stopping the search).

> > I suggest stating that more clearly.
> Done

Regarding this topic, I think it should rather refer to
qname-minimization here:

   queries.  (It would be better if the SOA record in the NXDOMAIN
   response were sufficient to find the non-existing domain but this is
   more delicate, see Section 5.)

than updating the interpretation of SOA.  qname-minimization is much
less controversial and will certainly help in this scenario.

> >   A minor corner case, but I suspect this is not fully accurate if
> >   QNAME is the name specified in the question section.
> Added.

Perhaps you might introduce a dedicated terminology such as "NXDOMAIN
name" as used in someone else's comment and use it consistently,
rather than just note this once and keep using QNAME in other places.

> >    [joost-dnsterror]
> >               Joost, M., "About DNS Attacks and ICMP Destination
> >               Unreachable Reports", December 2014,
> >               <>.
> >
> >   Getting this URL resulted in 403 error.  Is that only for me?
> Works for me.

Sorry for the false alarm, it seems to be my local problem.

One additional comment on 01:

- Section 7

   The technique described here may help against a denial-of-service
   attack named "random qnames" and described in Section 3.

  I suggest "a denial-of-service attack on authoritative servers" for
  the same reason as my comment on the "benefits" section of the
  previous version.

JINMEI, Tatuya