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