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

[Shumon Huque <[e-mail]>]

On Mon, Nov 23, 2015 at 1:08 PM, 神明達哉 <[e-mail]> wrote:

> 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).


Yes, I agree. The current description is a bit too implementation specific.


> 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.
>

Also agree. I think it would be best if this draft remained focussed on
correct interpretation of the NXDOMAIN response code, and leave this SOA
discussion out.


> > >   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.
>
>
> 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.
>

Yes,  this sounds appropriate.

-- 
Shumon Huque