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

From: 神明達哉 <[email-masked]>
Date: Fri, 20 Nov 2015 12:12:20 -0800

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Nov 2015 14:52:34 +0100

On Fri, Nov 20, 2015 at 12:12:20PM -0800,
 神明達哉 <[email-masked]> wrote 
 a message of 79 lines which said:

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

> - Abstract: s/status code/response code/

Stupid error fixed,
thanks.
<https://github.com/bortzmeyer/ietf-dnsop-nxdomain/commit/98d3e24cec1afa0feece328164519ba96112e7b1> 

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

> I suggest stating that more clearly.

Done

>   QNAME is the name specified in the question section.

Added.

If I remember
>   that leads to a non-existent name.

And rightly so because of RFC 6604, that I initially forgot, and which
is now a normative reference. Thanks for the reminder.

>   Getting this URL resulted in 403 error.  Is that only for me?

Works for me.

  Trying 77.75.249.241...
* Connected to www.michael-joost.de (77.75.249.241) port 80 (#0)
> GET /dnsterror.html HTTP/1.1
> Host: www.michael-joost.de
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sun, 22 Nov 2015 13:42:34 GMT
< Server: Apache
< Last-Modified: Tue, 08 Mar 2011 07:45:53 GMT
< ETag: "5208583f-4d-49df3cd4cd24c"
< Accept-Ranges: bytes
< Content-Length: 77
< Vary: Accept-Encoding,User-Agent
< X-Robots-Tag: noindex
< Content-Type: text/html; charset=utf-8
<

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 Nov 2015 10:08:51 -0800

At Sun, 22 Nov 2015 14:52:34 +0100,

> substantial changes. So, readers may prefer to wait 48h :-)

Okay, I'm now referring to 01.

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

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.

> >   QNAME is the name specified in the question section.

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.

> >   Getting this URL resulted in 403 error.  Is that only 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

---

From: Shumon Huque <[email-masked]>
Date: Tue, 24 Nov 2015 05:39:04 -0500

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

> implementations).

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

> The revised wording in 01 now looks even more
> redundant:
>

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

>   the same reason as my comment on the "benefits" section of the

Yes,  this sounds appropriate.

-- 
Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 29 Nov 2015 15:16:28 +0100

On Tue, Nov 24, 2015 at 05:39:04AM -0500,
 Shumon Huque <[email-masked]> wrote 
 a message of 234 lines which said:

> > That was exactly my point, and in that sense I'd say "SHOULD
> > delete" is redundant (and possibly imposes unnecessary
> > restrictions on implementations).
> 
> 

My concern is that some implementations may have a cache composed of a
tree structure *plus* a hashed index for speed. When receiving a
query whose answer is in the cache, such implementation may not
perform a "downward search" in the cache.

May be something like: "After the reception of a NXDOMAIN answer for a
given name, the resolver SHOULD/MUST? reply NXDOMAIN for every name
under the denied name." (There are details, such as TTL and such as
RFC 6604, see the draft for these.)

That way, we just specify a behaviour, with zero implementation
detail.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 30 Nov 2015 11:25:43 -0800

At Sun, 29 Nov 2015 15:16:28 +0100,

> That way, we just specify a behaviour, with zero implementation

Yes, this will address my point perfectly.

--
JINMEI, Tatuya