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 22.214.171.124, 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.
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?