NXDOMAIN: There Really Is Nothing Underneath
draft-ietf-dnsop-nxdomain-cut-05

[Ballot comment]
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

[Ballot 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?

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

[Ballot comment]
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!!

[Ballot comment]
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?

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type: Proposed Standard

This document clearly states that when a DNS resolver receives the response code of NXDOMAIN, it means that the domain name queried AND ALL THE NAMES UNDER IT do not exist. Currently this is an area where behavior varies depending on implementation.

The document updates Section 5 of RFC2308, and attempts to clarify RFC1034

Proposed Standard was chosen as it updates existing Standards.

In the document, the section 2 ("Rules") replaces the second paragraph of section 5 of RFC2308.  The document includes this paragraph in section 2, though in the middle of the discussion reflecting this:

    These rules replace the second paragraph of section 5 of [RFC2308].
  Otherwise, this document does not update any other parts of
  [RFC2308].  The fact that a subtree does not exist is not forever:
  [RFC2308], section 3, already describes the amount of time that an
  NXDOMAIN response may be cached (the "negative TTL").

The shepherd wonders if this should be handled more efficiently.

As for the updating of RFC1034, This is in the Third Paragraph of Section 1:

  However, in most known existing resolvers today, a cached non-
  existence for a domain is not considered "proof" that there can be no
  child domains underneath.  This is due to an ambiguity in [RFC1034]
  that failed to distinguish Empty Non-Terminal names (ENT) ([RFC7719])
  from nonexistent names.  The distinction became especially important
  for the development of DNSSEC, which provides proof of non-existence.
  [RFC4035], section 3.1.3.2, describes how security-aware
  authoritative name servers make the distinction, but no existing RFCs
  describe the behavior for recursive name servers.

Again, the Shepherd wonders if this can be documented more efficiently.

2. Review and Consensus

This document was reviewed and discussed both in DNSOP, but also other DNS-releated mailing lists.  The topic of strongly defining what happens with a NXDOMAIN and below that, especially with TLD servers. There was strong consensus to finally address outstanding issues in old standards.

3. Intellectual Property

There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References

There are no downward references

- IANA Considerations:

There are no IANA Considerations.

Checklist

X Does the shepherd stand behind the document and think the document is ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X Is the intent of the document accurately and adequately explained in the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?

X If this is a "bis" document, have all of the errata been considered?

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type: Proposed Standard

This document clearly states that when a DNS resolver receives the response code of NXDOMAIN, it means that the domain name queried AND ALL THE NAMES UNDER IT do not exist. Currently this is an area where behavior varies depending on implementation.

The document updates Section 5 of RFC2308, and attempts to clarify RFC1034

Proposed Standard was chosen as it updates existing Standards.

In the document, the section 2 ("Rules") replaces the second paragraph of section 5 of RFC2308.  The document includes this paragraph in section 2, though in the middle of the discussion reflecting this:

    These rules replace the second paragraph of section 5 of [RFC2308].
  Otherwise, this document does not update any other parts of
  [RFC2308].  The fact that a subtree does not exist is not forever:
  [RFC2308], section 3, already describes the amount of time that an
  NXDOMAIN response may be cached (the "negative TTL").

The shepherd wonders if this should be handled more efficiently.

As for the updating of RFC1034, This is in the Third Paragraph of Section 1:

  However, in most known existing resolvers today, a cached non-
  existence for a domain is not considered "proof" that there can be no
  child domains underneath.  This is due to an ambiguity in [RFC1034]
  that failed to distinguish Empty Non-Terminal names (ENT) ([RFC7719])
  from nonexistent names.  The distinction became especially important
  for the development of DNSSEC, which provides proof of non-existence.
  [RFC4035], section 3.1.3.2, describes how security-aware
  authoritative name servers make the distinction, but no existing RFCs
  describe the behavior for recursive name servers.

Again, the Shepherd wonders if this can be documented more efficiently.

2. Review and Consensus

This document was reviewed and discussed both in DNSOP, but also other DNS-releated mailing lists.  The topic of strongly defining what happens with a NXDOMAIN and below that, especially with root TLD servers. There was strong consensus to finally address outstanding issues in old standards.

3. Intellectual Property

There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References

There are no downward references

- IANA Considerations:

There are no IANA Considerations.

Checklist

X Does the shepherd stand behind the document and think the document is ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X Is the intent of the document accurately and adequately explained in the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?

X If this is a "bis" document, have all of the errata been considered?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-nxdomain-cut-03.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, draft-ietf-dnsop-nxdomain-cut@ietf.org, dnsop-chairs@ietf.org, joelja@gmail.com, "Tim Wicinski" , dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (NXDOMAIN really means there is nothing underneath) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'NXDOMAIN really means there is nothing underneath'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document states clearly that when a DNS resolver receives a
  response with response code of NXDOMAIN, it means that the domain
  name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

  REMOVE BEFORE PUBLICATION: this document should be discussed in the
  IETF DNSOP (DNS Operations) group, through its mailing list.  The
  source of the document, as well as a list of open issues, is
  currently kept at Github [1].

  This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it
  updates both of them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type: Proposed Standard

This document clearly states that when a DNS resolver receives the response code of NXDOMAIN, it means that the domain name queried AND ALL THE NAMES UNDER IT do not exist. Currently this is an ambitious area where behavior varies depending on implementation.

The document updates Section 5 of RFC2308, and attempts to clarify RFC1034

Proposed Standard was chosen as it updates existing Standards.

In the document, the section 2 ("Rules") replaces the second paragraph of section 5 of RFC2308.  The document includes this paragraph in section 2, though in the middle of the discussion reflecting this:

    These rules replace the second paragraph of section 5 of [RFC2308].
  Otherwise, this document does not update any other parts of
  [RFC2308].  The fact that a subtree does not exist is not forever:
  [RFC2308], section 3, already describes the amount of time that an
  NXDOMAIN response may be cached (the "negative TTL").

The shepherd wonders if this should be handled more efficiently.

As for the updating of RFC1034, This is in the Third Paragraph of Section 1:

  However, in most known existing resolvers today, a cached non-
  existence for a domain is not considered "proof" that there can be no
  child domains underneath.  This is due to an ambiguity in [RFC1034]
  that failed to distinguish Empty Non-Terminal names (ENT) ([RFC7719])
  from nonexistent names.  The distinction became especially important
  for the development of DNSSEC, which provides proof of non-existence.
  [RFC4035], section 3.1.3.2, describes how security-aware
  authoritative name servers make the distinction, but no existing RFCs
  describe the behavior for recursive name servers.

Again, the Shepherd wonders if this can be documented more efficiently.

2. Review and Consensus

This document was reviewed and discussed both in DNSOP, but also other DNS-releated mailing lists.  The topic of strongly defining what happens with a NXDOMAIN and below that, especially with root TLD servers. There was strong consensus to finally address outstanding issues in old standards.

3. Intellectual Property

There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References

There are no downward references

- IANA Considerations:

There are no IANA Considerations.

Checklist

X Does the shepherd stand behind the document and think the document is ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X Is the intent of the document accurately and adequately explained in the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?

X If this is a "bis" document, have all of the errata been considered?