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

[神明達哉 <[e-mail]>]

At Sun, 22 Nov 2015 14:52:34 +0100,
Stephane Bortzmeyer <[e-mail]> 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
redundant:

   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,
> >               <http://www.michael-joost.de/dnsterror.html>.
> >
> >   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