On Wed, Sep 14, 2016 at 6:05 PM, Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote:
> Hi, Shumon, > > On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque <shu...@gmail.com> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
