Subject: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Sep 2016 10:53:04 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-nxdomain-cut-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I honestly look forward to reading DNSOPS drafts because they are
uniquely chatty, and this one is no exception (awesome document title,
dude). That said, 

   This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
   updates both of them.
   
being "a bit modified" is like being a bit dead (either you're dead or
you're not), so maybe that's TOO chatty? 

This draft was very clear to me, as a non-DNS reader. Thanks for that.

Just for my own education, 

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply.  (Until the TTL of this cached data
   expires.)
   
I found myself wondering why this behavior is allowed. Is this a
performance thing, that you continue to respond normally until normal TTL
expiration happens with no special processing required, or is this about
the non-tree cache implementations described in Section 6, or is there
more to it than that? Perhaps that's worth a word or two explaining.

In this text in Appendix A, 

   Even if the accompanying SOA record is
   for example only, one cannot infer that foobar.example is
   nonexistent.  The accompanying SOA indicates the apex of the zone,
   not the closest existing domain name.
   
it's not clear that this practice is OK, and (especially from the example
that will be deleted), it seems dodgy to the uninitiated. Perhaps it's
worth saying so clearly (if it is, in fact, OK).

---

From: Shumon Huque <[email-masked]>
Date: Wed, 14 Sep 2016 14:33:58 -0700

Yes, agreed. How about?

"This document updates portions of RFC 1034 and RFC 2308".

> more to it than that? Perhaps that's worth a word or two explaining.

There was a long discussion on list about this point, but the quick summary
is that it is mostly for performance. For implementations that use a flat
data structure like a hash table, it is much more work to invalidate all
cache entries under the NXDOMAIN eliciting node. I believe Section 6 of the
draft does discuss this issue. Maybe we can make it clearer, or let us know
if you have any specific suggestions for doing so.

> worth saying so clearly (if it is, in fact, OK).

The section is attempting to say that it is NOT OK to use the SOA record
owner name. We could make that clearer.

I would personally be okay with removing this section also. I can't recall
what discussion happened that caused this scenario to be included - maybe
Stephane remembers.

-- 
Shumon Huque

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 20:05:48 -0500

Hi, Shumon,

> "This document updates portions of RFC 1034 and RFC 2308".

That would work for me. "portions of" is implicit in Updates, because if
you were updating all of those RFCs you'd probably be Obsoleting them, but
I wouldn't object to saying "portions of".

> There was a long discussion on list about this point, but the quick
> summary is that it is mostly for performance. For implementations that use
> a flat data structure like a hash table, it is much more work to invalidate
> all cache entries under the NXDOMAIN eliciting node. I believe Section 6 of
> the draft does discuss this issue. Maybe we can make it clearer, or let us
> know if you have any specific suggestions for doing so.
>

Just providing a hint would have worked for me, and a forward pointer to
Section 6 would be even better. Perhaps something like

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply until the TTL of this cached data
   expires, since this may avoid additional processing when an NXDOMAIN
   cut is received. Section 6 provides more information about this.

But you're more likely to get the text right than I am ...

> what discussion happened that caused this scenario to be included - maybe

Do The Right Thing, of course.

Thanks for considering my comments!

Spencer

---

From: Shumon Huque <[email-masked]>
Date: Wed, 14 Sep 2016 18:47:34 -0700

> I wouldn't object to saying "portions of".

Ah, good point :-) I'm fine with dispensing with "portions of" in that case.

> But you're more likely to get the text right than I am ...

Your proposed text sounds good to me (although I'd replace your "NXDOMAIN
cut" with "NXDOMAIN response" in the penultimate sentence above).

>> I would personally be okay with removing this section also. I can't
>> recall what discussion happened that caused this scenario to be included -
>> maybe Stephane remembers.
>>
>

Sure - and thanks for the comments!

-- 
Shumon Huque

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Sep 2016 22:38:24 -0500

Hi, Shumon,

> cut" with "NXDOMAIN response" in the penultimate sentence above).

"But you're more likely to get the text right than I am ..." :D

Thanks for getting it right!

Spencer

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Sep 2016 10:37:10 +0200

On Wed, Sep 14, 2016 at 02:33:58PM -0700,
 Shumon Huque <[email-masked]> wrote 
 a message of 146 lines which said:

> The section [appendix A] is attempting to say that it is NOT OK to
> use the SOA record owner name. We could make that clearer.

OK, but I don't see how.

> recall what discussion happened that caused this scenario to be
> included - maybe Stephane remembers.

This was mostly because I did not get the point at the beginning (I
think John Levine explained it to me). IMHO, it is important to keep
this appendix (not a "real" section) because other DNS people may make
the same mistake as I originally did and ask "why not use the SOA
record to find the NXDOMAIN cut?"

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 15 Sep 2016 04:49:52 -0400

>> use the SOA record owner name. We could make that clearer.

Here is the paragraph in question:

    In this document, we deduce the non-existence of a domain only for
    NXDOMAIN answers where the denied name was this exact domain.  If a
    resolver sends a query to the name servers of the TLD example, and
    asks the MX record for www.foobar.example, and receives a NXDOMAIN,
    it can only register the fact that www.foobar.example (and everything
    underneath) does not exist.  Even if the accompanying SOA record is
    for example only, one cannot infer that foobar.example is
    nonexistent.  The accompanying SOA indicates the apex of the zone,
    not the closest existing domain name.

Here is a possible update (changes marked with *'s)

    In this document, we deduce the non-existence of a domain only for
    NXDOMAIN answers where the denied name was *the* exact domain.  If a
    resolver sends a query to the name servers of the TLD example, *then*
    asks *for* the MX record for www.foobar.example, and receives a
    NXDOMAIN,it can only register the fact that www.foobar.example (and
    everything underneath) does not exist.  *This is true regardless*
    if the accompanying SOA record is for example only*. O*ne cannot
    infer that foobar.example is nonexistent.
    The accompanying SOA *record* indicates the apex of the zone,
    not the closest existing domain name.

tim