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". > > >> >> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
