draft-ietf-dnsop-nxdomain-cut-01.txt   draft-ietf-dnsop-nxdomain-cut-02.txt 
Domain Name System Operations (dnsop) Working Group S. Bortzmeyer Domain Name System Operations (dnsop) Working Group S. Bortzmeyer
Internet-Draft AFNIC Internet-Draft AFNIC
Updates: 1034,2308 (if approved) S. Huque Updates: 1034,2308 (if approved) S. Huque
Intended status: Standards Track Verisign Labs Intended status: Standards Track Verisign Labs
Expires: September 11, 2016 March 10, 2016 Expires: October 9, 2016 April 7, 2016
NXDOMAIN really means there is nothing underneath NXDOMAIN really means there is nothing underneath
draft-ietf-dnsop-nxdomain-cut-01 draft-ietf-dnsop-nxdomain-cut-02
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 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 REMOVE BEFORE PUBLICATION: this document should be discussed in the
IETF DNSOP (DNS Operations) group, through its mailing list. The IETF DNSOP (DNS Operations) group, through its mailing list. The
source of the document, as well as a list of open issues, is source of the document, as well as a list of open issues, is
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2016. This Internet-Draft will expire on October 9, 2016.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 5 4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation considerations . . . . . . . . . . . . . . . . 5 5. Implementation considerations . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Why can't we just use the owner name of the returned Appendix A. Why can't we just use the owner name of the returned
SOA? . . . . . . . . . . . . . . . . . . . . . . . . 9 SOA? . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Related approaches . . . . . . . . . . . . . . . . . 9 Appendix B. Related approaches . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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), non-existence of a node
implies non-existence of the entire sub-tree rooted at this node. implies non-existence of the entire sub-tree rooted at this node.
The DNS iterative resolution algorithm precisely interprets the The DNS iterative resolution algorithm precisely interprets the
skipping to change at page 3, line 30 skipping to change at page 3, line 30
"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].
"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 of rcode 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] or [RFC1035] or (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
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
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
under/above, descendent names, subtrees etc). In fact, the DNS
algorithm description in [RFC1034] even states an assumption that the
cache is a tree structure, so the precedent is already well
established: see its section 4.3.2 which says "The following
algorithm assumes that the RRs are organized in several tree
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
refers to the model, not to the actual implementation.
2. Rules 2. Rules
When an iterative caching DNS resolver receives a response NXDOMAIN, When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and all names and RRsets at or below it SHOULD store it in its cache and all names and RRsets at or below
that node SHOULD then be considered to be unreachable. Subsequent that node SHOULD then be considered to be unreachable. Subsequent
queries for such names SHOULD elicit an NXDOMAIN response. queries for such names SHOULD elicit an NXDOMAIN response.
[TODO: currently under discussion, some people find it dangerous. But if a resolver has cached data under the NXDOMAIN cut, it MAY
Only if the NXDOMAIN is DNSSEC-validated? Perhaps the resolver could continue to send it as a reply. (Until the TTL of this cached data
be configured to not apply this rule to TLDs (or root). See expires.)
Section 7.]
For example, consider two successive queries to a resolver, with a Another exception is that a validating resolver MAY decide to
non-existing domain 'foo.example': the first is for 'foo.example' implement this behaviour only when the NXDOMAIN response has been
(which results in an NXDOMAIN) and the second for 'bar.foo.example' validated with DNSSEC. See Section 7 for the rationale.
(which also results in an NXDOMAIN). Many resolvers today will
forward both queries, as noticed in Section 8. However, following As an example of the consequence of these rules, consider two
the rules in this document ("NXDOMAIN cut"), a resolver would cache successive queries to a resolver, with a non-existing domain
the first NXDOMAIN response, as a sign of non-existence, and then 'foo.example': the first is for 'foo.example' (which results in an
immediately return an NXDOMAIN response for the second query, without NXDOMAIN) and the second for 'bar.foo.example' (which also results in
transmitting it to an authoritative server. an NXDOMAIN). Many resolvers today will forward both queries, as
noticed in Section 8. However, following the rules in this document
("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response,
as a sign of non-existence, and then immediately return an NXDOMAIN
response for the second query, without transmitting it to an
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', the first NXDOMAIN response won't tell anything
about 'baz.foo.example' and therefore the second query will be about 'baz.foo.example' and therefore the second query will be
transmitted as it was before "NXDOMAIN cut" (see Appendix A). transmitted as it was before "NXDOMAIN cut" (see Appendix A).
These rules replace the second paragraph of section 5 of [RFC2308]. These rules replace the second paragraph of section 5 of [RFC2308].
Otherwise, this document does not update any other parts of Otherwise, this document does not update any other parts of
[RFC2308]. 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 [RFC2308], section 3, already describes the amount of time that an
skipping to change at page 4, line 34 skipping to change at page 5, line 9
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 which 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.
3. Benefits 3. 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 send only one query instead of two, the example above, the resolver send only one query instead of two, the
second one being answered from the cache. second one being answered from the cache. This will benefit the
entire DNS ecosystem, since the authoritative name servers will have
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 is specially useful when combined with QNAME minimisation [RFC7816]
[I-D.ietf-dnsop-qname-minimisation] since it will allow a resolver to since it will allow a resolver to stop searching as soon as an
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] [balakrichenan-dafa888], where there is a
fixed suffix which does not exist. In these attacks against the fixed suffix which 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 have
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
skipping to change at page 6, line 16 skipping to change at page 6, line 40
for instance, as a dictionary) and therefore have a reason to ignore 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. the rules of Section 2. So these rules are a SHOULD and not a MUST.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Security Considerations 7. Security Considerations
The technique described here may help against a denial-of-service The technique described here may help against a denial-of-service
attack named "random qnames" and described in Section 3. Apart from attack named "random qnames" and described in Section 3.
that, it is believed to have no security consequences.
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. This
denial-of-service attack is already possible without the rules of denial-of-service attack is already possible without the rules of
this document (but "NXDOMAIN cut" may increase its effects). The this document (but "NXDOMAIN cut" may increase its effects). The
only solution is to use DNSSEC. only solution is to use DNSSEC.
8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
skipping to change at page 7, line 37 skipping to change at page 8, line 18
[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
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>. <http://www.rfc-editor.org/info/rfc2308>.
[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>.
10.2. Informative References 10.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 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, DOI Code: The Implementation Status Section", RFC 6982,
10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <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
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<http://www.rfc-editor.org/info/rfc7816>.
[I-D.vixie-dnsext-resimprove] [I-D.vixie-dnsext-resimprove]
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 draft-vixie-dnsext-resimprove-00 (work in progress), June
2010. 2010.
[I-D.ietf-dnsop-qname-minimisation]
Bortzmeyer, S., "DNS query name minimisation to improve
privacy", draft-ietf-dnsop-qname-minimisation-09 (work in
progress), January 2016.
[I-D.fujiwara-dnsop-nsec-aggressiveuse] [I-D.fujiwara-dnsop-nsec-aggressiveuse]
Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
draft-fujiwara-dnsop-nsec-aggressiveuse-02 (work in draft-fujiwara-dnsop-nsec-aggressiveuse-03 (work in
progress), October 2015. progress), March 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/37>.
10.3. URIs 10.3. URIs
[1] https://www.unbound.net/documentation/unbound.conf.html [1] https://github.com/bortzmeyer/ietf-dnsop-nxdomain
[2] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust [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 non-existence of a domain only for
NXDOMAIN answers where the denied name was this exact domain. If a NXDOMAIN answers where the denied name was this exact domain. If a
resolver sends a query to the name servers of the TLD example, and resolver sends a query to the name servers of the TLD example, and
asks the MX record for www.foobar.example, and receives a NXDOMAIN, asks the MX record for www.foobar.example, and receives a NXDOMAIN,
it can only register the fact that www.foobar.example (and everything it can only register the fact that www.foobar.example (and everything
underneath) does not exist. Even if the accompanying SOA record is underneath) does not exist. Even if the accompanying SOA record is
for example only, one cannot infer that foobar.example is for example only, one cannot infer that foobar.example is
skipping to change at page 9, line 38 skipping to change at page 10, line 20
than one label up in the tree, to send requests for the domains which than one label up in the tree, to send requests for the domains which
are between the QNAME and the owner name of the SOA. (A resolver are between the QNAME and the owner name of the SOA. (A resolver
which does DNSSEC validation or QNAME minimisation will need to do which does DNSSEC validation or QNAME minimisation will need to do
it, anyway.) it, anyway.)
Appendix B. Related approaches Appendix B. Related approaches
The document [I-D.fujiwara-dnsop-nsec-aggressiveuse] describes The document [I-D.fujiwara-dnsop-nsec-aggressiveuse] describes
another way to address some of the same concerns (decreasing the another way to address some of the same concerns (decreasing the
traffic for non-existing domain names). Unlike NXDOMAIN cut, it traffic for non-existing domain names). Unlike NXDOMAIN cut, it
requires DNSSEC but it is more powerful since it can synthetize requires DNSSEC but it is more powerful since it can synthesize
NXDOMAINs for domains that were not queried. NXDOMAINs for domains that were not queried.
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
 End of changes. 23 change blocks. 
44 lines changed or deleted 64 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/