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

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

I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 and have a few
comments.  (I support the basic idea of the proposal, btw)

- Abstract: s/status code/response code/

   This document states clearly that when a DNS resolver receives a
   response with status code NXDOMAIN, it means that the name in the

- Section 2

   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.

  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.  If the resolver implementation frees memory
  region used for the corresponding cached RRsets that are now known
  to be nonexistent, it would be certainly considered a "delete".  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 (as described in the first paragraph).
  And the implementation may actually rather prefer to keep them
  in-memory until it needs memory for other purposes to save the
  overhead of actually freeing them.  So, in terms of interoperability
  the only important requirement is the first SHOULD.  IMO, whether
  the resolver implementation should "delete" the ancestor RRsets
  (including what "delete" actually means) should leave to specific
  implementation, and therefore I suggest just removing this
  paragraph.

- Section 3

   NXDOMAIN cut may also help with random QNAME attacks
   [joost-dnsterror] [balakrichenan-dafa888].  In these attacks, queries
   are sent for a QNAME composed of a fixed suffix ("dafa888.wf" in one
   of the articles above), which is typically nonexistent, and a random
   prefix, different for each request.

  If the intended attack is against the authoritative server
  (such as that for "dafa888.wf" or "wf") exploiting innocent
  resolvers, then I see that.  But if it's about the attack against
  the resolver (forcing it to perform recursive resolutions very
  often), I doubt the mitigation effect of this proposal since the
  attacker can easily circumvent the defense (using '<random>.' or
  existent names in a zone that has a wildcard, etc).  Assuming the
  intended attack is the former type ([balakrichenan-dafa888] seems to
  talk about that type of attack), I suggest stating that more
  clearly.

- Section 5

   In this document, we deduce the non-existence of a domain only for
   NXDOMAIN answers where the QNAME was this exact domain.

  A minor corner case, but I suspect this is not fully accurate if
  QNAME is the name specified in the question section.  If I remember
  it correctly BIND 9 returns an NXDOMAIN if it finds a CNAME chain
  that leads to a non-existent name.  In this case "QNAME" itself
  exists but the response is NXDOMAIN.  I'm not sure if we do
  something about the text because of this, but I'm noting this just
  for completeness.

- References

   [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?

--
JINMEI, Tatuya