<?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. --> version="1.0" encoding="utf-8"?>

<!-- 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 [rfced] This document updates RFCs 4034 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 4035. Please review
the reference entries alphabetically -->
<!-- control vertical white space
     (using errata reported for these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- RFCs. We do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list believe that any are
relevant to the content of popular I-D processing instructions this document, but please confirm.

https://www.rfc-editor.org/errata_search.php?rfc=4034
https://www.rfc-editor.org/errata_search.php?rfc=4035
-->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-dnsop-compact-denial-of-existence-07" number="9824" 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 DNSSEC">Compact Denial of Existence in DNSSEC
    </title> DNSSEC</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-compact-denial-of-existence-07"/> name="RFC" value="9824"/>

    <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>
      <organization>Retired/Unaffiliated</organization>
      <address>
        <email>ogud@ogud.com</email>
      </address>
    </author>

    <date day="27" month="02" month="August" year="2025"/>
    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Internet-Draft</keyword>

    <area>OPS</area>
    <workgroup>dnsop</workgroup>

    <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>

<!-- [rfced] Abstract: Will readers understand "Such answers" in the second
sentence below? Answers are not mentioned in the first sentence (but
"response" is).

Original:
   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 minimally covering NSEC or NSEC3 record, allow
   online signing servers to minimize signing operations and response
   sizes, and prevent zone content disclosure.

Perhaps ("This technique"):
   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.  The technique
   requires only one minimally covering NSEC or NSEC3 record, allows
   online signing servers to minimize signing operations and response
   sizes, and prevents zone content disclosure.

Or ("Such responses"):
   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 responses
   require only one minimally covering NSEC or NSEC3 record, allow
   online signing servers to minimize signing operations and response
   sizes, and prevent zone content disclosure.
-->

     <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 minimally covering NSEC or NSEC3 record, allow online
       signing servers to minimize signing operations and response sizes,
       and prevent zone content disclosure.
     </t>
     <t>
       This document updates RFC RFCs 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"> anchor="intro">
      <name>Introduction and Motivation</name>
<!-- [rfced] We do not see "White Lies" mentioned in RFC 4470 (though NSEC and
online signing are mentioned). Are any updates needed?

Original:
   In the online
   signing model, described in NSEC and NSEC3 "White Lies" [RFC4470]
   [RFC7129], they are used to dynamically compute an epsilon function
   around the queried name.

Perhaps:
   In the online
   signing model, described in [RFC4470] and
   [RFC7129], they are used to dynamically compute an epsilon function
   around the queried name.

Or:
   In the online
   signing model, described for NSEC in [RFC4470] and for NSEC3 White Lies in
   [RFC7129], they are used to dynamically compute an epsilon function
   around the queried name.
-->

<!-- [rfced] Please review "at the name" and "at the same name" in these sentences. Are
these correct as it, or should these be updated to "for the name" and "for the
same name" (or something else)?

Original:
   A "Type Bit Maps" field in the data of the
   NSEC or NSEC3 record asserts which resource record types are present
   at the name.
   ...
   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 Bit Maps field.
   ...
   The Type
   Bit Maps field lists the available Resource Record types at the name.
   ...
   can cause such functions to issue another query at
   the same name for an A record.
-->
      <t>
        One of the functions of the Domain Name System DNS Security Extensions
        (DNSSEC) <xref target="RFC9364" /> is
        "Authenticated Denial
        "authenticated denial of Existence", 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 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 The Type Bit Maps" Maps field in the data
        of the NSEC or NSEC3 record asserts which resource record (RR) types are
        present at the name.
      </t>
      <t>
        The response for a non-existent name requires up to 2 two signed NSEC
        records or up to 3 three signed NSEC3 records (and for online signers,
        the associated cryptographic computation), computation) to prove that (1) the
        name did not explicitly exist in the zone, zone and (2) that it could
        not have been synthesized by a wildcard.
      </t>
<!-- [rfced] This text indicates that the technique described in this document
has two names ("Compact Denial of Existence" or "Compact Answers"), and
we see both used in the document. Would it be helpful to use one name
throughout the document? It seems that "Compact Denial of Existence" is
more common (and included in the document title). Let us know your
thoughts.

Original:
   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.
-->

<!-- [rfced] The first sentence below uses "has no resource records" while the
other two use "has no resource record sets" (note "sets"). Should these
be consistent?

Original:
   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.
   ...
   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.
   ...
   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).
-->

      <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 or NSEC3 record matching the queried name.
        This has two advantages: the 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 or NSEC3 records also prevents
        adversaries from enumerating the entire contents of DNS zones
        by walking the NSEC chain, chain or by performing an offline dictionary
        attack on the hashes in the NSEC3 chain.
      </t>
      <t>
        This document assumes a reasonable level of familiarity with DNS
        operations and protocol terms.  Much of the terminology is explained
        in further detail in "DNS Terminology" <xref target="RFC9499" />.
      </t>

      <section anchor="reserved-words"><name>Requirements Language</name>
      <t>The
        <t>
    The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>

    <section anchor="distinguish" numbered="true" toc="default"> anchor="distinguish">
      <name>Distinguishing non-existent names</name> Non-existent Names</name>
      <t>
        This method generates NODATA responses for non-existent names
        that don't match a DNS wildcard. Since there are clearly no
        record types for such names, the NSEC Type Bit Maps field in
        the response will only contain the "NSEC" NSEC and "RRSIG" RRSIG types
        (and in the case of NSEC3 NSEC3, the Type Bit Maps field will be empty).
        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
        Bit Maps field.
      </t>
      <t>
        This specification defines the use of a synthetic Resource Record RR
        type to signal the presence of a non-existent name. The
        mnemonic for this RR type is "NXNAME", 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

      <table>
	<thead>
	  <tr><th>TYPE</th><th>Value</th><th>Meaning</th></tr>
	</thead>
	<tbody>
          <tr><td>NXNAME</td><td>128</td><td>NXDOMAIN indicator for Compact Denial of Existence
        ]]></artwork> Existence</td></tr>
	</tbody>
      </table>

      <t>
        This RR type is added to the NSEC Type Bit Maps field for responses
        to non-existent names, in addition to the required RRSIG and
        NSEC types. If NSEC3 is being used, this RR type is the sole
        entry in the Type Bit Maps field. It is a "Meta-Type", "Meta-TYPE", as defined in
        <xref target="RFC6895" />, and it stores no data in a DNS zone, 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 ("Signaled Response Code Restoration) Restoration")
        to better restore NXDOMAIN visibility
        to various applications that may remain oblivious to the new
        NXNAME signal.
      </t>
    </section>

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

    <t>
    This section describes various types of answers generated by
    authoritative servers implementing Compact Denial of Existence
    using NSEC. <xref target="nsec3" /> describes changes needed to
    support NSEC3.
    </t>

    <section anchor="response-nxd" numbered="true" toc="default"> anchor="response-nxd">
      <name>Responses for Non-Existent 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) placed in the Authority section.
      </t>
      <t>
        The Next Domain Name field SHOULD <bcp14>SHOULD</bcp14> be set to the immediate
        lexicographic successor of the QNAME. This is accomplished by
        adding a leading label with a single null (zero-value) octet.
        The Type Bit Maps field MUST <bcp14>MUST</bcp14> only have the bits set for the
        following RR Types: RRSIG, NSEC, and NXNAME.
      </t>
      <t>
        For example, a request for the non-existing non-existent name "a.example.com."
        would result in the generation of the following NSEC record to be generated (in DNS
        presentation format):
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      <sourcecode type=""><![CDATA[
a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
        ]]></artwork>
]]></sourcecode>

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

    <section anchor="response-nodata" numbered="true" toc="default"> anchor="response-nodata">
      <name>Responses for Non-Existent Non-existent Types</name>
      <t>
        When the authoritative server receives a query for a name
        that exists, exists but has no resource record sets associated with
        the queried type, it generates a NODATA response, response with
        a dynamically constructed signed NSEC record in the Authority
        Section.
        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 Bit Maps field lists the available
        Resource Record
        RR 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 Bit Maps field 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, bitmap but "covers" rather than matches the ENT, ENT and
        has the Next Domain Name field set to the next lexicographic
        descendent
        descendant of the ENT in the zone.)
      </t>
    </section>

    <section anchor="response-wildcard" numbered="true" toc="default"> anchor="response-wildcard">
      <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 RRset 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 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 Bit Maps field
        representing the list of types available at the wildcard.
      </t>
    </section>

    <section anchor="response-referral" numbered="true" toc="default"> anchor="response-referral">
      <name>Responses for Unsigned Referrals</name>
      <t>
        Per the DNSSEC protocol, a referral to an unsigned subzone
        includes an NSEC record whose Owner Name owner name matches the subzone, subzone
        and which proves the delegation is unsigned by the absence of
        the DS RRtype Delegation Signer (DS) RR type bit in the Type Bit Maps field.
      </t>
      <t>
        With Compact Denial of Existence, the Next Domain Name field
        for this NSEC record is computed with a slightly different
        epsilon function than the immediate lexicographic successor of
        the Owner Name, owner name, as that name would then fall under the delegated
        subzone. Instead, the Next Domain Name field is formed by appending
        a zero octet to the first label of the Owner Name. owner name.
      </t>
      <t>
        For example, a referral response for the subzone sub.example.com
        would include an NSEC record like the following:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      <sourcecode type=""><![CDATA[
sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC
        ]]></artwork>
]]></sourcecode>

    </section>

    <section anchor="response-nxname" numbered="true" toc="default"> anchor="response-nxname">
      <name>Responses to explicit queries Explicit Queries for NXNAME</name>
      <t>
        NXNAME is a meta type which Meta-TYPE that 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 However, if 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 <bcp14>MUST</bcp14> 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 for Meta-TYPEs and QTYPEs, except
        those types that are already defined to support queries.
      </t>
      <t>
        Optionally, a DNS server MAY <bcp14>MAY</bcp14> also include the following
        <xref target="RFC8914" />
         Extended DNS Error (EDE) Code code <xref target="RFC8914" /> in the
        response:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         INFO-CODE  Purpose
         30         Invalid
      <table>
	<thead>
	  <tr><th>INFO-CODE</th><th>Purpose</th></tr>
	</thead>
	<tbody>
          <tr><td>30</td><td>Invalid Query Type
        ]]></artwork> Type</td></tr>
	</tbody>
      </table>
      <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="nsec3" numbered="true" toc="default"> anchor="nsec3">
      <name>Generating Responses with NSEC3</name>
      <t>
        The
        NSEC3 protocol <xref target="RFC5155" /> uses hashed names to
        provide zone enumeration defense. This protection is already better
        provided by minimally covering NSEC records. NSEC3's Opt-Out feature
        also provides no specific benefit for online signing implementations
        (minimally covering NSEC3 records provide no useful Opt-Out span).
        Hence, there is no known advantage to implementing Compact Denial
        of Existence with NSEC3. However, an existing implementation of
        traditional NSEC3 online signing migrating to Compact Denial of
        Existence may find it simpler to do so with NSEC3 rather than implementing
        NSEC from scratch.
      </t>
      <t>
        For NSEC3, the functional details of the protocol remain as
        described in <xref target="responses"/>, with the following
        changes:
        changes.
      </t>
      <t>
        NSEC3 records and their signatures are dynamically generated
        instead of NSEC.
      </t>
      <t>
        The NSEC3 parameters should be set to algorithm 1, a flags field
        of 0, an additional hash iteration count of 0, and an empty salt.
        In DNS presentation format, this is "1 0 0 -".
      </t>
      <t>
        The Owner Name owner name of the NSEC3 resource record is the NSEC3 hash of
        the relevant domain name, encoded in Base32 with Extended Hex
        Alphabet (<xref target="RFC4648"/>, Section 7), target="RFC4648" sectionFormat="comma" section="7"/>), prepended as a
        single label to the name of the zone. The Next Hashed Owner Name
        is the immediate name successor of the unencoded binary form of
        the previous hash, which can be computed by adding one to the
        binary hash value.
      </t>
      <t>
        In responses for non-existent names, the Type Bit Maps field will
        contain only the NXNAME meta-type. Meta-TYPE. In responses to Empty Non-Terminal
        names, the Type Bit Maps field will be empty.
      </t>
      <t>
        For example, a request for the non-existent name "a.example.com."
        would result in the generation of the following NSEC3 record to be generated: record:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      <sourcecode type=""><![CDATA[
H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
                  H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )
        ]]></artwork>
]]></sourcecode>

<!-- [rfced] In the sentence below, is "next name field" correct? We see
"Next Hashed Owner Name field" and "Next Domain Name field" elsewhere in
the document.

Original:
   Unlike Compact Denial of Existence with NSEC, no special form of the
   next name field for unsigned referrals is needed.
-->

      <t>
        Unlike Compact Denial of Existence with NSEC, no special form of
        the next name field for unsigned referrals is needed. The Hashed
        Next Hashed Owner Name field remains the NSEC3 hash of original owner
        name plus one.
      </t>
    </section>

    <section anchor="rcode" numbered="true" toc="default"> anchor="rcode">
      <name>Response Code Restoration</name>

<!-- [rfced] We do not see "DNSSEC_OK" in past RFCs. The IANA registry at
<https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13>
uses "DNSSEC answer OK". May we update this sentence in one of the
following ways?

Original:
   This is
   generally possible for non-DNSSEC enabled queries, namely those which
   do not set the DNSSEC_OK EDNS flag (DO bit).

Perhaps:
   This is
   generally possible for non-DNSSEC enabled queries, namely those that
   do not set the EDNS header flag "DNSSEC answer OK" (DO bit).

Or:
   This is
   generally possible for non-DNSSEC enabled queries, namely those that
   do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header.
-->

      <t>
        For non-existent names, implementations should try wherever
        possible,
        to preserve the response code value of 3 (NXDOMAIN). (NXDOMAIN) whenever possible.  This is
        generally possible for non-DNSSEC enabled non-DNSSEC-enabled queries, namely those which that
        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 However, there may be limited benefit to
        doing this however, since most modern DNS resolvers are DNSSEC-aware, DNSSEC aware,
        and by per <xref target="RFC3225" />
        Section 3, sectionFormat="of" 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"> anchor="signaled-rcode">
        <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
          DNSSEC-enabled responses. A new EDNS0
          <xref target="RFC6891">EDNS0</xref> target="RFC6891"></xref> header flag is defined
          in the 2nd second most significant bit of the flags field in the EDNS0
          OPT header. This flag is referred to as the
          "Compact
          Compact Answers OK (CO)" (CO) flag.
        </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
          +0 (MSB)                +1 (LSB)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: |   EXTENDED-RCODE      |       VERSION         |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|CO|                 Z                       |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork>
        <t>

<!-- [rfced] Will "signed NXNAME enhanced NODATA response" be clear to
readers?

Original:
   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>

Perhaps:
   When this flag is sent in a query by a resolver, it indicates that
   the resolver will accept a NODATA response with a signed NXNAME for
   a non-existent name together with the response code field set to
   NXDOMAIN (3).
-->

      <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>

<!-- [rfced] Please review "a Compact Denial authoritative server". Is the
intended meaning "an authoritative server implementing Compact Denial of
Existence"?

Original:
   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.

Perhaps:
   In responses to such queries, an authoritative server
   implementing both Compact Denial of Existence and 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>
          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 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 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"> anchor="operational">
      <name>Operational Implications</name>
      <t>
        For DNSSEC enabled 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 Bit Maps field 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 a AAAA record for a non-existent name, name can cause such
        functions to issue another query at the same name for an A record.
        Whereas record,
        whereas an NXDOMAIN response to the first query could suppress
        additional queries for other types at that name. Address lookup
        functions could be enhanced to issue DNSSEC enabled DNSSEC-enabled queries and
        to examine the NSEC Type Bit Maps field in responses to accurately
        determine non-existent names. Note that this is less of a concern
        with
        connection functions like Happy Eyeballs <xref target="RFC8305" /> that typically issue back-to-back DNS queries without
        waiting for individual responses.
      </t>

<!-- [rfced] We updated the following sentences to avoid using RFC number or
citation as an adjective. Specifically, we updated the following phrases:
"Happy Eyeballs [RFC8305] style", "RFC 8198 style", and "RFC 8020
style". Please review to ensure that the updates accurately convey the
intended meaning.

Original:
   Note that this
   is less of a concern with Happy Eyeballs [RFC8305] style of
   connection functions that typically issue back to back DNS queries
   without waiting for individual responses.
      </t>
   ...
   In general, no online signing scheme that employs minimally covering
   NSEC or NSEC3 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.

Perhaps:
   Note that this
   is less of a concern with connection functions like Happy Eyeballs
   [RFC8305] that typically issue back-to-back DNS queries without
   waiting for individual responses.
   ...
   In general, no online signing scheme that employs
   minimally covering NSEC or NSEC3 records (including this one) permits
   NXDOMAIN or wildcard response synthesis in the style described in
   [RFC8198].  Additionally, this protocol also precludes NXDOMAIN
   synthesis for DNSSEC-enabled responses in the style described in
   [RFC8020].
-->

      <t>
        Protocol optimizations that enable DNS resolvers to synthesize
        NXDOMAIN or wildcard responses, like those described in <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 or NSEC3 records
        (including this one) permits RFC 8198 style NXDOMAIN or wildcard
        response synthesis. synthesis in the style described in <xref target="RFC8198" />. Additionally, this protocol also precludes
        RFC 8020 style
        NXDOMAIN synthesis for DNSSEC enabled responses. DNSSEC-enabled responses in the style described in <xref target="RFC8020" />.
      </t>
    </section>

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

<!-- [rfced] Should the instances of "Type Bit Maps" in the following
sentences be updated to "Type Bit Maps field"? Or are these correct as
they are?

Original:
   Note: as a practical matter, no known resolver insists that pseudo-
   types must be clear in the NSEC Type Bit Maps, so this restriction
   (prior to its revision) has posed no problem for the deployment of
   this mechanism.
   ...
   ...for responses to Empty Non-
   Terminals, they synthesized the NSEC Type Bit Maps to include all
   record types supported except for the queried type.
-->

      <section anchor="updates4034" title="Updates to RFC 4034">
        <t>
          <xref
        <t><xref target="RFC4034" /> Section 4.1.2, The sectionFormat="of" section="4.1.2"/>
        ("The Type Bit Maps Field, Field") states the following:
        </t>
        <ul>
        <li>
          Bits following:</t>

	<blockquote>
          <t>Bits representing pseudo-types MUST <bcp14>MUST</bcp14> be clear, as they do not appear
          in zone data.  If encountered, they MUST <bcp14>MUST</bcp14> be ignored upon being read.
        </li>
        </ul>
        <t>
          This read.</t>
	</blockquote>

        <t>This paragraph is updated to the following:
        </t>
        <ul>
        <li> following:</t>

<!-- [rfced] We use the <blockquote> element for OLD/NEW text. We have
included both the first paragraph and the note below within the <blockquote>
element. Please confirm that this is correct. If the note should not be
part of the updated text, we will adjust the <blockquote> element
accordingly.

Original:
   *  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 Bit Maps, so this restriction
   (prior to its revision) has posed no problem for the deployment of
   this mechanism.
-->

<blockquote>
          <t>Bits representing pseudo-types <bcp14>MUST</bcp14> be clear, as
          they do not appear in zone data.  If encountered, they
          <bcp14>MUST</bcp14> be ignored upon being read.  There is one
          exception to this rule for Compact Denial of Existence (RFC 9824),
          where the NXNAME pseudo-type is allowed to appear in responses to
          non-existent names.</t>

       <t>
          Note: As a practical matter, no known resolver insists that
          pseudo-types must be clear in the NSEC Type Bit Maps, so this
          restriction (prior to its revision) has posed no problem for
          the deployment of this mechanism.
       </t>
	</blockquote>

      </section>

      <section anchor="updates4035" title="Updates anchor="updates4035">
	<name>Updates to RFC 4035">
        <t>
          <xref 4035</name>
        <t><xref target="RFC4035" /> Section 2.3, Including sectionFormat="of" section="2.3"/>
        ("Including NSEC RRs in a Zone, Zone") states the following:
        </t>
        <ul>
        <li>
          An following:</t>

	<blockquote>

          <t>An NSEC record (and its associated RRSIG RRset) MUST NOT <bcp14>MUST
          NOT</bcp14> be the only RRset at any particular owner name.  That
          is, the signing process
          MUST NOT <bcp14>MUST NOT</bcp14> 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> servers.</t>
	</blockquote>

        <t>
          This paragraph is updated to the following:: following:
        </t>
        <ul>
        <li>
          An

	<blockquote>
          <t>An NSEC record (and its associated RRSIG RRset) MUST NOT <bcp14>MUST NOT</bcp14> be the only
          RRset at any particular owner name.  That is, the signing process
          MUST NOT
          <bcp14>MUST NOT</bcp14> 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 precomputed signatures. There is an exception to this
          rule for online signing implementations of DNSSEC (e.g., Minimally
          Covering NSEC, minimally
          covering NSEC and Compact Denial of Existence), where
          dynamically generated NSEC records can be produced for owner names
          that don't exist or are empty non-terminals.
        </li>
        </ul> non-terminals.</t>
	</blockquote>

      </section>
    </section>

    <section anchor="security" numbered="true" toc="default"> anchor="security">
      <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 Internet-reachable servers makes them
        more vulnerable to attack.
      </t>
      <t>
        Additionally, generating signatures on-demand on demand is more
        computationally intensive than returning pre-computed precomputed
        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 denial-of-service
        attacks than pre-computed precomputed signatures. The use of signature
        algorithms (like those based on Elliptic Curves) 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 (rather than
        NXDOMAIN) 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 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 Pseudorandom Subdomain Attacks
        <xref target="PRSD-ATTACK" format="default"/>, 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 non-existent 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 if they 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), precomputed 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 anchor="iana">
      <name>IANA Considerations</name>

<!-- [rfced] Table 1 and Olafur Gudmundsson, 3 are identical, as are Tables 2 and implemented by Cloudflare. The Empty
        Non-Terminal distinguisher RR type was originally proposed 5. We suggest
removing Tables 1 and 2 (and leaving the tables in
        <xref target="ENT-SENTINEL" format="default"/> by Shumon Huque, the IANA section) and deployed by NS1.
        The NXNAME type is based on
updating the FDOM type proposed text in
        <xref target="NXDOMAIN-TYPE" format="default"/> by Gudmundsson Sections 2 and Valsorda.
      </t>
      <t>
        Especially detailed discussions on many technical aspects of 3.5 as follows. Would this
        document were conducted with Paul Vixie, Jan Vcelak, Viktor Dukhovni,
        Ed Lewis, and John Levine. be acceptable?

Current (Section 2)
   This specification defines the use of a synthetic resource record
   type to signal the presence of a non-existent name.  The authors would also like mnemonic for
   this RR type is NXNAME, chosen to thank clearly distinguish it from the many other members
   response code mnemonic NXDOMAIN.

Perhaps:
   This specification defines the use of NXNAME (128), a synthetic resource record
   type to signal the IETF DNS Operations working group presence of a non-existent name. See Section 9. The mnemonic for helpful comments and discussions.
      </t>
    </section>

    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        IANA
   this RR type is requested NXNAME, chosen to do clearly distinguish it from the following:
      </t>
      <t>
        Allocate
   response code mnemonic NXDOMAIN.

Current (Section 3.5):
   Optionally, a new DNS Resource Record type server MAY also include the following Extended DNS
   Error (EDE) code for NXNAME from [RFC8914] in the response:

Perhaps:
   Optionally, a DNS server MAY also include the following Extended DNS
   Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type). See Section 9.
-->

      <t>
        IANA has allocated the following in
        the "Resource Record (RR) Types" TYPEs" registry in the "DNS parameters" "Domain Name System (DNS) Parameters"
        registry group, from the meta type range. Specifically, the lowest
        available number (currently 128) in the meta types range is
        requested to be allocated. for Meta-TYPEs.
        A lower number in this range lowers the size of the
        Type Bit Maps field, which reduces the overall size of the DNS
        response message.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         Type    Value  Meaning
         NXNAME  128  NXDOMAIN
      <table>
	<thead>
          <tr><th>Type</th><th>Value</th><th>Meaning</th><th>Reference</th></tr>
	</thead>
	<tbody>
          <tr>
	    <td>NXNAME</td>
	    <td>128</td>
	    <td>NXDOMAIN indicator for Compact Denial of Existence
        ]]></artwork> Existence</td>
	    <td>RFC 9824</td>
	  </tr>
	</tbody>
      </table>

      <t>
        Allocate
        IANA has also allocated the "Compact Answers OK" following flag in the "EDNS Header Flags
        (16 bits)" registry in the "Domain Name System (DNS) Parameters"
        registry group. Set the Flag field to "CO", as This flag is described in <xref target="signaled-rcode"/>.
      </t>
<table anchor="blah">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Flag</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Bit 1</td>
      <td>CO</td>
      <td>Compact Answers OK</td>
      <td>RFC 9824</td>
    </tr>
  </tbody>
</table>

      <t>
        Allocate a
        Last, IANA has allocated the following code point for "Invalid Query Type" in the
        "Extended DNS Error Codes" registry in the "Domain Name System
        (DNS) Parameters" registry group, as group. This code point is described in
        <xref target="response-nxname"/>.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         INFO-CODE  Purpose
         30         Invalid
      <table>
	<thead>
          <tr>
	  <th>INFO-CODE</th>
	  <th>Purpose</th>
	  <th>Reference</th>
	  </tr>
	</thead>
	<tbody>
          <tr>
	  <td>30</td>
	  <td>Invalid Query Type
        ]]></artwork> Type</td>
	  <td>RFC 9824</td></tr>
	</tbody>
      </table>

    </section>

  </middle>

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

  <back>
    <displayreference target="I-D.valsorda-dnsop-black-lies" to="BLACK-LIES"/>
    <displayreference target="I-D.huque-dnsop-blacklies-ent" to="ENT-SENTINEL"/>
    <displayreference target="I-D.ogud-fake-nxdomain-type" to="NXDOMAIN-TYPE"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3225.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4470.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4470.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> href="https://bib.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.7129.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7129.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
<!-- [BLACK-LIES] Long Way due to author name
draft-valsorda-dnsop-black-lies-00
IESG State: Expired as of 04/12/25
-->
<reference anchor="BLACK-LIES"
                 target="https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies"> anchor="I-D.valsorda-dnsop-black-lies" target="https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00">
<front>
<title>Compact DNSSEC Denial of Existence or Black Lies</title>
<author fullname="Filippo Valsorda" initials="F" surname="Valsorda" /> initials="F." surname="Valsorda">
<organization>CloudFlare Inc.</organization>
</author>
<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" /> initials="O." surname="Gudmundsson">
<organization>CloudFlare Inc.</organization>
</author>
<date /> day="21" month="March" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-valsorda-dnsop-black-lies-00"/>
</reference>
<!-- [ENT-SENTINEL]
draft-huque-dnsop-blacklies-ent-01
IESG State: Expired as of 04/12/25
-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.huque-dnsop-blacklies-ent.xml"/>

<!-- [NXDOMAIN-TYPE] Long Way due to author name
draft-ogud-fake-nxdomain-type-00
IESG State: Expired as of 04/12/25
-->
<reference anchor="NXDOMAIN-TYPE"
                 target="https://tools.ietf.org/html/draft-ogud-fake-nxdomain-type/"> anchor="I-D.ogud-fake-nxdomain-type" target="https://datatracker.ietf.org/doc/html/draft-ogud-fake-nxdomain-type-00">
<front>
<title>Signaling NSEC record owner name nonexistence</title>
<author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsson" /> initials="O." surname="Gudmundsson">
<organization>CloudFlare Inc.</organization>
</author>
<author fullname="Filippo Valsorda" initials="F" surname="Valsorda" /> initials="F." surname="Valsorda">
<organization>CloudFlare Inc.</organization>
</author>
<date /> day="7" month="May" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ogud-fake-nxdomain-type-00"/>
</reference>

      <reference anchor="PRSD-ATTACK"
                 target="https://conference.apnic.net/data/39/dnswatertortureonqtnet_1425130417_1425507043.pptx">
        <front>
          <title>Water Torture: A Slow Drip DNS DDoS Attack on QTNet</title>
          <author fullname="Kei Nishida" initials="K" surname="Nishida" />
          <date />
        </front>
      </reference>
      </references>
    </references>

    <section anchor="other-approaches" numbered="true" removeInRFC="false"
        toc="include" pn="section-appendix.a"> anchor="other-approaches">
      <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 For responses to Empty
        Non-Terminals, they synthesized the NSEC Type Bit Maps 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, ENTs and of making the Type
        Bit Maps 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 RR type for ENTs instead,
        as specified in <xref target="ENT-SENTINEL" target="I-D.huque-dnsop-blacklies-ent" 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, responses and allows
        them to be distinguished conclusively from potential ENT responses
        in other online signing NSEC implementations.
      </t>
    </section>

    <section anchor="implementations" numbered="true" removeInRFC="false"
        toc="include" pn="section-appendix.b"> anchor="implementations">
      <name>Historical Implementation Notes</name>
      <t>
        At the time of publication, the basic Compact Denial of Existence
        method using NSEC is implemented by Cloudflare, NS1, Amazon Route53,
        and Knot DNS's optional online signing module. From early 2021 until
        November 2023, NS1 had deployed the Empty Non-Terminal distinguisher
        <xref target="ENT-SENTINEL" target="I-D.huque-dnsop-blacklies-ent" 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 2024, both Cloudflare and NS1 have
        deployed NXNAME using the officially allocated code point of 128.
        Oracle Cloud Initiative implemented Compact Denial of Existence
        using NSEC3 in October 2024.
      </t>
    </section>

    <section anchor="acks" numbered="false">
      <name>Acknowledgements</name>
      <t>The Compact Answers technique (then called "Black Lies") was
      originally proposed in <xref target="I-D.valsorda-dnsop-black-lies"
      format="default"/> by <contact fullname="Filippo Valsorda"/> and
      <contact fullname="Olafur Gudmundsson"/> and implemented by
      Cloudflare. The Empty Non-Terminal distinguisher RR type was originally
      proposed in <xref target="I-D.huque-dnsop-blacklies-ent"
      format="default"/> by <contact fullname="Shumon Huque"/> and deployed by
      NS1.  The NXNAME type is based on the FDOM type proposed in <xref
      target="I-D.ogud-fake-nxdomain-type" format="default"/> by Gudmundsson
      and Valsorda.</t>
      <t>Especially detailed discussions on many technical aspects of this
      document were conducted with <contact fullname="Paul Vixie"/>, <contact
      fullname="Jan Včelák"/>, <contact fullname="Viktor Dukhovni"/>, <contact
      fullname="Ed Lewis"/>, and <contact fullname="John Levine"/>. 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>

  </back>

<!-- [rfced] We updated <artwork> to <sourcecode> for the following:

Original:
  a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME

  sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC

    H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
                      H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )

Please review whether the "type" attribute should be set for sourcecode
elements in the XML file. If the current list of preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not
contain an applicable type, then feel free to suggest a new one.  Also, it is
acceptable to leave the "type" attribute not set.
-->

<!-- [rfced] Terminology

a) FYI - We updated the following forms to "Meta-TYPEs" per usage in RFCs 5155
and 6895 (normatively referenced in this document):

meta type
Meta-Type
meta-type

b) We see the following forms in the document. We updated to the latter. Let us
know any concerns.

Hashed Next Owner Name vs. Next Hashed Owner Name
  Note: Per RFC 5155.

Owner Name vs. owner name
  Note: Per RFCs 4034 and 4035.

c) We see the following forms in the document. Are any updates needed for
consistency?

Type Bit Maps field
NSEC Type Bit Maps field

d) If no objections, we will remove the hyphen from "non-existent" per the
Merriam Webster dictionary (https://www.merriam-webster.com/dictionary/nonexistent).
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansion(s) for the following abbreviation(s)
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Delegation Signer (DS)

b) The following are used throughout the document. If no objections, we will
update to use the abbreviation after the expansion upon first use.

Empty Non-Terminal
empty non-terminal
ENT

c) We see instances of both "queried name" and "QNAME" in the document, with
one instance of QNAME as the abbreviation of "queried name" (see below). Would it
be helpful to update all instances of "queried name" to "QNAME"? We note that
QNAME is defined in RFC 9499, but "queried name" is not.

Original:
   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) placed in the Authority section.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

For example, please consider whether the following should be updated:
term A, term B, term C, etc.

White Lies
Black Lies

In addition, please consider whether the two instances of "traditional" should
be updated for clarity.  While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Traditional" is a subjective term, as it is not the same for everyone.

Original:
   However, an existing implementation of
   traditional NSEC3 online signing migrating to Compact Denial of
   Existence may find it simpler to do so with NSEC3 than implementing
   NSEC from scratch.
   ...
   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.
-->

</rfc>