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

[Shumon Huque <[e-mail]>]

On Wed, Sep 14, 2016 at 6:05 PM, Spencer Dawkins at IETF <
[e-mail]> wrote:

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

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


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

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


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

Sure - and thanks for the comments!

-- 
Shumon Huque