NXDOMAIN: There Really Is Nothing Underneath
draft-ietf-dnsop-nxdomain-cut-05
Yes
(Alexey Melnikov)
(Joel Jaeggli)
(Kathleen Moriarty)
(Stephen Farrell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 04 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(for -04)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2016-09-09 for -04)
Unknown
One minor question: In section 2, paragraph 3, which behavior is "this behavior"? The continuing to use cached data under the cut, or the cached non-existence itself?
Joel Jaeggli Former IESG member
Yes
Yes
(for -04)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(for -04)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2016-09-14 for -04)
Unknown
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? 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. 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).
Stephen Farrell Former IESG member
Yes
Yes
(for -04)
Unknown
Terry Manderson Former IESG member
Yes
Yes
(2016-09-13 for -04)
Unknown
In a very poor attempt at not showing my own geek level too much here, this document was a pleasure to read, well constructed, and a perfect fit for the ambiguity in 1034. Thank you!!
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2016-09-15 for -04)
Unknown
I like the sections 3.1 and 3.2. These are in line with the recent discussion on the wgchairs mailing list, and https://tools.ietf.org/html/draft-wilde-updating-rfcs-00. Copying erik.wilde@dret.net
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -04)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -04)
Unknown