draft-ietf-dnsop-nxdomain-cut-04.txt   draft-ietf-dnsop-nxdomain-cut-05.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: January 19, 2017 July 18, 2016 Expires: March 22, 2017 September 18, 2016
NXDOMAIN really means there is nothing underneath NXDOMAIN really means there is nothing underneath
draft-ietf-dnsop-nxdomain-cut-04 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 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
currently kept at Github [1]. currently kept at Github [1].
This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it This documents clarifies RFC 1034 and modifies a portion of RFC 2308,
updates both of them. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 19, 2017. This Internet-Draft will expire on March 22, 2017.
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. Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Updates to RFC1034 . . . . . . . . . . . . . . . . . . . 5 3.1. Updates to RFC1034 . . . . . . . . . . . . . . . . . . . 5
3.2. Updates to RFC2308 . . . . . . . . . . . . . . . . . . . 5 3.2. Updates to RFC2308 . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 4, line 6 skipping to change at page 4, line 6
refers to the model, not to the actual implementation. refers to the model, not to the actual implementation.
2. Rule 2. Rule
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.
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.) expires), since this may avoid additional processing when a query is
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 this behaviour only when the NXDOMAIN response has been implement the "NXDOMAIN cut" behaviour (described in the first
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 8 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 non-existence 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 non-existence 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
skipping to change at page 8, line 47 skipping to change at page 8, line 47
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <http://www.rfc-editor.org/info/rfc2136>.
[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>.
skipping to change at page 9, line 30 skipping to change at page 9, line 30
2012, <http://www.rfc-editor.org/info/rfc6604>. 2012, <http://www.rfc-editor.org/info/rfc6604>.
11.2. Informative References 11.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 [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] [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.fujiwara-dnsop-nsec-aggressiveuse] [I-D.ietf-dnsop-nsec-aggressiveuse]
Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
draft-fujiwara-dnsop-nsec-aggressiveuse-03 (work in NSEC/NSEC3", draft-ietf-dnsop-nsec-aggressiveuse-02 (work
progress), March 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/37>.
11.3. URIs 11.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 the 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, asking
asks the MX record for www.foobar.example, and receives a NXDOMAIN, for the MX record for www.foobar.example, and subsequently receives a
it can only register the fact that www.foobar.example (and everything NXDOMAIN, it can only register the fact that www.foobar.example (and
underneath) does not exist. Even if the accompanying SOA record is everything underneath) does not exist. This is true regardless if
for example only, one cannot infer that foobar.example is the accompanying SOA record is for the domain example only. One
nonexistent. The accompanying SOA indicates the apex of the zone, cannot infer that foobar.example is nonexistent. The accompanying
not the closest existing domain name. SOA record indicates the apex of the zone, not the closest existing
domain name. So, using the owner name of the SOA record in the
Authoritative section to deduce "NXDOMAIN cuts" is currently
definitely not OK.
RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today,
ask the authoritative name servers of the TLD fr about ask the authoritative name servers of the TLD fr about
anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the 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 apex) even while gouv.fr does exist (there is no zone cut between
gouv.fr and fr). gouv.fr and fr).
Deducing the non-existence of a node from the SOA in the NXDOMAIN Deducing the non-existence 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 to address 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 would be, when receiving a NXDOMAIN with a SOA which is more
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.ietf-dnsop-nsec-aggressiveuse] describes another
another way to address some of the same concerns (decreasing the way to address some of the same concerns (decreasing the traffic for
traffic for non-existing domain names). Unlike "NXDOMAIN cut", it non-existing domain names). Unlike "NXDOMAIN cut", it requires
requires DNSSEC but it is more powerful since it can synthesize DNSSEC but it is more powerful since it can synthesize NXDOMAINs for
NXDOMAINs for domains that were not queried. 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
Phone: +33 1 39 30 83 46 Phone: +33 1 39 30 83 46
 End of changes. 14 change blocks. 
32 lines changed or deleted 39 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/