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?