One document matched: draft-ietf-dnsop-nxdomain-cut-03.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2308 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY rfc4033 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4035 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5936 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5936.xml">
<!ENTITY rfc6347 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY rfc6604 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6604.xml">
<!ENTITY rfc6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY rfc6982 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml">
<!ENTITY rfc7626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7626.xml">
<!ENTITY rfc7719 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7719.xml">
<!ENTITY rfc7816 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7816.xml">
<!ENTITY I-D.vixie-dnsext-resimprove SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vixie-dnsext-resimprove.xml">
<!ENTITY I-D.fujiwara-dnsop-nsec-aggressiveuse SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.fujiwara-dnsop-nsec-aggressiveuse.xml">
]>

<rfc docName="draft-ietf-dnsop-nxdomain-cut-03"
     category="std" ipr="trust200902" updates="1034, 2308">
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<front>
<title abbrev="NXDOMAIN cut">NXDOMAIN really means there is nothing underneath</title>
<author fullname="Stephane Bortzmeyer" initials="S." surname="Bortzmeyer">
<organization>AFNIC</organization>
<address><postal><street>1, rue Stephenson</street><code>78180</code><city>Montigny-le-Bretonneux</city><country>France</country></postal> <phone>+33 1 39 30 83 46</phone><email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
</author>
<author fullname="Shumon Huque" initials="S." surname="Huque">
<organization>Verisign Labs</organization>
<address><postal><street>12061 Bluemont Way</street><code>20190</code><city>Reston</city><country>USA</country></postal> <email>shuque@verisign.com</email><uri>http://www.verisignlabs.com/</uri></address>
</author>
<date month="May" year="2016"/>
<workgroup>Domain Name System Operations (dnsop) Working Group</workgroup>
<abstract>
<t>This document states clearly that when a DNS resolver receives a
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.</t>
<t>REMOVE BEFORE PUBLICATION: this document should be discussed in the
IETF DNSOP (DNS Operations) group, through its mailing list. The
source of the document, as well as a list of open issues, is currently
kept <eref
target="https://github.com/bortzmeyer/ietf-dnsop-nxdomain">at
Github</eref>.</t>
<t>This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it
updates both of them.</t>
</abstract>
</front>

<middle>
  <section anchor="intro" title="Introduction and background">
    <t>
      The DNS protocol <xref target="RFC1035"/> defines response code 
      3 as "Name Error", or "NXDOMAIN" <xref target="RFC2308"/>, which means that the queried domain name
      does not exist in the DNS. Since domain names are represented as
      a tree of labels (<xref target="RFC1034"/>, Section 3.1),
      non-existence of a node implies non-existence of the entire sub-tree 
      rooted at this node.
    </t>
    <t>
      The DNS iterative resolution algorithm precisely interprets the
      NXDOMAIN signal in this manner. If it encounters an NXDOMAIN
      response code from an authoritative server, it immediately stops
      iteration and returns the NXDOMAIN response to the querier.
    </t>
    <t>However, in most known existing resolvers today, a cached
    non-existence for a domain
    is not considered "proof" that there can be no child domains
    underneath. This is due to an ambiguity in <xref
    target="RFC1034"/> that failed to distinguish Empty Non-Terminal
    names (ENT)  (<xref target="RFC7719"/>) from nonexistent names.
    The distinction became especially important for the development of DNSSEC,
    which provides proof of non-existence. <xref
    target="RFC4035"/>, section 3.1.3.2, describes
    how security-aware authoritative name servers make the distinction, but no 
    existing RFCs describe the behavior for recursive name servers.</t>
    <t>
      This document specifies that an NXDOMAIN response for a domain
      name means that no child domains underneath the queried name
      exist either.  And furthermore, that DNS resolvers should
      interpret cached non-existence in this manner. Since the
      domain names are organized in a tree, it is a simple consequence
      of the tree structure: non-existence of a node implies
      non-existence of the entire sub-tree rooted at this node.</t>
      <section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref
   target="RFC2119"/>.</t>
   <t>"Denied name": the domain name whose existence has been denied
   by a response of rcode NXDOMAIN. In most cases, it is the QNAME
   but, because of <xref target="RFC6604"/>, it is not always the
   case.</t>
   <t>Other terms are defined in <xref target="RFC1034"/> or <xref
   target="RFC1035"/> or (like NXDOMAIN itself) in the more recent
   <xref target="RFC7719"/>.</t>
   <t>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 <xref target="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.</t>
      </section>
  </section>

<section anchor="rules" title="Rules">

<t>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 that node SHOULD then be considered to be
unreachable. Subsequent queries for such names SHOULD elicit an
NXDOMAIN response.</t>
<t>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 expires.)<!-- https://mailarchive.ietf.org/arch/msg/dnsop/k7jhPJ1IyPJEq84CpWxlRMAnfxw --></t>
<t>Another exception is that a validating resolver MAY decide to implement this behaviour only when the
NXDOMAIN response has been validated with DNSSEC. See <xref
target="security"/> for the rationale.</t>
<t>As an example of the consequence of these rules, consider two successive queries to a resolver, with a
non-existing domain 'foo.example': the first is for 'foo.example'
(which results in an NXDOMAIN) and the second for 'bar.foo.example' (which
also results in an NXDOMAIN).  Many resolvers today will forward both
queries, as noticed in <xref target="impl"/>.  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.</t>
<t>If the first request is for 'bar.foo.example' and the second for
'baz.foo.example', the first NXDOMAIN response won't tell anything
about 'baz.foo.example' and therefore the second query will be
transmitted as it was before the use of "NXDOMAIN cut" optimisation (see <xref target="future"/>).</t>
<t>These rules replace the second paragraph of section 5 of <xref
target="RFC2308"/>. Otherwise, this document does not update any other parts of <xref
target="RFC2308"/>. The fact that a subtree does
not exist is not forever: <xref
target="RFC2308"/>, section 3, already describes the
amount of time
that an NXDOMAIN response may be cached (the "negative TTL").</t>
<t>If the NXDOMAIN response due to a cached non-existence is from a DNSSEC signed zone, then
it will have accompanying NSEC or NSEC3 records that authenticate the
non-existence of the name. For a descendant name of the original
NXDOMAIN name, the same set of NSEC or NSEC3 records proves the
non-existence of the descendant name. The iterative, caching resolver
MUST return these NSEC or NSEC3 records in the response to the
triggering query if the query had the DNSSEC OK (DO) bit set.
</t>
<t>Warning: if there is a chain of
CNAME (or DNAME), the name which does not exist is the last of the
chain (<xref target="RFC6604"/>) and not the QNAME. The NXDOMAIN
stored in the cache is for the denied name, not always for the QNAME.</t>
</section>

<section anchor="benefits" title="Benefits">
  <t>The main benefit is a better efficiency of the caches. In the
  example above, the resolver sends only one query instead of two, the 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.</t>
  <t>The correct behavior (in <xref target="RFC1034"/> and made
  clearer in this document) is specially useful when combined with QNAME
  minimisation <xref
  target="RFC7816"/> since it will allow a
  resolver to stop searching as soon as an NXDOMAIN is encountered.</t>
  <t>"NXDOMAIN cut" may also help mitigate certain types of random QNAME attacks <xref
  target="joost-dnsterror"/> <xref
  target="balakrichenan-dafa888"/>, where there is a fixed suffix which
  does not exist. In these attacks against the authoritative name
  server, queries are sent to resolvers for a QNAME composed 
  of a fixed suffix ("dafa888.wf" in one of the articles above), which is 
  typically nonexistent, and a random prefix, different for each request. A
  resolver receiving these requests have to forward them to the
  authoritative servers. With "NXDOMAIN cut", a system administrator would just have to send
  to the resolver a query for the fixed suffix, the resolver would get
  a NXDOMAIN and then would stop forwarding the queries. (It would be
  better if the SOA record in the NXDOMAIN response were sufficient to
  find the non-existing domain but it is not the case, see 
  <xref target="future"/>.)</t>
</section>

<section title="Possible issues">
  <t>Let's assume the TLD example exists but foobar.example is not
  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.</t>
<t>Another issue that may happen: today, we see broken authoritative name servers which reply to ENT
(<xref target="RFC7719"/>, section 6) with
NXDOMAIN instead of the normal NODATA (<xref
target="RFC7719"/>, section 3).</t>
<t>RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example today is
mta2._domainkey.cbs.nl (which exists) where querying _domainkey.cbs.nl
yields NXDOMAIN. Another example is
www.upenn.edu, redirected to www.upenn.edu-dscg.edgesuite.net while a
query for edu-dscg.edgesuite.net returns NXDOMAIN.</t>
<t>Such name servers are definitely wrong and have always been. Their
behaviour is incompatible with DNSSEC. Given
the advantages of "NXDOMAIN cut", there is little reason to support
this behavior.
</t>
</section>

<section anchor="impladvice" title="Implementation considerations">
  <t>This section is non-normative, and is composed only of various
  things which may be useful for implementors. A recursive resolver
  may 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,
  in practice, other implementations are possible, as well as various
  optimisations (such as a tree, augmented by an index of some common
  domain names).</t>
  <t>If a resolver implements its cache as a tree (without any
  optimisation), one way to follow the rules of <xref target="rules"/>
  is, when receiving the NXDOMAIN, to prune the subtree of positive
  cache entries at that node, or to delete all individual cache
  entries for names below that node. Then, when searching downward in
  its cache, this iterative caching DNS resolver stop searching if it
  encounters a cached non-existence.
  </t>
  <t>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 <xref target="rules"/>. So these rules are
  a SHOULD and not a MUST.</t>
</section>

<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>

<section anchor="security" title="Security Considerations">
<t>The technique described here may help against a denial-of-service
attack named "random qnames" and described in <xref
target="benefits"/>.</t>
<t>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 false NXDOMAIN, thus "deleting" a part of
the domain name tree. This denial-of-service attack is already
possible without the rules of this document (but "NXDOMAIN cut" may
increase its effects). The only solution is to use DNSSEC.</t>
</section>

<section anchor="impl" title="Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION">

<t>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 <xref
target="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.</t>
<t>According to <xref target="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".</t>
<t>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.</t>
<t>There are a few exceptions. The Unbound resolver has a
configuration parameter called <eref
target="https://www.unbound.net/documentation/unbound.conf.html">"harden-below-nxdomain"
</eref>, which if set to "yes" turns on "NXDOMAIN cut" behavior ("only
DNSSEC-secure nxdomains are used", see <xref target="security"/>). The PowerDNS recursor has optional
partial support for "NXDOMAIN cut", for the root domain only, with its
"root-nx-trust" setting, <eref
target="https://doc.powerdns.com/md/recursor/settings/#root-nx-trust">described
as</eref> "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.".</t>
</section>

<section title="Acknowledgments">
<t>The main idea is in this document is taken from 
   <xref target="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, John Levine, 
Jinmei Tatuya, Bob Harold and Duane Wessels provided valuable feedback and 
suggestions.</t>
</section>

</middle>

<back>

<references title='Normative References'>
&rfc1034;
&rfc1035;
&rfc2119;
&rfc2308;
&rfc6604;
</references>

<references title='Informative References'>
&rfc4035;
&rfc6982;
&rfc7719;
&rfc7816;
&I-D.vixie-dnsext-resimprove;
&I-D.fujiwara-dnsop-nsec-aggressiveuse;

<reference anchor="joost-dnsterror" target="http://www.michael-joost.de/dnsterror.html">
<front>
<title>About DNS Attacks and ICMP Destination Unreachable Reports</title>
<author fullname="Michael Joost" initials="M." surname="Joost"/>
<date month="December" year="2014"/>
</front>
</reference>

<reference anchor="balakrichenan-dafa888"
	   target="https://indico.dns-oarc.net/event/20/session/3/contribution/37">
  <front>
    <title>Disturbance in the DNS - "Random qnames", the dafa888 DoS
    attack"</title>
    <author fullname="Sandoche Balakrichenan" initials="S."
	    surname="Balakrichenan"/>
    <date month="October" year="2014"/>
    <abstract><t>At the DNS-OARC meeting in Los Angeles</t></abstract>
  </front>
</reference>

</references>

<section anchor="future" title="Why can't we just use the owner name of the returned SOA?">
  <t>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
  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,
  it can only register the fact that www.foobar.example (and
  everything underneath) does not exist. Even if the accompanying SOA
  record is for example only, one cannot infer that
  foobar.example is nonexistent. The accompanying SOA indicates the
  apex of the zone, not the closest existing domain name.</t>
  <t>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).</t>
<t>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-of-scope for this document. It would require to address
the problems mentioned in the first paragraph of this section. A possible 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 are between the
QNAME and the owner name of the SOA. (A resolver which does DNSSEC
validation or QNAME minimisation will need to do it, anyway.)</t>
</section>

<section title="Related approaches">
<t>The document <xref
target="I-D.fujiwara-dnsop-nsec-aggressiveuse"/> describes another way to
address some of the same concerns (decreasing the traffic for
non-existing domain names). Unlike "NXDOMAIN cut",
it requires DNSSEC but it is more powerful since it can synthesize
NXDOMAINs for domains that were not queried.</t>
</section>

</back>

</rfc>