draft-ietf-dnsop-compact-denial-of-existence.xml

<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
        category="std" consensus="true"
        docName="draft-ietf-dnsop-compact-denial-of-existence-06"
        ipr="trust200902" updates="4034, 4035" obsoletes=""
        submissionType="IETF" xml:lang="en"
        tocInclude="true" tocDepth="4"
        symRefs="true" sortRefs="true" version="3">

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="Compact Denial of Existence in DNSSEC">
       Compact Denial of Existence in DNSSEC
    </title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-compact-denial-of-existence-06"/>

    <author fullname="Shumon Huque" initials="S." surname="Huque">
      <organization>Salesforce</organization>
      <address>
        <postal>
          <street>415 Mission Street, 3rd Floor</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94105</code>
          <country>United States of America</country>
        </postal>
        <email>shuque@gmail.com</email>
      </address>
    </author>

    <author fullname="Christian Elmerot" initials="C." surname="Elmerot">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St.</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94107</code>
          <country>United States of America</country>
        </postal>
        <email>elmerot@cloudflare.com</email>
      </address>
    </author>

    <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
      <organization>Retired / Unaffiliated</organization>
      <address>
        <email>ogud@ogud.com</email>
      </address>
    </author>

    <date day="23" month="12" year="2024"/>
    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>DNS</keyword>
    <keyword>DNSSEC</keyword>
    <keyword>Denial of Existence</keyword>
    <keyword>Compact Denial of Existence</keyword>
    <keyword>Compact Answers</keyword>
    <keyword>Black Lies</keyword>
    <keyword>NXDOMAIN</keyword>
    <keyword>NODATA</keyword>
    <keyword>Empty Non-Terminal</keyword>

    <abstract>
     <t>
       This document describes a technique to generate a signed DNS response
       on demand for a non-existent name by claiming that the name exists
       but doesn't have any data for the queried record type. Such answers
       require only one minimal NSEC record, allow online signing servers
       to minimize signing operations and response sizes, and prevent zone
       content disclosure.
     </t>
     <t>
       This document updates RFC 4034 and 4035.
     </t>
    </abstract>

    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/shuque/id-dnssec-compact-lies"/>.</t>
    </note>

  </front>

  <middle>

    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction and Motivation</name>
      <t>
        One of the functions of the Domain Name System Security Extensions
        (DNSSEC) <xref target="RFC9364" /> is
        "Authenticated Denial of Existence",
        i.e. proving that a DNS name or record type does not exist.
        Normally, this is done by means of signed NSEC or NSEC3 records.
        In the precomputed signature model, these records chain together
        existing names, or cryptographic hashes of them in the zone. In
        the online signing model, described in NSEC and NSEC3 "White Lies"
        <xref target="RFC4470" /> <xref target="RFC7129" />,
        they are used to dynamically compute an epsilon
        function around the queried name. A 'type bitmap' in the data field
        of the NSEC or NSEC3 record asserts which resource record types are
        present at the name.
      </t>
      <t>
        The response for a non-existent name requires up to 2 signed NSEC
        records or up to 3 signed NSEC3 records (and for online signers,
        the associated cryptographic computation), to prove that (1) the
        name did not explicitly exist in the zone, and (2) that it could
        not have been synthesized by a wildcard.
      </t>
      <t>
        This document describes an alternative technique, "Compact Denial
        of Existence" or "Compact Answers",
        to generate a signed DNS response on demand for a non-existent
        name by claiming that the name exists but has no resource records
        associated with the queried type, i.e. it returns a NODATA response
        rather than an NXDOMAIN response. A NODATA response, which has a
        response code (RCODE) of NOERROR and an empty ANSWER section,
        requires only one NSEC record matching the queried name. This has
        two advantages: the DNS response size is smaller, and it reduces
        the online cryptographic work involved in generating the response.
      </t>
      <t>
        The use of minimally covering NSEC records also prevents
        adversaries from enumerating the entire contents of DNS zones
        by walking NSEC chains.
      </t>
    </section>

    <section anchor="distinguish" numbered="true" toc="default">
      <name>Distinguishing non-existent names</name>
      <t>
        Since NODATA responses are generated for non-existent names, and
        there are no defined record types for the name, the NSEC type
        bitmap in the response will only contain "NSEC" and "RRSIG".
        Tools that need to accurately identify non-existent names in
        responses cannot rely on this specific type bitmap because Empty
        Non-Terminal (ENT) names (which positively exist) also have no
        record types at the name and will return exactly the same type
        bitmap.
      </t>
      <t>
        This specification defines the use of a synthetic Resource Record
        type to signal the presence of a non-existent name. The
        mnemonic for this RR type is "NXNAME", chosen to clearly
        distinguish it from the response code mnemonic NXDOMAIN.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         Type    Value  Meaning
         NXNAME  128    NXDOMAIN indicator for Compact Denial of Existence
        ]]></artwork>
      <t>
        This RR type is added to the NSEC type bitmap for responses
        to non-existent names (in addition to the required RRSIG and
        NSEC types). It is a "Meta-Type", as defined in
        <xref target="RFC6895" />, stores no data in a DNS zone, and
        cannot be usefully queried. <xref target="response-nxname"/>
        describes what a DNS resolver or authoritative server should
        do if it receives an explicit query for NXNAME.
      </t>
      <t>
        No special handling of this RR type is required on the part of
        DNS resolvers. However, resolvers may optionally implement the
        behavior described in <xref target="signaled-rcode"/> 
        (Response Code Restoration) to better restore NXDOMAIN visibility
        to various applications.
      </t>
    </section>

    <section anchor="responses" numbered="true" toc="default">
      <name>Generating Responses</name>

    <t>
    This section describes various types of answers generated by
    authoritative servers implementing Compact Denial of Existence.
    At the current time, the compact denial scheme is only defined
    for NSEC. While it could support NSEC3 too, there is no benefit
    in introducing the additional complexity associated with it.
    </t>

    <section anchor="response-nxd" numbered="true" toc="default">
      <name>Responses for Non-Existent Names</name>
      <t>
        When the authoritative server receives a query for a non-existent
        name in a zone that it serves, a NODATA response (response code
        NOERROR, empty Answer section) is generated with a dynamically
        constructed NSEC record with the owner name matching the queried
        name (QNAME).
      </t>
      <t>
        The Next Domain Name field SHOULD be set to the immediate
        lexicographic successor of the QNAME. The Type Bit Maps field
        MUST only have the bits set for the following RR Types: RRSIG,
        NSEC, and NXNAME. (The immedidate lexicographic successor is
        the typical case of the "DNS Name Successor" defined in
        <xref target="RFC4471" />).
      </t>
      <t>
        For example, a request for the non-existing name a.example.com would
        cause the following NSEC record to be generated (in DNS presentation
        format):
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
          a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
        ]]></artwork>

      <t>
        The NSEC record MUST have corresponding RRSIGs generated.
      </t>
    </section>

    <section anchor="response-nodata" numbered="true" toc="default">
      <name>Responses for Non-Existent Types</name>
      <t>
        When the authoritative server receives a query for a name
        that exists, but has no resource record sets associated with
        the queried type, it generates a NODATA response, with
        a dynamically constructed signed NSEC record in the Authority
        Section. The owner name of the NSEC record matches the queried
        name. The Next Domain Name field is set to the immediate lexicographic
        successor of the QNAME. The Type Bitmaps field lists the available
        Resource Record types at the name.
      </t>
      <t>
        An Empty Non-Terminal is a special subset of this category,
        where the name has no resource record sets of any type (but
        has descendant names that do). For a query for an Empty
        Non-Terminal, the NSEC type bitmap will only contain RRSIG
        and NSEC. (Note that this is substantially different than the
        ENT response in precomputed NSEC, where the NSEC record has the
        same type bitmap, but "covers" rather than matches the ENT, and
        has the Next Domain Name field set to the next lexicographic
        descendent of the ENT in the zone.)
      </t>
    </section>

    <section anchor="response-wildcard" numbered="true" toc="default">
      <name>Responses for Wildcard Matches</name>
      <t>
        For wildcard matches, the authoritative server will provide
        a dynamically signed response that claims that the queried
        name exists explicitly. Specifically, the answer RR set will
        have an RRSIG record demonstrating an exact match (i.e. the
        label count in the RRSIG RDATA will be equal to the number of
        labels in the query name minus the root label). This obviates
        the need to include an NSEC record in the Authority section
        of the response that shows that no closer match than the wildcard
        was possible.
      </t>
      <t>
        For a Wildcard NODATA match (where the queried name matches
        a wildcard but no data for the queried type exists), a response
        akin to a non-wildcard NODATA is returned. The Answer section
        is empty, and the Authority section contains a single NSEC
        record that matches the query name with a type bitmap
        representing the list of types available at the wildcard.
      </t>
    </section>

    <section anchor="response-nxname" numbered="true" toc="default">
      <name>Responses to explicit queries for NXNAME</name>
      <t>
        NXNAME is a meta type which should not appear anywhere in
        a DNS message apart from the NSEC type bitmap of a Compact
        Answer response for a non-existent name. If however a DNS
        server implementing this specification receives an explicit
        query for the NXNAME RR type, this section describes what the
        response should be.
      </t>
      <t>
        If an explicit query for the NXNAME RR type is received, the
        DNS server MUST return a Format Error (response code FORMERR).
        A resolver should not forward these queries upstream or attempt
        iterative resolution. Many DNS server implementations already
        return errors for all types in the meta and q-type range except
        those types that are already defined to support queries.
      </t>
      <t>
        Optionally, a DNS server MAY also include the following
        <xref target="RFC8914" /> Extended DNS Error Code in the
        response:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         INFO-CODE  Purpose
         30         Invalid Query Type
        ]]></artwork>
      <t>
        Note that this EDE code is generally applicable to any
        RR type that should not appear in DNS queries.
      </t>
    </section>

    </section>

    <section anchor="rcode" numbered="true" toc="default">
      <name>Response Code Restoration</name>
      <t>
        For non-existent names, implementations should try wherever
        possible, to preserve  the response code value of 3 (NXDOMAIN).
        This is generally possible for non-DNSSEC enabled queries,
        namely those which do not set the DNSSEC_OK EDNS flag (DO bit).
        For such queries, authoritative servers implementing Compact Denial
        of Existence could return a normal NXDOMAIN response. There may
        be limited benefit to doing this however, since most modern DNS
        resolvers are DNSSEC-aware, and by <xref target="RFC3225" />
        Section 3, DNSSEC-aware recursive servers are required to set
        the DO bit on outbound queries, regardless of the status of the
        DO bit on incoming requests.
      </t>
      <t>
        A validating resolver that understands the NXNAME signal from an
        authoritative server could modify the response code from NOERROR
        to NXDOMAIN in responses they return to downstream queriers that
        have not set the DO bit in their requests.
      </t>

      <section anchor="signaled-rcode" numbered="true" toc="default">
        <name>Signaled Response Code Restoration</name>
        <t>
          This section describes an optional but recommended scheme
          to permit signaled restoration of the NXDOMAIN RCODE for
          DNSSEC enabled responses. A new
          <xref target="RFC6891">EDNS0</xref> header flag is defined
          in the 2nd most significant bit of the flags field in the EDNS0
          OPT header. This flag is referred to as the
          "Compact Answers OK (CO)" flag.
        </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|CO|                 Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        ]]></artwork>
        <t>
          When this flag is sent in a query by a resolver, it indicates
          that the resolver will accept a signed NXNAME enhanced
          NODATA response for a non-existent name together with the
          response code field set to NXDOMAIN (3).
        </t>
        <t>
          In responses to such queries, a Compact Denial authoritative
          server implementing this signaling scheme, will set the Compact
          Answers OK EDNS header flag, and for non-existent names will
          additionally set the response code field to NXDOMAIN.
        </t>
        <t>
          EDNS is a hop by hop signal, so resolvers will need to
          record the presence of this flag in associated cache data
          and respond to downstream DNSSEC enabled queriers
          appropriately. If the querier does not set the Compact
          Answers OK flag, the resolver will need to reset the
          response code back to NOERROR (0) for an NXNAME response.
        </t>
      </section>

    </section>

    <section anchor="operational" numbered="true" toc="default">
      <name>Operational Implications</name>
      <t>
        For DNSSEC enabled queries, a signed zone at an authoritative
        server implementing Compact Answers will never return a response
        with a response code of NXDOMAIN, unless they have implemented
        the optional response code restoration feature described in
        <xref target="signaled-rcode"/>. Similarly, resolvers not
        implementing this feature will also not be able to return NXDOMAIN.
        In the absence of this, tools that rely on accurately determining
        non-existent names will need to infer them from the presence of
        the NXNAME RR type in the type bitmap of the NSEC record in NODATA
        responses from these servers.
      </t>
      <t>
        Address lookup functions typically invoked by applications
        may need to do more work when dealing with implementations of
        Compact Answers. For example, a NODATA response to the lookup
        of an AAAA record for a non-existent name, can cause such
        functions to issue another query at the same name for an A record.
        Whereas an NXDOMAIN response to the first query would suppress
        additional queries for other types at that name. Address lookup
        functions could be enhanced to issue DNSSEC enabled queries and
        to examine the NSEC type bitmaps in responses to accurately
        determine non-existent names.
      </t>
      <t>
        Protocol optimizations that enable DNS resolvers to synthesize
        NXDOMAIN or wildcard responses, like <xref target="RFC8020" /> and
        <xref target="RFC8198" />, cannot be realized from responses
        that use Compact Denial of Existence. In general, no online signing
        scheme that employs minimally covering NSEC records (including this
        one) permits RFC 8198 style NXDOMAIN or wildcard response
        synthesis. Additionally, this protocol also precludes RFC 8020
        style NXDOMAIN synthesis for DNSSEC enabled responses.
      </t>
    </section>

    <section anchor="updates" numbered="true" toc="default">
      <name>Updates to RFCs</name>

      <section anchor="updates4034" title="Updates to RFC 4034">
        <t>
          <xref target="RFC4034" /> Section 4.1.2, The Type Bit Maps Field,
          states the following:
        </t>
        <ul>
        <li>
          Bits representing pseudo-types MUST be clear, as they do not appear
          in zone data.  If encountered, they MUST be ignored upon being read.
        </li>
        </ul>
        <t>
          This paragraph is updated to the following:
        </t>
        <ul>
        <li>
          Bits representing pseudo-types MUST be clear, as they do not appear
          in zone data.  If encountered, they MUST be ignored upon being read.
          There is one exception to this rule for Compact Denial of Existence
          (RFC TBD), where the NXNAME pseudo-type is allowed to appear in
          responses to non-existent names.
        </li>
        </ul>
        <t>
          Note: as a practical matter, no known resolver insists that
          pseudo-types must be clear in the NSEC type bitmap, so this
          restriction (prior to its revision) has posed no problem for
          the deployment of this mechanism.
        </t>
      </section>

      <section anchor="updates4035" title="Updates to RFC 4035">
        <t>
          <xref target="RFC4035" /> Section 2.3, Including NSEC RRs in a Zone,
           states the following:
        </t>
        <ul>
        <li>
          An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
          RRset at any particular owner name.  That is, the signing process
          MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
          the owner name of any RRset before the zone was signed.  The main
          reasons for this are a desire for namespace consistency between
          signed and unsigned versions of the same zone and a desire to reduce
          the risk of response inconsistency in security oblivious recursive
          name servers.
        </li>
        </ul>
        <t>
          This paragraph is updated to the following::
        </t>
        <ul>
        <li>
          An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
          RRset at any particular owner name.  That is, the signing process
          MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
          the owner name of any RRset before the zone was signed.  The main
          reasons for this are a desire for namespace consistency between
          signed and unsigned versions of the same zone and a desire to reduce
          the risk of response inconsistency in security oblivious recursive
          name servers. This concern only applies to implementations of DNSSEC
          that employ pre-computed signatures. There is an exception to this
          rule for online signing implementations of DNSSEC (e.g Minimally
          Covering NSEC, and Compact Denial of Existence (RFC TBD), where
          dynamically generated NSEC records can be produced for owner names
          that don't exist or are empty non-terminals.
        </li>
        </ul>
      </section>
    </section>

    <section anchor="implementation" numbered="true" toc="default">
      <name>Implementation Status</name>
      <t>
        Cloudflare, NS1, and Amazon Route53 currently implement the
        Compact Denial of Existence method. From early 2021 until
        November 2023, NS1 had deployed the Empty Non-Terminal
        distinguisher <xref target="ENT-SENTINEL" format="default"/>
        using the private RR type code 65281. A version of the
        NXNAME distinguisher using the private RR type code 65238
        was deployed by both Cloudflare (from July 2023) and NS1
        (from November 2023) until roughly September 2024. Since
        September 2024 both Cloudflare and NS1 have deployed NXNAME
        using the officially allocated code point of 128. At the
        current time, there are only prototype implementations of the
        signaled rcode restoration scheme.
      </t>
    </section>

    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        Online signing of DNS records requires authoritative servers
        for the DNS zone to have access to the private signing keys.
        Exposing signing keys on Internet reachable servers makes them
        more vulnerable to attack.
      </t>
      <t>
        Additionally, generating signatures on-demand is more
        computationally intensive than returning pre-computed
        signatures. Although the Compact Answers scheme reduces the
        number of online signing operations compared to previous
        techniques like White Lies, it still may make authoritative
        servers more vulnerable to computational denial of service
        attacks than pre-computed signatures. The use of signature
        algorithms (like those based on Elliptic Curves) that have
        a comparatively low cost for signing is recommended.
      </t>
      <t>
        Some security tools rely on detection of non-existent
        domain names by examining the response code field of DNS
        response messages. A NOERROR code in that field rather than
        NXDOMAIN will impact such tools. Implementation of the
        optional response code restoration scheme will help recover
        NXDOMAIN visibility for these tools. Note that the DNS
        header is not cryptographically protected, so the response
        code field cannot be authenticated. Thus inferring the status
        of a response from signed data in the body of the DNS message
        is actually more secure. These tools could be enhanced to
        recognize the (signed) NXNAME signal.
      </t>
      <t>
        Because this method does not allow for aggressive negative
        caching among resolvers, it allows for certain types
        of denial-of-service attacks to be more effective. This
        includes so-called Water Torture attacks, where random names
        are queried, either directly via botnets or across a wide
        range of public resolver services, in order to intentionally
        generate non-existence responses from the authoritative
        servers for a domain. If the resolver cannot synthesize NXDOMAIN
        responses from NSEC records, it must pass all queries on to the
        domain's authority servers, making resource exhaustion more likely
        at those latter servers, if those servers do not have the capacity
        to absorb those additional queries.
      </t>
      <t>
        If the motivating aspects of this specification (minimizing
        response size and computational costs) are not a concern,
        DNSSEC deployments can opt for a different method (e.g.
        traditional online signing or pre-computed signatures),
        and avoid imposing the challenges of NXDOMAIN visibility.
      </t>
    </section>

    <section anchor="acks" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>
        The Compact Answers technique (then called "Black Lies") was
        originally proposed in
        <xref target="BLACK-LIES" format="default"/> by Filippo Valsorda
        and Olafur Gudmundsson, and implemented by Cloudflare. The Empty
        Non-Terminal distinguisher RR type was originally proposed in
        <xref target="ENT-SENTINEL" format="default"/> by Shumon Huque,
        and deployed by NS1.
        The NXNAME type is based on the FDOM type proposed in
        <xref target="NXDOMAIN-TYPE" format="default"/> by Gudmundsson
        and Valsorda.
      </t>
      <t>
        Especially detailed discussions on many technical aspects of this
        document were conducted with Paul Vixie, Jan Vcelak, Viktor Dukhovni,
        and Ed Lewis. The authors would also like to thank the many other
        members of the IETF DNS Operations working group for helpful
        comments and discussions.
      </t>
    </section>

    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        IANA has done or is requested to do the following:
      </t>
      <t>
        Done: Allocate a new DNS Resource Record type
        code for NXNAME in the DNS parameters registry, from the meta type
        range. Specifically, the lowest available number (currently 128)
        in the meta range is requested to be allocated. A lower number
        lowers the size of the type bitmap, which reduces the size of the
        DNS response message.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         Type    Value  Meaning
         NXNAME  128  NXDOMAIN indicator for Compact Denial of Existence
        ]]></artwork>
      <t>
        Allocate the "Compact Answers OK" flag in the EDNS header, as
        described in <xref target="signaled-rcode"/>.
      </t>
      <t>
        Done: Allocate a code point for the "Invalid Query Type" Extended
        DNS Error in the DNS parameters registry, as described in
        <xref target="response-nxname"/>. Specifically code point 30 has
        been allocated.
      </t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4470.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7129.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4471.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/>
      <reference anchor="BLACK-LIES"
                 target="https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies">
        <front>
          <title>Compact DNSSEC Denial of Existence or Black Lies</title>
          <author fullname="Filippo Valsorda" initials="F" surname="Valsorda" />
          <author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsson" />
          <date />
        </front>
      </reference>
      <reference anchor="ENT-SENTINEL"
                 target="https://www.ietf.org/archive/id/draft-huque-dnsop-blacklies-ent-01.html">
        <front>
          <title>Empty Non-Terminal Sentinel for Black Lies</title>
          <author fullname="Shumon Huque" initials="S" surname="Huque" />
          <date />
        </front>
      </reference>
      <reference anchor="NXDOMAIN-TYPE"
                 target="https://tools.ietf.org/html/draft-ogud-fake-nxdomain-type/">
        <front>
          <title>Signaling NSEC record owner name nonexistence</title>
          <author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsson" />
          <author fullname="Filippo Valsorda" initials="F" surname="Valsorda" />
          <date />
        </front>
      </reference>
      </references>
    </references>

    <section anchor="other-approaches" numbered="true" removeInRFC="false"
        toc="include" pn="section-appendix.a">
      <name>Other Approaches</name>
      <t>
        In the past, some implementations of Compact Denial of Existence
        have used other means to differentiate NXDOMAIN from Empty
        Non-Terminals.
      </t>
      <t>
        One method employed by both Cloudflare and Amazon Route53 for
        a period of time was the following: for responses to Empty
        Non-Terminals, they synthesized the NSEC type bitmap to include
        all record types supported except for the queried type. This
        method has the undesirable effect of no longer being able to
        reliably determine the existence of ENTs, and of making the Type
        Bitmaps field larger than it needs to be. It also has the potential
        to confuse validators and others tools that infer type existence
        from the NSEC record.
      </t>
      <t>
        Another way to distinguish NXDOMAIN from ENT is to
        define the synthetic Resource Record type for ENTs instead,
        as specified in <xref target="ENT-SENTINEL" format="default"/>.
        This method was successfully deployed in the field by NS1 for a
        period of time. This typically imposes less work on the server
        since NXDOMAIN responses are a lot more common than ENTs. At the
        time it was deployed, it also allowed a common bitmap pattern
        ("NSEC RRSIG") to identify NXDOMAIN across this and other
        implementations that returned a broad bitmap pattern for Empty
        Non-Terminals. However, the advantage of the NXNAME RR type is
        that it explicitly identifies NXDOMAIN responses, and allows
        them to be distinguished conclusively from potential ENT responses
        in other online signing NSEC implementations.
      </t>
    </section>

  </back>

</rfc>