draft-ietf-dnsop-nsec-aggressiveuse.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-dnsop-nsec-aggressiveuse-02"
     ipr="trust200902" updates="4035">
  <front>
    <title abbrev="NSEC/NSEC3 usage">Aggressive use of NSEC/NSEC3</title>

    <author fullname="Kazunori Fujiwara" initials="K." surname="Fujiwara">
      <organization abbrev="JPRS">Japan Registry Services Co.,
      Ltd.</organization>

      <address>
        <postal>
          <street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>

          <city>Chiyoda-ku, Tokyo</city>

          <code>101-0065</code>

          <country>Japan</country>
        </postal>

        <phone>+81 3 5215 8451</phone>

        <email>fujiwara@jprs.co.jp</email>
      </address>
    </author>

    <author fullname="Akira Kato" initials="A." surname="Kato">
      <organization abbrev="Keio/WIDE">Keio University/WIDE
      Project</organization>

      <address>
        <postal>
          <street>Graduate School of Media Design, 4-1-1 Hiyoshi</street>

          <city>Kohoku</city>

          <region>Yokohama</region>

          <code>223-8526</code>

          <country>Japan</country>
        </postal>

        <phone>+81 45 564 2490</phone>

        <email>kato@wide.ad.jp</email>
      </address>
    </author>

    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>

          <city>Mountain View, CA</city>

          <code>94043</code>

          <country>US</country>
        </postal>

        <email>warren@kumari.net</email>
      </address>
    </author>

    <date day="13" month="September" year="2016"/>

    <area>operations</area>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>The DNS relies upon caching to scale; however, the cache lookup
      generally requires an exact match. This document specifies the use of
      NSEC/NSEC3 resource records to generate negative answers within a range.
      This increases performance / decreases latency, decreases resource
      utilization on both authoritative and recursive servers, and also
      increases privacy. It may also help increase resilience to certain DoS
      attacks in some circumstances.</t>

      <t>This document updates RFC4035 by allowing resolvers to generate
      negative answers based upon NSEC/NSEC3 records.</t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to frequently asked questions, general musings,
      etc. They will be removed before publication.This document is being
      collaborated on in Github at:
      https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse. The most
      recent version of the document, open issues, etc should all be available
      here. The authors (gratefully) accept pull requests.</t>

      <t>Known / open issues [To be moved to Github issue tracker]: <list
          style="numbers">
          <t>We say things like: "Currently the DNS does ..." - this will not
          be true after this is deployed, but I'm having a hard time rewording
          this. "Without the techniques described in this document..." seems
          klunky. Perhaps "historically?!"</t>
        </list>]</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>A DNS negative cache exists, and is used to cache the fact
      that a name does not exist. This method of negative caching requires
      exact matching; this leads to unnecessary additional lookups, increases
      latency, leads to extra resource utilization on both authoritative and
      recursive servers, and decreases privacy by leaking queries.</t>

      <t>This document updates RFC 4035 to allow recursive resolvers to use
      NSEC/NSEC3 resource records to aggressively use cache negative answers. This
      would allow such resolvers to respond with NXDOMAIN immediately if the
      name in question falls into a range expressed by a NSEC/NSEC3 resource
      record already in the cache.</t>

      <t>Aggressive Use Of Negative Caching was first proposed in Section 6 of DNSSEC
      Lookaside Validation (DLV) <xref target="RFC5074"/> in order to find
      covering NSEC records efficiently.</t>

      <t>Section 3 of <xref target="I-D.vixie-dnsext-resimprove"/> "Stopping
      Downward Cache Search on NXDOMAIN" and <xref
      target="I-D.ietf-dnsop-nxdomain-cut"/> proposed another approach to use
      NXDOMAIN information effectively.</t>
    </section>

    <section anchor="terminology" 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 RFC 2119 <xref
      target="RFC2119"/>.</t>

      <t>Many of the specialized terms used in this document are defined in
      DNS Terminology <xref target="RFC7719"/>. In this document we are using
      the terms "recursive resolver" or "recursive server" as a more readable
      alternative to the more formal<xref target="RFC7719"/> "full-service
      resolver"</t>

      <t>The key words "Closest Encloser" and "Source of Synthesis" in this
      document are to be interpreted as described in <xref
      target="RFC4592"/>.</t>

      <t>"Closest Encloser" is also defined in NSEC3 <xref target="RFC5155"/>,
      as is "Next closer name".</t>
    </section>

    <section anchor="problem-statement" title="Problem Statement">
      <t>The DNS negative cache caches negative (non-existent)
      information, and requires an exact match in most instances <xref
      target="RFC2308"/>.</t>

      <t>Assume that the (DNSSEC signed) "example.com" zone contains:</t>

      <t><list style="empty">
          <t>apple.example.com IN A 192.0.2.1</t>

          <t>elephant.example.com IN A 192.0.2.2</t>

          <t>zebra.example.com IN A 192.0.2.3</t>
        </list></t>

      <t>If a recursive resolver gets a query for cat.example.com, it will
      query the example.com authoritative servers and will get back an NSEC
      (or NSEC3) record starting that there are no records between apple and
      elephant. The recursive resolver then knows that cat.example.com does
      not exist; however, it does not use the fact that the proof
      covers a range (apple to elephant) to suppress queries for other labels
      that fall within this range. This means that if the recursive resolvers
      gets a query for ball.example.com (or dog.example.com) it will once
      again go off and query the example.com servers for these names.</t>

      <t>Apart from wasting bandwidth, this also wastes resources on the
      recursive server (it needs to keep state for outstanding queries),
      wastes resources on the authoritative server (it has to answer
      additional questions), increases latency (the end user has to wait
      longer than necessary to get back an NXDOMAIN answer), can be used by
      attackers to cause a DoS (see additional resources), and also has
      privacy implications (e.g: typos leak out further than necessary).</t>
    </section>

    <section title="Background">
      <t>DNSSEC <xref target="RFC4035"/> and <xref target="RFC5155"/> both
      provide "authenticated denial of existence"; this is a cryptographic
      proof that the queried for name does not exist, accomplished by
      providing a (DNSSEC secured) record containing the names which appear
      alphabetically before and after the queried for name. In the example
      above, if the (DNSSEC validating) recursive server were to query for
      lion.example.com it would receive a (signed) NSEC/NSEC3 record stating
      that there are no labels between "elephant" and "zebra". This is a
      signed, cryptographic proof that these names are the ones before and
      after the queried for label. As lion.example.com falls within this
      range, the recursive server knows that lion.example.com really does not
      exist. This document specifies that this NSEC/NSEC3 record should be
      used to generate negative answers for any queries that the recursive
      server receives that fall within the range covered by the record (for
      the TTL for the record).</t>

      <t><xref target="RFC4035"/>; Section 4.5 states:</t>

      <t>For a zone signed with NSEC, it would be possible to use the
      information carried in NSEC resource records to indicate the
      non-existence of a range of names. However, such use is discouraged by
      Section 4.5 of RFC4035. It is recommended that readers read RFC4035 in
      its entirety for a better understanding. At the root of the concern is
      that new records could have been added to the zone during the TTL of the
      NSEC record, and that generating negative responses from the NSEC record
      would hide these. We believe this recommendation can be relaxed because
      lookups for the specific name could have come in during the normal
      negative cache time and so operators should have no expectation that an
      added name would work immediately. We think that the TTL of the NSEC
      record is the authoritative statement of how quickly a name can start
      working within a zone.</t>
    </section>

    <section anchor="aggressive-negative-caching"
             title="Aggressive Use Of Negative Caching">
        <t/>

        <t>Section 4.5 of <xref target="RFC4035"/> shows that "In theory, a
        resolver could use wildcards or NSEC RRs to generate positive and
        negative responses (respectively) until the TTL or signatures on the
        records in question expire. However, it seems prudent for resolvers to
        avoid blocking new authoritative data or synthesizing new data on
        their own. Resolvers that follow this recommendation will have a more
        consistent view of the namespace".</t>

        <t>This document relaxes this this restriction, as follows:</t>

        <figure>
          <artwork><![CDATA[
+--------------------------------------------------------------+
|  Once the records are validated, DNSSEC enabled validating   |
|  resolvers MAY use NSEC/NSEC3 resource records to generate   |
|  negative responses until their effective TTLs or signatures |
|  for those records expire.                                   |
+--------------------------------------------------------------+
]]></artwork>
        </figure>

        <t>If the validating resolver's cache has sufficient information to
        validate the query, the resolver SHOULD use NSEC/NSEC3/wildcard
        records aggressively. Otherwise, it MUST fall back to send the query
        to the authoritative DNS servers.</t>

        <t>If the query name has the matching NSEC/NSEC3 RR proving the
        information requested does not exist, the resolver may respond with a
        NODATA (empty) answer.</t>

      <section anchor="nsec" title="NSEC">
        <t>Implementations SHOULD enable aggressive use of NSEC by default.
        Implementations SHOULD provide a configuration switch to disable
        aggressive use of NSEC and allow it to be enabled or disabled per
        domain.</t>

        <t>The validating resolver needs to check the existence of an NSEC RR
        matching/covering the source of synthesis and an NSEC RR covering the
        query name.</t>

        <t>If the validating resolver's cache contains an NSEC RR covering the
        source of synthesis and the covering NSEC RR of the query name, the
        resolver may respond with NXDOMAIN error immediately.</t>
      </section>

      <section anchor="nsec3" title="NSEC3">
        <t>NSEC3 aggressive use of negative caching is more difficult. If the zone is
        signed with NSEC3, the validating resolver needs to check the
        existence of non-terminals and wildcards which derive from query
        names.</t>

        <t>If the validating resolver's cache contains an NSEC3 RR matching
        the closest encloser, an NSEC3 RR covering the next closer name, and
        an NSEC3 RR covering the source of synthesis, it is possible for the
        resolver to respond with NXDOMAIN immediately.</t>

        <t>If a covering NSEC3 RR has Opt-Out flag, the covering NSEC3 RR does
        not prove the non-existence of the domain name and the aggressive
        negative caching is not possible for the domain name.</t>

        <t>A validating resolver implementation MAY support aggressive use of
        NSEC3. If it does aggressive use of NSEC3, it SHOULD provide a
        configuration switch to disable aggressive use of NSEC3 and allow it
        to be enabled or disabled for specific zones.</t>
      </section>

      <section anchor="wildcard" title="Wildcard">
        <t>The last paragraph of RFC 4035 Section 4.5 discusses aggressive use
        of a cached deduced wildcard (as well as aggressive use of NSEC) and
        recommends that it is not relied upon.</t>

        <t>Just like the case for the aggressive use of NSEC discussed in this
        draft, we revise this recommendation. As long as the resolver knows a
        name would not exist without the wildcard match, it can answer a query
        for that name using the cached deduced wildcard, and it may be
        justified for performance and other benefits.</t>

        <t>Such aggressive use of cached deduced wildcard can be employed
        independently from aggressive use of NSEC. But, it will be more
        effective when both are enabled since the resolver can determine the
        name subject to wildcard would not otherwise exist more
        efficiently.</t>

        <t>Furthermore, when aggressive use of NSEC is enabled, the aggressive
        use of cached deduced wildcard will be more effective.</t>

        <t>An implementation MAY support aggressive use of wildcards. It
        SHOULD provide a configuration switch to disable aggressive use of
        wildcards.</t>
      </section>

      <section anchor="consideration-on-ttl" title="Consideration on TTL">
        <t>The TTL value of negative information is especially important,
        because newly added domain names cannot be used while the negative
        information is effective. Section 5 of RFC 2308 states that the
        maximum number of negative cache TTL value is 3 hours (10800). It is
        RECOMMENDED that resolvers limit the maximum effective TTL value of
        negative responses (NSEC/NSEC3 RRs) to this same value.</t>
      </section>
    </section>

    <section title="Benefits">
      <t>The techniques described in this document provide a number of
      benefits, including (in no specific order):<list style="hanging">
          <t hangText="Reduced latency">By answering directly from cache, recursive
          resolvers can immediately inform clients that the name they are
          looking for does not exist, improving the user experience.</t>

          <t hangText="Decreased recursive server load">By answering negative
          queries from the cache, recursive servers avoid having send a query
          and wait for a response. In addition to decreasing the bandwidth
          used, it also means that the server does not need to allocate and
          maintain state, thereby decreasing memory and CPU load.</t>

          <t hangText="Decreased authorative server load">Because recursive
          servers can answer (negative) queries without asking the
          authoritative server, the authoritative servers receive less
          queries. This decreases the authoritative server bandwidth, queries
          per second and CPU utilization.</t>
        </list>The scale of the benefit depends upon multiple factors,
      including the query distribution. For example, currently around 65% of
      queries to Root Name servers result in NXDOMAIN responses; this
      technique will eliminate a sizable quantity of these.</t>

      <t>[ Editor note: There has been some discussion on if this document
      should discuss this attack and mitigation. The authors think that this
      is useful / important, but some participants feel that it oversells the
      DoS mitigation benefit. Please let us know if the below is helpful.
      Also, the below description is not as clear as it could be - it's been
      tricky to balance readability, correctness and conciseness. Text
      gratefully accepted... ] </t>

      <t>The technique described in this document may also mitigate so-called
      "random QNAME attacks", in which attackers send many queries for random
      sub-domains to recursive resolvers. As the recursive server will not
      have the answers cached it has to ask the authoritative servers for each
      random query, leading to a DoS on the authoritative (and often
      recursive) servers. Aggressive NSEC may help mitigate these attacks by
      allowing the recursive to answer directly from cache for any random
      queries which fall within already requested ranges. The effectiveness of
      this depends upon a number of factors, including if the attacker is
      making his queries through recursive resolvers (e.g to hide his source),
      the number of entries in the zone, the TTL, if the zone is using NSEC,
      if the attacker is setting the CD bit, etc. In the ideal case,
      authoritative servers under attack will need to answer somewhere between
      number_of_entries_in_zone queries and 2 * number_of_entries_in_zone
      queries from each recursive server. This is because there are as many
      "holes" between labels as there are labels in a zone. If the random
      query falls in range for which recursive server does not have an NSEC
      record cached, it will send a query to the authoritative server, and so
      it will send approximately the same number of queries as there are
      "holes" between entries. If the random queries happen to be for names
      which exist in the zone, the recursive will send those as well.</t>
    </section>

    <section anchor="update" title="Update to RFC 4035">
      <t>Section 4.5 of <xref target="RFC4035"/> shows that "In theory, a
      resolver could use wildcards or NSEC RRs to generate positive and
      negative responses (respectively) until the TTL or signatures on the
      records in question expire. However, it seems prudent for resolvers to
      avoid blocking new authoritative data or synthesizing new data on their
      own. Resolvers that follow this recommendation will have a more
      consistent view of the namespace".</t>

      <t>The paragraph is updated as follows:</t>

      <figure>
        <artwork><![CDATA[
+--------------------------------------------------------------+
|  Once the records are validated, DNSSEC enabled recursive    |
|  resolvers MAY use wildcards and NSEC/NSEC3 resource records |
|  to generate (positive and) negative responses until their   |
|  effective TTLs or signatures for those records expire.      |
+--------------------------------------------------------------+
]]></artwork>
      </figure>
    </section>

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

    <section anchor="securitycons" title="Security Considerations">
      <t>Newly registered resource records may not be used immediately.
      However, choosing suitable TTL value and negative cache TTL value (SOA
      MINIMUM field) will mitigate the delay concern, and it is not a security
      problem.</t>

      <t>It is also suggested to limit the maximum TTL value of NSEC / NSEC3
      resource records in the negative cache to, for example, 10800 seconds
      (3hrs), to mitigate this issue. Implementations which comply with this
      proposal are recommended to have a configurable maximum value of NSEC
      RRs in the negative cache.</t>

      <t>Aggressive use of NSEC / NSEC3 resource records without DNSSEC
      validation may cause security problems. It is highly recommended to
      apply DNSSEC validation.</t>
    </section>

    <section anchor="implementation-status" title="Implementation Status">
      <t>Unbound supports aggressive use of negative caching.</t>
    </section>

    <section anchor="acknowledgments" title="Acknowledgments">
      <t>The authors gratefully acknowledge DLV <xref target="RFC5074"/>
      author Samuel Weiler and the Unbound developers.</t>

      <t>The authors would like to specifically thank Tatuya JINMEI for
      extensive review and comments, and also Mark Andrews, Stephane
      Bortzmeyer, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob
      Harold, Shumon Huque, Pieter Lexis and Matthijs Mekking.</t>
    </section>

    <section anchor="change-history" title="Change History">
      <t>RFC Editor: Please remove this section prior to publication.</t>

      <t>-01 to -02:<list style="symbols">
          <t>Added Section 6 - Benefits (as suggested by Jinmei).</t>

          <t>Removed Appendix B (Jinmei)</t>

          <t>Replaced "full-service" with "validating" (where applicable)</t>

          <t>Integrated other comments from Jinmei from
          https://www.ietf.org/mail-archive/web/dnsop/current/msg17875.html</t>

          <t>Integrated comment from co-authors, including re-adding parts of
          Appendix B, terminology, typos.</t>

          <t>Tried to explain under what conditions this may actually mitigate
          attacks.</t>
        </list></t>

      <t>-00 to -01:<list style="symbols">
          <t>Comments from DNSOP meeting in Berlin.</t>

          <t>Changed intended status to Standards Track (updates RFC 4035)</t>

          <t>Added a section "Updates to RFC 4035"</t>

          <t>Some language clarification / typo / cleanup</t>

          <t>Cleaned up the TTL section a bit.</t>

          <t>Removed Effects section, Additional proposal section, and pseudo
          code.</t>

          <t>Moved "mitigation of random subdomain attacks" to Appendix.</t>
        </list></t>

      <t>From draft-fujiwara-dnsop-nsec-aggressiveuse-03 -&gt;
      draft-ietf-dnsop-nsec-aggressiveuse<list style="symbols">
          <t>Document adopted by DNSOP WG.</t>

          <t>Adoption comments</t>

          <t>Changed main purpose to performance</t>

          <t>Use NSEC3/Wildcard keywords</t>

          <t>Improved wordings (from good comments)</t>

          <t>Simplified pseudo code for NSEC3</t>

          <t>Added Warren as co-author.</t>

          <t>Reworded much of the problem statement</t>

          <t>Reworked examples to better explain the problem / solution.</t>
        </list></t>

      <section anchor="version-draft-fujiwara-dnsop-nsec-aggressiveuse-01"
               title="Version draft-fujiwara-dnsop-nsec-aggressiveuse-01">
        <t><list style="symbols">
            <t>Added reference to DLV <xref target="RFC5074"/> and imported
            some sentences.</t>

            <t>Added Aggressive Negative Caching Flag idea.</t>

            <t>Added detailed algorithms.</t>
          </list></t>
      </section>

      <section anchor="version-draft-fujiwara-dnsop-nsec-aggressiveuse-02"
               title="Version draft-fujiwara-dnsop-nsec-aggressiveuse-02">
        <t><list style="symbols">
            <t>Added reference to <xref
            target="I-D.vixie-dnsext-resimprove"/></t>

            <t>Added considerations for the CD bit</t>

            <t>Updated detailed algorithms.</t>

            <t>Moved Aggressive Negative Caching Flag idea into Additional
            Proposals</t>
          </list></t>
      </section>

      <section anchor="version-draft-fujiwara-dnsop-nsec-aggressiveuse-03"
               title="Version draft-fujiwara-dnsop-nsec-aggressiveuse-03">
        <t><list style="symbols">
            <t>Added "Partial implementation"</t>

            <t>Section 4,5,6 reorganized for better representation</t>

            <t>Added NODATA answer in Section 4</t>

            <t>Trivial updates</t>

            <t>Updated pseudo code</t>
          </list></t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119"
                 target="http://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>

          <date month="March" year="1997"/>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. This document specifies
            an Internet Best Current Practices for the Internet Community, and
            requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14"/>

        <seriesInfo name="RFC" value="2119"/>

        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>

      <reference anchor="RFC2308"
                 target="http://www.rfc-editor.org/info/rfc2308">
        <front>
          <title>Negative Caching of DNS Queries (DNS NCACHE)</title>

          <author fullname="M. Andrews" initials="M." surname="Andrews">
            <organization/>
          </author>

          <date month="March" year="1998"/>

          <abstract>
            <t>RFC1034 provided a description of how to cache negative
            responses. It however had a fundamental flaw in that it did not
            allow a name server to hand out those cached responses to other
            resolvers, thereby greatly reducing the effect of the caching.
            This document addresses issues raise in the light of experience
            and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2308"/>

        <seriesInfo name="DOI" value="10.17487/RFC2308"/>
      </reference>

      <reference anchor="RFC4035"
                 target="http://www.rfc-editor.org/info/rfc4035">
        <front>
          <title>Protocol Modifications for the DNS Security
          Extensions</title>

          <author fullname="R. Arends" initials="R." surname="Arends">
            <organization/>
          </author>

          <author fullname="R. Austein" initials="R." surname="Austein">
            <organization/>
          </author>

          <author fullname="M. Larson" initials="M." surname="Larson">
            <organization/>
          </author>

          <author fullname="D. Massey" initials="D." surname="Massey">
            <organization/>
          </author>

          <author fullname="S. Rose" initials="S." surname="Rose">
            <organization/>
          </author>

          <date month="March" year="2005"/>

          <abstract>
            <t>This document is part of a family of documents that describe
            the DNS Security Extensions (DNSSEC). The DNS Security Extensions
            are a collection of new resource records and protocol
            modifications that add data origin authentication and data
            integrity to the DNS. This document describes the DNSSEC protocol
            modifications. This document defines the concept of a signed zone,
            along with the requirements for serving and resolving by using
            DNSSEC. These techniques allow a security-aware resolver to
            authenticate both DNS resource records and authoritative DNS error
            indications.</t>

            <t>This document obsoletes RFC 2535 and incorporates changes from
            all updates to RFC 2535. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4035"/>

        <seriesInfo name="DOI" value="10.17487/RFC4035"/>
      </reference>

      <reference anchor="RFC4592"
                 target="http://www.rfc-editor.org/info/rfc4592">
        <front>
          <title>The Role of Wildcards in the Domain Name System</title>

          <author fullname="E. Lewis" initials="E." surname="Lewis">
            <organization/>
          </author>

          <date month="July" year="2006"/>

          <abstract>
            <t>This is an update to the wildcard definition of RFC 1034. The
            interaction with wildcards and CNAME is changed, an error
            condition is removed, and the words defining some concepts central
            to wildcards are changed. The overall goal is not to change
            wildcards, but to refine the definition of RFC 1034.
            [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4592"/>

        <seriesInfo name="DOI" value="10.17487/RFC4592"/>
      </reference>

      <reference anchor="RFC5155"
                 target="http://www.rfc-editor.org/info/rfc5155">
        <front>
          <title>DNS Security (DNSSEC) Hashed Authenticated Denial of
          Existence</title>

          <author fullname="B. Laurie" initials="B." surname="Laurie">
            <organization/>
          </author>

          <author fullname="G. Sisson" initials="G." surname="Sisson">
            <organization/>
          </author>

          <author fullname="R. Arends" initials="R." surname="Arends">
            <organization/>
          </author>

          <author fullname="D. Blacka" initials="D." surname="Blacka">
            <organization/>
          </author>

          <date month="March" year="2008"/>

          <abstract>
            <t>The Domain Name System Security (DNSSEC) Extensions introduced
            the NSEC resource record (RR) for authenticated denial of
            existence. This document introduces an alternative resource
            record, NSEC3, which similarly provides authenticated denial of
            existence. However, it also provides measures against zone
            enumeration and permits gradual expansion of delegation-centric
            zones. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5155"/>

        <seriesInfo name="DOI" value="10.17487/RFC5155"/>
      </reference>

      <reference anchor="RFC5074"
                 target="http://www.rfc-editor.org/info/rfc5074">
        <front>
          <title>DNSSEC Lookaside Validation (DLV)</title>

          <author fullname="S. Weiler" initials="S." surname="Weiler">
            <organization/>
          </author>

          <date month="November" year="2007"/>

          <abstract>
            <t>DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
            DNS Security (DNSSEC) trust anchors outside of the DNS delegation
            chain. It allows validating resolvers to validate DNSSEC-signed
            data from zones whose ancestors either aren't signed or don't
            publish Delegation Signer (DS) records for their children. This
            memo provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5074"/>

        <seriesInfo name="DOI" value="10.17487/RFC5074"/>
      </reference>

      <reference anchor="RFC7719"
                 target="http://www.rfc-editor.org/info/rfc7719">
        <front>
          <title>DNS Terminology</title>

          <author fullname="P. Hoffman" initials="P." surname="Hoffman">
            <organization/>
          </author>

          <author fullname="A. Sullivan" initials="A." surname="Sullivan">
            <organization/>
          </author>

          <author fullname="K. Fujiwara" initials="K." surname="Fujiwara">
            <organization/>
          </author>

          <date month="December" year="2015"/>

          <abstract>
            <t>The DNS is defined in literally dozens of different RFCs. The
            terminology used by implementers and developers of DNS protocols,
            and by operators of DNS systems, has sometimes changed in the
            decades since the DNS was first defined. This document gives
            current definitions for many of the terms used in the DNS in a
            single document.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7719"/>

        <seriesInfo name="DOI" value="10.17487/RFC7719"/>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="I-D.vixie-dnsext-resimprove">
        <front>
          <title>Improvements to DNS Resolvers for Resiliency, Robustness, and
          Responsiveness</title>

          <author fullname="Paul Vixie" initials="P" surname="Vixie">
            <organization/>
          </author>

          <author fullname="Rodney Joffe" initials="R" surname="Joffe">
            <organization/>
          </author>

          <author fullname="Frederico Neves" initials="F" surname="Neves">
            <organization/>
          </author>

          <date day="23" month="June" year="2010"/>

          <abstract>
            <t>This document describes several mechanisms which can be
            employed by iterative caching DNS resolvers to improve resiliency,
            robustness, and responsiveness. These improvements are optional
            and they require no changes to the protocol, or to authority
            servers, or to DNS stub resolver clients.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-vixie-dnsext-resimprove-00"/>

        <format target="http://www.ietf.org/internet-drafts/draft-vixie-dnsext-resimprove-00.txt"
                type="TXT"/>
      </reference>

      <reference anchor="I-D.ietf-dnsop-nxdomain-cut">
        <front>
          <title>NXDOMAIN really means there is nothing underneath</title>

          <author fullname="Stephane Bortzmeyer" initials="S"
                  surname="Bortzmeyer">
            <organization/>
          </author>

          <author fullname="Shumon Huque" initials="S" surname="Huque">
            <organization/>
          </author>

          <date day="8" month="May" year="2016"/>

          <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. 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 at Github [1]. This documents
            clarifies RFC 1034 and modifies a bit RFC 2308 so it updates both
            of them.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-dnsop-nxdomain-cut-03"/>

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-dnsop-nxdomain-cut-03.txt"
                type="TXT"/>
      </reference>
    </references>

    <section anchor="detailed-implementation-idea"
             title="Detailed implementation notes">
      <t><list style="symbols">
          <t>Previously, cached negative responses were indexed by QNAME,
          QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035, Section
          4.7), and only queries matching the index key would be answered from
          the cache. With aggressive use of negative caching, the validator, in
          addition to checking to see if the answer is in its cache before
          sending a query, checks to see whether any cached and validated NSEC
          record denies the existence of the sought record(s). Aggressive use
          of negative caching, a validator will not make queries for
          any name covered by a cached and validated NSEC record. Furthermore,
          a validator answering queries from clients will synthesize a
          negative answer whenever it has an applicable validated NSEC in its
          cache unless the CD bit was set on the incoming query. (Imported
          from Section 6 of <xref target="RFC5074"/>).</t>

          <t>Implementing aggressive use of negative caching suggests that a
          validator will need to build an ordered data structure of NSEC and
          NSEC3 records for each signer domain name of NSEC / NSEC3 records in
          order to efficiently find covering NSEC / NSEC3 records. Call the
          table as NSEC_TABLE. (Imported from Section 6.1 of <xref
          target="RFC5074"/> and expanded.)</t>

          <t>The aggressive use of negative caching may be inserted at the cache
          lookup part of the recursive resolvers.</t>

          <t>If errors happen in aggressive use of negative caching algorithm,
          resolvers MUST fall back to resolve the query as usual. "Resolve the
          query as usual" means that the resolver must process the query as
          though it does not implement aggressive use of negative caching.</t>
        </list></t>
    </section>
  </back>
</rfc>