draft-ietf-dnsop-nxdomain-cut-05.txt   rfc8020.txt 
Domain Name System Operations (dnsop) Working Group S. Bortzmeyer Internet Engineering Task Force (IETF) S. Bortzmeyer
Internet-Draft AFNIC Request for Comments: 8020 AFNIC
Updates: 1034, 2308 (if approved) S. Huque Updates: 1034, 2308 S. Huque
Intended status: Standards Track Verisign Labs Category: Standards Track Verisign Labs
Expires: March 22, 2017 September 18, 2016 ISSN: 2070-1721 November 2016
NXDOMAIN really means there is nothing underneath NXDOMAIN: There Really Is Nothing Underneath
draft-ietf-dnsop-nxdomain-cut-05
Abstract Abstract
This document states clearly that when a DNS resolver receives a This document states clearly that when a DNS resolver receives a
response with response code of NXDOMAIN, it means that the domain response with a response code of NXDOMAIN, it means that the domain
name which is thus denied AND ALL THE NAMES UNDER IT do not exist. name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
REMOVE BEFORE PUBLICATION: this document should be discussed in the This document clarifies RFC 1034 and modifies a portion of RFC 2308:
IETF DNSOP (DNS Operations) group, through its mailing list. The it updates both of them.
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 portion of RFC 2308,
so it updates both of them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 22, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8020.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and Background .....................................2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
2. Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rules ...........................................................3
3. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 5 3. Updates to RFCs .................................................5
3.1. Updates to RFC1034 . . . . . . . . . . . . . . . . . . . 5 3.1. Updates to RFC 1034 ........................................5
3.2. Updates to RFC2308 . . . . . . . . . . . . . . . . . . . 5 3.2. Updates to RFC 2308 ........................................5
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Benefits ........................................................5
5. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 6 5. Possible Issues .................................................6
6. Implementation considerations . . . . . . . . . . . . . . . . 6 6. Implementation Considerations ...................................6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations .........................................7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References ......................................................7
9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 8.1. Normative References .......................................7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References .....................................8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Why can't we just use the owner name of the returned
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 SOA? ...................................................9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix B. Related Approaches .....................................9
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments ....................................................9
Appendix A. Why can't we just use the owner name of the returned Authors' Addresses ................................................10
SOA? . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Related approaches . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and Background
The DNS protocol [RFC1035] defines response code 3 as "Name Error", The DNS protocol [RFC1035] defines response code 3 as "Name Error",
or "NXDOMAIN" [RFC2308], which means that the queried domain name or "NXDOMAIN" [RFC2308], which means that the queried domain name
does not exist in the DNS. Since domain names are represented as a does not exist in the DNS. Since domain names are represented as a
tree of labels ([RFC1034], Section 3.1), non-existence of a node tree of labels ([RFC1034], Section 3.1), nonexistence of a node
implies non-existence of the entire sub-tree rooted at this node. implies nonexistence of the entire subtree rooted at this node.
The DNS iterative resolution algorithm precisely interprets the The DNS iterative resolution algorithm precisely interprets the
NXDOMAIN signal in this manner. If it encounters an NXDOMAIN NXDOMAIN signal in this manner. If it encounters an NXDOMAIN
response code from an authoritative server, it immediately stops response code from an authoritative server, it immediately stops
iteration and returns the NXDOMAIN response to the querier. iteration and returns the NXDOMAIN response to the querier.
However, in most known existing resolvers today, a cached non- However, in most known existing resolvers today, a cached
existence for a domain is not considered "proof" that there can be no nonexistence for a domain is not considered "proof" that there can be
child domains underneath. This is due to an ambiguity in [RFC1034] no child domains underneath. This is due to an ambiguity in
that failed to distinguish Empty Non-Terminal names (ENT) ([RFC7719]) [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names
from nonexistent names (Section 3.1). The distinction became ([RFC7719]) from nonexistent names (Section 3.1). The distinction
especially important for the development of DNSSEC, which provides became especially important for the development of DNSSEC, which
proof of non-existence. [RFC4035], section 3.1.3.2, describes how provides proof of nonexistence. [RFC4035], Section 3.1.3.2,
security-aware authoritative name servers make the distinction, but describes how security-aware authoritative name servers make the
no existing RFCs describe the behavior for recursive name servers. distinction, but no existing RFCs describe the behavior for recursive
name servers.
This document specifies that an NXDOMAIN response for a domain name This document specifies that an NXDOMAIN response for a domain name
means that no child domains underneath the queried name exist either. means that no child domains underneath the queried name exist either;
And furthermore, that DNS resolvers should interpret cached non- furthermore, it means that DNS resolvers should interpret cached
existence in this manner. Since the domain names are organized in a nonexistence in this manner. Since the domain names are organized in
tree, it is a simple consequence of the tree structure: non-existence a tree, it is a simple consequence of the tree structure:
of a node implies non-existence of the entire sub-tree rooted at this nonexistence of a node implies nonexistence of the entire subtree
node. rooted at this node.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but,
because [RFC2308] provides a different definition, we repeat the
original one here: the QNAME is the domain name in the question
section.
"Denied name": the domain name whose existence has been denied by a "Denied name": the domain name whose existence has been denied by a
response of rcode NXDOMAIN. In most cases, it is the QNAME but, response RCODE of NXDOMAIN. In most cases, it is the QNAME but,
because of [RFC6604], it is not always the case. because of [RFC6604], it is not always the case.
Other terms are defined in [RFC1034] or [RFC1035] or (like NXDOMAIN Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN
itself) in the more recent [RFC7719]. itself) in the more recent [RFC7719].
The domain name space is conceptually defined in terms of a tree The domain name space is conceptually defined in terms of a tree
structure. The implementation of a DNS resolver/cache MAY use a tree structure. The implementation of a DNS resolver/cache MAY use a tree
or other data structures. The cache being a subset of the data in or other data structures. The cache being a subset of the data in
the domain name space, it is much easier to reason about it in terms the domain name space, it is much easier to reason about it in terms
of that tree structure and to describe things in those terms (names of that tree structure and to describe things in those terms (names
under/above, descendent names, subtrees etc). In fact, the DNS under/above, descendant names, subtrees, etc.). In fact, the DNS
algorithm description in [RFC1034] even states an assumption that the algorithm description in [RFC1034] even states an assumption that the
cache is a tree structure, so the precedent is already well cache is a tree structure, so the precedent is already well
established: see its section 4.3.2 which says "The following established: see its Section 4.3.2, which says "The following
algorithm assumes that the RRs are organized in several tree algorithm assumes that the RRs are organized in several tree
structures, one for each zone, and another for the cache..." So, in structures, one for each zone, and another for the cache..." So, in
this document, each time we talk of a tree or tree operations, it this document, each time we talk about a tree or tree operations,
refers to the model, not to the actual implementation. we're referring to the model, not to the actual implementation.
2. Rule 2. Rules
When an iterative caching DNS resolver receives a response NXDOMAIN, When an iterative caching DNS resolver receives an NXDOMAIN response,
it SHOULD store it in its cache and all names and RRsets at or below it SHOULD store it in its cache and then all names and resource
that node SHOULD then be considered to be unreachable. Subsequent record sets (RRsets) at or below that node SHOULD be considered
queries for such names SHOULD elicit an NXDOMAIN response. unreachable. Subsequent queries for such names SHOULD elicit an
NXDOMAIN response.
But if a resolver has cached data under the NXDOMAIN cut, it MAY 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 continue to send it as a reply (until the TTL of this cached data
expires), since this may avoid additional processing when a query is expires), since this may avoid additional processing when a query is
received. Section 6 provides more information about this. received. Section 6 provides more information about this.
Another exception is that a validating resolver MAY decide to Another exception is that a validating resolver MAY decide to
implement the "NXDOMAIN cut" behaviour (described in the first implement the "NXDOMAIN cut" behavior (described in the first
paragraph of this section) only when the NXDOMAIN response has been paragraph of this section) only when the NXDOMAIN response has been
validated with DNSSEC. See Section 8 for the rationale. validated with DNSSEC. See Section 7 for the rationale.
The fact that a subtree does not exist is not forever: [RFC2308], The fact that a subtree does not exist is not forever: [RFC2308],
section 3, already describes the amount of time that an NXDOMAIN Section 3, already describes the amount of time that an NXDOMAIN
response may be cached (the "negative TTL"). response may be cached (the "negative TTL").
If the NXDOMAIN response due to a cached non-existence is from a If the NXDOMAIN response due to a cached nonexistence is from a
DNSSEC signed zone, then it will have accompanying NSEC or NSEC3 DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3
records that authenticate the non-existence of the name. For a records that authenticate the nonexistence of the name. For a
descendant name of the original NXDOMAIN name, the same set of NSEC descendant name of the original NXDOMAIN name, the same set of NSEC
or NSEC3 records proves the non-existence of the descendant name. or NSEC3 records proves the nonexistence of the descendant name. The
The iterative, caching resolver MUST return these NSEC or NSEC3 iterative, caching resolver MUST return these NSEC or NSEC3 records
records in the response to the triggering query if the query had the in the response to the triggering query if the query had the DNSSEC
DNSSEC OK (DO) bit set. OK (DO) bit set.
Warning: if there is a chain of CNAME (or DNAME), the name which does Warning: if there is a chain of CNAME (or DNAME), the name that does
not exist is the last of the chain ([RFC6604]) and not the QNAME. not exist is the last of the chain ([RFC6604]) and not the QNAME.
The NXDOMAIN stored in the cache is for the denied name, not always The NXDOMAIN stored in the cache is for the denied name, not always
for the QNAME. for the QNAME.
As an example of the consequence of these rules, consider two As an example of the consequence of these rules, consider two
successive queries to a resolver, with a non-existing domain successive queries to a resolver with a nonexisting domain
'foo.example': the first is for 'foo.example' (which results in an 'foo.example': the first is for 'foo.example' (which results in an
NXDOMAIN) and the second for 'bar.foo.example' (which also results in NXDOMAIN) and the second for 'bar.foo.example' (which also results in
an NXDOMAIN). Many resolvers today will forward both queries, as an NXDOMAIN). Many resolvers today will forward both queries.
noticed in Section 9. However, following the rules in this document However, following the rules in this document ("NXDOMAIN cut"), a
("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, resolver would cache the first NXDOMAIN response, as a sign of
as a sign of non-existence, and then immediately return an NXDOMAIN nonexistence, and then immediately return an NXDOMAIN response for
response for the second query, without transmitting it to an the second query, without transmitting it to an authoritative server.
authoritative server.
If the first request is for 'bar.foo.example' and the second for If the first request is for 'bar.foo.example' and the second for
'baz.foo.example', the first NXDOMAIN response won't tell anything 'baz.foo.example', then the first NXDOMAIN response won't tell
about 'baz.foo.example' and therefore the second query will be anything about 'baz.foo.example'; therefore, the second query will be
transmitted as it was before the use of "NXDOMAIN cut" optimisation transmitted as it was before the use of "NXDOMAIN cut" optimization
(see Appendix A). (see Appendix A).
3. Updates to RFCs 3. Updates to RFCs
3.1. Updates to RFC1034 3.1. Updates to RFC 1034
This document clarifies possible ambiguities in [RFC1034] that did This document clarifies possible ambiguities in [RFC1034] that did
not clearly distinguish Empty Non-Terminal names (ENT) ([RFC7719]) not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])
from nonexistent names, and refers to subsequent documents that do. from nonexistent names, and it refers to subsequent documents that
Empty Non-Terminals are nodes in the DNS that have no resource record do. ENTs are nodes in the DNS that do not have resource record sets
sets associated with them, but have descendant nodes that do. The associated with them but have descendant nodes that do. The correct
correct response to Empty Non-Terminals is NODATA (i.e. a response response to ENTs is NODATA (i.e., a response code of NOERROR and an
code of NOERROR and an empty ANSWER section). Additional clarifying empty answer section). Additional clarifying language on these
language on these points is provided in section 7.16 of [RFC2136] and points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2
sections 2.2.2 and 2.2.3 of [RFC4592]. and 2.2.3 of [RFC4592].
3.2. Updates to RFC2308 3.2. Updates to RFC 2308
The second paragraph of section 5 of [RFC2308] states the following: The second paragraph of Section 5 in [RFC2308] states the following:
"A negative answer that resulted from a name error (NXDOMAIN) should
be cached such that it can be retrieved and returned in response to
another query for the same <QNAME, QCLASS> that resulted in the
cached negative response."
This document revises that paragraph to the following: "A negative A negative answer that resulted from a name error (NXDOMAIN)
answer that resulted from a name error (NXDOMAIN) should be cached should be cached such that it can be retrieved and returned in
such that it can be retrieved and returned in response to another response to another query for the same <QNAME, QCLASS> that
query for the same <QNAME, QCLASS> that resulted in the cached resulted in the cached negative response.
negative response, or where QNAME is a descendant of the original
QNAME, and QCLASS is the same."
The above section Section 2 elaborates on the revised rule and This document revises that paragraph to the following:
specifies when it may be reasonable to relax or ignore it.
A negative answer that resulted from a name error (NXDOMAIN)
should be cached such that it can be retrieved and returned in
response to another query for the same <QNAME, QCLASS> that
resulted in the cached negative response, or where the QNAME is a
descendant of the original QNAME and the QCLASS is the same.
Section 2 above elaborates on the revised rule and specifies when it
may be reasonable to relax or ignore it.
4. Benefits 4. Benefits
The main benefit is a better efficiency of the caches. In the The main benefit is a better efficiency of the caches. In the
example above, the resolver sends only one query instead of two, the example above, the resolver sends only one query instead of two, the
second one being answered from the cache. This will benefit the second one being answered from the cache. This will benefit the
entire DNS ecosystem, since the authoritative name servers will have entire DNS ecosystem, since the authoritative name servers will have
less unnecessary traffic to process. less unnecessary traffic to process.
The correct behavior (in [RFC1034] and made clearer in this document) The correct behavior (in [RFC1034] and made clearer in this document)
is specially useful when combined with QNAME minimisation [RFC7816] is especially useful when combined with QNAME minimization [RFC7816]
since it will allow a resolver to stop searching as soon as an since it will allow a resolver to stop searching as soon as an
NXDOMAIN is encountered. NXDOMAIN is encountered.
"NXDOMAIN cut" may also help mitigate certain types of random QNAME "NXDOMAIN cut" may also help mitigate certain types of random QNAME
attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is
fixed suffix which does not exist. In these attacks against the a fixed suffix that does not exist. In these attacks against the
authoritative name server, queries are sent to resolvers for a QNAME authoritative name server, queries are sent to resolvers for a QNAME
composed of a fixed suffix ("dafa888.wf" in one of the articles composed of a fixed suffix ("dafa888.wf" in one of the articles
above), which is typically nonexistent, and a random prefix, above), which is typically nonexistent, and a random prefix,
different for each request. A resolver receiving these requests have different for each request. A resolver receiving these requests has
to forward them to the authoritative servers. With "NXDOMAIN cut", a to forward them to the authoritative servers. With "NXDOMAIN cut", a
system administrator would just have to send to the resolver a query system administrator would just have to send to the resolver a query
for the fixed suffix, the resolver would get a NXDOMAIN and then for the fixed suffix, the resolver would get a NXDOMAIN and then
would stop forwarding the queries. (It would be better if the SOA would stop forwarding the queries. (It would be better if the SOA
record in the NXDOMAIN response were sufficient to find the non- record in the NXDOMAIN response were sufficient to find the
existing domain but it is not the case, see Appendix A.) nonexisting domain, but this is not the case, see Appendix A.)
5. Possible issues
Let's assume the TLD example exists but foobar.example is not 5. Possible Issues
delegated (so the example's name servers will reply NXDOMAIN for a
query about anything.foobar.example). A system administrator decides
to name the internal machines of his organization under
office.foobar.example and uses a trick of his resolver to forward
requests about this zone to his local authoritative name servers.
"NXDOMAIN cut" would create problems here, since, depending on the
order of requests to the resolver, it may have cached the non-
existence from example and therefore "deleted" everything under.
This document assumes that such setup is rare and does not need to be
supported.
Another issue that may happen: today, we see broken authoritative Let's assume that the Top-Level Domain (TLD) example exists, but
name servers which reply to ENT ([RFC7719], section 6) with NXDOMAIN foobar.example is not delegated (so the example's name servers will
instead of the normal NODATA ([RFC7719], section 3). reply NXDOMAIN for a query about anything.foobar.example). A system
administrator decides to name the internal machines of his
organization under office.foobar.example and uses a trick of his
resolver to forward requests about this zone to his local
authoritative name servers. "NXDOMAIN cut" would create problems
here; depending on the order of requests to the resolver, it may have
cached the nonexistence from example and therefore "deleted"
everything under it. This document assumes that such a setup is rare
and does not need to be supported.
RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example Today, another possible issue exists; we see authoritative name
today is mta2._domainkey.cbs.nl (which exists) where querying servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN
_domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu, instead of the normal NODATA ([RFC7719], Section 3).
redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu-
dscg.edgesuite.net returns NXDOMAIN.
Such name servers are definitely wrong and have always been. Their Such name servers are definitely wrong and have always been. Their
behaviour is incompatible with DNSSEC. Given the advantages of behaviour is incompatible with DNSSEC. Given the advantages of
"NXDOMAIN cut", there is little reason to support this behavior. "NXDOMAIN cut", there is little reason to support this behavior.
6. Implementation considerations 6. Implementation Considerations
This section is non-normative, and is composed only of various things This section is non-normative and is composed only of various things
which may be useful for implementors. A recursive resolver may that may be useful for implementors. A recursive resolver may
implement its cache in many ways. The most obvious one is a tree implement its cache in many ways. The most obvious one is a tree
data structure, because it fits the data model of domain names. But, data structure, because it fits the data model of domain names. But,
in practice, other implementations are possible, as well as various in practice, other implementations are possible, as well as various
optimisations (such as a tree, augmented by an index of some common optimizations (such as a tree, augmented by an index of some common
domain names). domain names).
If a resolver implements its cache as a tree (without any If a resolver implements its cache as a tree (without any
optimisation), one way to follow the rules of Section 2 is, when optimization), one way to follow the rules in Section 2 is as
receiving the NXDOMAIN, to prune the subtree of positive cache follows: when receiving the NXDOMAIN, prune the subtree of positive
entries at that node, or to delete all individual cache entries for cache entries at that node or delete all individual cache entries for
names below that node. Then, when searching downward in its cache, names below that node. Then, when searching downward in its cache,
this iterative caching DNS resolver will stop searching if it this iterative caching DNS resolver will stop searching if it
encounters a cached non-existence. encounters a cached nonexistence.
Some resolver may have a cache which is NOT organized as a tree (but,
for instance, as a dictionary) and therefore have a reason to ignore
the rules of Section 2. So these rules are a SHOULD and not a MUST.
7. IANA Considerations
This document has no actions for IANA. Some resolvers may have a cache that is NOT organized as a tree (but,
for instance, as a dictionary); therefore, they have a reason to
ignore the rules of Section 2. So these rules use SHOULD and not
MUST.
8. Security Considerations 7. Security Considerations
The technique described here may help against a denial-of-service The technique described in this document may help against a denial-
attack named "random qnames" and described in Section 4. of-service attack named "random qnames" described in Section 4.
If a resolver does not validate the answers with DNSSEC, or if the If a resolver does not validate the answers with DNSSEC, or if the
zone is not signed, the resolver can of course be poisoned with a zone is not signed, the resolver can of course be poisoned with a
false NXDOMAIN, thus "deleting" a part of the domain name tree. This false NXDOMAIN, thus, "deleting" a part of the domain name tree.
denial-of-service attack is already possible without the rules of This denial-of-service attack is already possible without the rules
this document (but "NXDOMAIN cut" may increase its effects). The of this document (but "NXDOMAIN cut" may increase its effects). The
only solution is to use DNSSEC. only solution is to use DNSSEC.
9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 8. References
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
As of today, practically all existing DNS resolvers are conservative
by default: they consider a NXDOMAIN as only significant for the
denied name itself, not for the names under. Almost all the current
recursive servers will send upstream a query for out-of-cache
sub.example.com even if their cache contains an NXDOMAIN for
example.com.
There are a few exceptions. The Unbound resolver has a configuration
parameter called "harden-below-nxdomain" [2], which if set to "yes"
turns on "NXDOMAIN cut" behavior ("only DNSSEC-secure nxdomains are
used", see Section 8). The PowerDNS recursor has optional partial
support for "NXDOMAIN cut", for the root domain only, with its "root-
nx-trust" setting, described as [3] "If set, an NXDOMAIN from the
root-servers will serve as a blanket NXDOMAIN for the entire TLD the
query belonged to. The effect of this is far fewer queries to the
root-servers.".
10. Acknowledgments
The main idea is in this document is taken from
[I-D.vixie-dnsext-resimprove], section 3, "Stopping Downward Cache
Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney
Joffe, and Frederico Neves. Additionally Tony Finch, Ted Lemon, John
Levine, Jinmei Tatuya, Bob Harold and Duane Wessels provided valuable
feedback and suggestions.
11. References
11.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 9, line 22 skipping to change at page 8, line 17
<http://www.rfc-editor.org/info/rfc2308>. <http://www.rfc-editor.org/info/rfc2308>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006, System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<http://www.rfc-editor.org/info/rfc4592>. <http://www.rfc-editor.org/info/rfc4592>.
[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits
Clarification", RFC 6604, DOI 10.17487/RFC6604, April Clarification", RFC 6604, DOI 10.17487/RFC6604, April
2012, <http://www.rfc-editor.org/info/rfc6604>. 2012, <http://www.rfc-editor.org/info/rfc6604>.
11.2. Informative References 8.2. Informative References
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <http://www.rfc-editor.org/info/rfc4035>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<http://www.rfc-editor.org/info/rfc7816>. <http://www.rfc-editor.org/info/rfc7816>.
[I-D.vixie-dnsext-resimprove] [DNSRRR] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
Resolvers for Resiliency, Robustness, and Responsiveness", Resolvers for Resiliency, Robustness, and Responsiveness",
draft-vixie-dnsext-resimprove-00 (work in progress), June Work in Progress, draft-vixie-dnsext-resimprove-00, June
2010. 2010.
[I-D.ietf-dnsop-nsec-aggressiveuse] [NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-
NSEC/NSEC3", draft-ietf-dnsop-nsec-aggressiveuse-02 (work aggressiveuse-04, September 2016.
in progress), September 2016.
[joost-dnsterror] [joost-dnsterror]
Joost, M., "About DNS Attacks and ICMP Destination Joost, M., "About DNS Attacks and ICMP Destination
Unreachable Reports", December 2014, Unreachable Reports", December 2014,
<http://www.michael-joost.de/dnsterror.html>. <http://www.michael-joost.de/dnsterror.html>.
[balakrichenan-dafa888] [balakrichenan-dafa888]
Balakrichenan, S., "Disturbance in the DNS - "Random Balakrichenan, S., "Disturbance in the DNS - "Random
qnames", the dafa888 DoS attack"", October 2014, qnames", the dafa888 DoS attack"", October 2014,
<https://indico.dns-oarc.net/event/20/session/3/ <https://indico.dns-oarc.net/event/20/session/3/
contribution/37>. contribution/3>.
11.3. URIs
[1] https://github.com/bortzmeyer/ietf-dnsop-nxdomain
[2] https://www.unbound.net/documentation/unbound.conf.html
[3] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust
Appendix A. Why can't we just use the owner name of the returned SOA? Appendix A. Why can't we just use the owner name of the returned SOA?
In this document, we deduce the non-existence of a domain only for In this document, we deduce the nonexistence of a domain only for
NXDOMAIN answers where the denied name was the exact domain. If a NXDOMAIN answers where the denied name was the exact domain. If a
resolver sends a query to the name servers of the TLD example, asking resolver sends a query to the name servers of the TLD example, asking
for the MX record for www.foobar.example, and subsequently receives a for the mail exchange (MX) record for www.foobar.example, and
NXDOMAIN, it can only register the fact that www.foobar.example (and subsequently receives a NXDOMAIN, it can only register the fact that
everything underneath) does not exist. This is true regardless if www.foobar.example (and everything underneath) does not exist. This
the accompanying SOA record is for the domain example only. One is true regardless of whether or not the accompanying SOA record is
cannot infer that foobar.example is nonexistent. The accompanying for the domain example only. One cannot infer that foobar.example is
SOA record indicates the apex of the zone, not the closest existing nonexistent. The accompanying SOA record indicates the apex of the
domain name. So, using the owner name of the SOA record in the zone, not the closest existing domain name. So, using the owner name
Authoritative section to deduce "NXDOMAIN cuts" is currently of the SOA record in the authority section to deduce "NXDOMAIN cuts"
definitely not OK. is currently definitely not OK.
RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today,
ask the authoritative name servers of the TLD fr about
anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the
apex) even while gouv.fr does exist (there is no zone cut between
gouv.fr and fr).
Deducing the non-existence of a node from the SOA in the NXDOMAIN Deducing the nonexistence of a node from the SOA in the NXDOMAIN
reply may certainly help with random qnames attacks but this is out- reply may certainly help with random qnames attacks, but this is out-
of-scope for this document. It would require to address the problems of-scope for this document. It would require addressing the problems
mentioned in the first paragraph of this section. A possible mentioned in the first paragraph of this section. A possible
solution would be, when receiving a NXDOMAIN with a SOA which is more solution is, when receiving a NXDOMAIN with a SOA that is more than
than one label up in the tree, to send requests for the domains which one label up in the tree, to send requests for the domains that are
are between the QNAME and the owner name of the SOA. (A resolver between the QNAME and the owner name of the SOA. (A resolver that
which does DNSSEC validation or QNAME minimisation will need to do does DNSSEC validation or QNAME minimization will need to do it
it, anyway.) anyway.)
Appendix B. Related approaches Appendix B. Related Approaches
The document [I-D.ietf-dnsop-nsec-aggressiveuse] describes another The document [NSEC] describes another way to address some of the same
way to address some of the same concerns (decreasing the traffic for concerns (decreasing the traffic for nonexisting domain names).
non-existing domain names). Unlike "NXDOMAIN cut", it requires Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful
DNSSEC but it is more powerful since it can synthesize NXDOMAINs for since it can synthesize NXDOMAINs for domains that were not queried.
domains that were not queried.
Acknowledgments
The main idea in this document is taken from [DNSRRR], Section 3,
"Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors,
Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony
Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane
Wessels provided valuable feedback and suggestions.
Authors' Addresses Authors' Addresses
Stephane Bortzmeyer Stephane Bortzmeyer
AFNIC AFNIC
1, rue Stephenson 1, rue Stephenson
Montigny-le-Bretonneux 78180 Montigny-le-Bretonneux 78180
France France
Phone: +33 1 39 30 83 46 Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr Email: bortzmeyer+ietf@nic.fr
URI: http://www.afnic.fr/ URI: https://www.afnic.fr/
Shumon Huque Shumon Huque
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston 20190 Reston, VA 20190
USA United States of America
Email: shuque@verisign.com Email: shuque@verisign.com
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
 End of changes. 68 change blocks. 
276 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/