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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Shumon,

On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque <[e-mail]> wrote:

>
>> ----------------------------------------------------------------------
>> 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?
>>
>
> Yes, agreed. How about?
>
> "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".

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

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

Do The Right Thing, of course.

Thanks for considering my comments!

Spencer