draft-ietf-dnsop-nxdomain-cut-02.txt   draft-ietf-dnsop-nxdomain-cut-03.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: October 9, 2016 April 7, 2016 Expires: November 9, 2016 May 8, 2016
NXDOMAIN really means there is nothing underneath NXDOMAIN really means there is nothing underneath
draft-ietf-dnsop-nxdomain-cut-02 draft-ietf-dnsop-nxdomain-cut-03
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 October 9, 2016. This Internet-Draft will expire on November 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 4, line 27 skipping to change at page 4, line 27
an NXDOMAIN). Many resolvers today will forward both queries, as an NXDOMAIN). Many resolvers today will forward both queries, as
noticed in Section 8. However, following the rules in this document noticed in Section 8. However, following the rules in this document
("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, ("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response,
as a sign of non-existence, and then immediately return an NXDOMAIN as a sign of non-existence, and then immediately return an NXDOMAIN
response for the second query, without transmitting it to an response for 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', 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 the use of "NXDOMAIN cut" optimisation
(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
NXDOMAIN response may be cached (the "negative TTL"). NXDOMAIN 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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
DNSSEC OK (DO) bit set. DNSSEC 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 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 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 specially useful when combined with QNAME minimisation [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] [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
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 non-
existing domain but it is not the case, see Appendix A.) existing domain but it is not the case, see Appendix A.)
4. Possible issues 4. Possible issues
Let's assume the TLD example exists but foobar.example is not Let's assume the TLD example exists but foobar.example is not
delegated (so the example's name servers will reply NXDOMAIN for a delegated (so the example's name servers will reply NXDOMAIN for a
query about anything.foobar.example). A system administrator decides query about anything.foobar.example). A system administrator decides
to name the internal machines of his organization under to name the internal machines of his organization under
office.foobar.example and uses a trick of his resolver to forward office.foobar.example and uses a trick of his resolver to forward
requests about this zone to his local authoritative name servers. requests about this zone to his local authoritative name servers.
NXDOMAIN cut would create problems here, since, depending on the "NXDOMAIN cut" would create problems here, since, depending on the
order of requests to the resolver, it may have cached the non- order of requests to the resolver, it may have cached the non-
existence from example and therefore "deleted" everything under. existence from example and therefore "deleted" everything under.
This document assumes that such setup is rare and does not need to be This document assumes that such setup is rare and does not need to be
supported. supported.
Another issue that may happen: today, we see broken authoritative Another issue that may happen: today, we see broken authoritative
name servers which reply to ENT ([RFC7719], section 6) with NXDOMAIN name servers which reply to ENT ([RFC7719], section 6) with NXDOMAIN
instead of the normal NODATA ([RFC7719], section 3). instead of the normal NODATA ([RFC7719], section 3).
RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example
today is mta2._domainkey.cbs.nl (which exists) where querying today is mta2._domainkey.cbs.nl (which exists) where querying
_domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu, _domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu,
redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu- redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu-
dscg.edgesuite.net returns NXDOMAIN. 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 cuts, there is little reason to support this behavior. "NXDOMAIN cut", there is little reason to support this behavior.
5. Implementation considerations 5. 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 which 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 optimisations (such as a tree, augmented by an index of some common
domain names). domain names).
skipping to change at page 7, line 28 skipping to change at page 7, line 28
exist. exist.
According to [RFC6982], "this will allow reviewers and working groups According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
As of today, practically all existing DNS resolvers are conservative As of today, practically all existing DNS resolvers are conservative
by default: they consider a NXDOMAIN as only significant for the name by default: they consider a NXDOMAIN as only significant for the
itself, not for the names under. Almost all the current recursive denied name itself, not for the names under. Almost all the current
servers will send upstream a query for out-of-cache sub.example.com recursive servers will send upstream a query for out-of-cache
even if their cache contains an NXDOMAIN for example.com. sub.example.com even if their cache contains an NXDOMAIN for
example.com.
There are a few exceptions. The Unbound resolver has a configuration There are a few exceptions. The Unbound resolver has a configuration
parameter called "harden-below-nxdomain" [2], which if set to "yes" parameter called "harden-below-nxdomain" [2], which if set to "yes"
turns on NXDOMAIN cut behavior ("only DNSSEC-secure nxdomains are turns on "NXDOMAIN cut" behavior ("only DNSSEC-secure nxdomains are
used", see Section 7). The PowerDNS recursor has optional partial used", see Section 7). The PowerDNS recursor has optional partial
support for NXDOMAIN cut, for the root domain only, with its "root- support for "NXDOMAIN cut", for the root domain only, with its "root-
nx-trust" setting, described as [3] "If set, an NXDOMAIN from the 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 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 query belonged to. The effect of this is far fewer queries to the
root-servers.". root-servers.".
9. Acknowledgments 9. Acknowledgments
The main idea is in this document is taken from The main idea is in this document is taken from
[I-D.vixie-dnsext-resimprove], section 3, "Stopping Downward Cache [I-D.vixie-dnsext-resimprove], section 3, "Stopping Downward Cache
Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney
Joffe, and Frederico Neves. Additionally Tony Finch, John Levine, Joffe, and Frederico Neves. Additionally Tony Finch, John Levine,
Jinmei Tatuya, and Duane Wessels provided valuable feedback and Jinmei Tatuya, Bob Harold and Duane Wessels provided valuable
suggestions. feedback and suggestions.
10. References 10. References
10.1. Normative References 10.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
skipping to change at page 10, line 19 skipping to change at page 10, line 19
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.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 synthesize 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. 15 change blocks. 
19 lines changed or deleted 21 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/