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

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<?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-huque-dnsop-compact-lies-00"
        ipr="trust200902" updates="" 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-huque-dnsop-compact-lies"/>

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

    <date day="25" month="2" year="2023"/>
    <!-- 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 Lies</keyword>
    <keyword>Minimal Lies</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 NSEC record and allow online signing servers to
       minimize signing operations and response sizes.
     </t>
    </abstract>

  </front>

  <middle>

    <section numbered="true" toc="default">
      <name>Introduction and Motivation</name>
      <t>
        One of the functions of the Domain Name System Security Extensions
        (DNSSEC) <xref target="RFC4033" /> <xref target="RFC4034" />
        <xref target="RFC4035" /> <xref target="RFC5155" /> 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 upto 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 Lies",
        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 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>
    </section>

    <section numbered="true" toc="default">
      <name>Distinguishing NXDOMAIN from Empty Non-Terminal 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>
        Today, some specific implementations of Compact Lies avoid the
        NXDOMAIN identification problem by synthesizing the NSEC type
        bitmap for ENTs to include all record types supported except for
        the queried type. This has the undesirable effect of no longer
        being able to reliably determine the existence of ENTs.
      </t>
      <t>
        This document defines the use of a synthetic Resource Record
        type to signal the presence of an Empty Non-Terminal name. The
        mnemonic for this RR type is "ENT" and its type code is [TBD].
        This RR type is added to the NSEC type bitmap for responses
        to ENTs. No special handling of this RR type is needed on the
        part of DNS resolvers.
      </t>
    </section>

    <section numbered="true" toc="default">
      <name>Responses for Non-Existent Names</name>
      <t>
        When an authoritative server implementing Compact Lies 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 name SHOULD be set to the immediate lexicographic successor
       of the QNAME. The generated NSEC record's type bitmap MUST have only
       the RRSIG and NSEC bits set.
      </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
        ]]></artwork>

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

    <section numbered="true" toc="default">
      <name>Responses for Wildcard Matches</name>
      <t>
        For wildcard matches, a Compact Lies implementation will
        typically provide a dynamically signed response that claims
        that the queried name exists explicitly. This obviates the
        need to include an NSEC record in the Additional section of
        the response that shows that no closer match than the wildcard
        was possible.
      </t>
      <t>
        Similarly, Wildcard NODATA responses (where the queried name
        matches a wildcard but no data for the queried type exists),
        a response akin to a regular NODATA is returned. The Answer
        section is empty, and the Additional 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 numbered="true" toc="default">
      <name>Responses for Empty Non-Terminals</name>
      <t>
        When an authoritative server implementing Compact Lies receives
        a query for an Empty Non-Terminal name, it generates a NODATA
        response in the usual way, except that it adds the additional
        Empty Non-Terminal distinguisher RR type code in the NSEC type
        bitmap field. Corresponding RRSIG signature record(s) MUST also
        be generated.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
          ent1.example.net.  3600 IN NSEC \000.ent.example.net. RRSIG NSEC ENT
        ]]></artwork>
      <t>
        Note that this RR type only appears in the type bitmap of an
        NSEC record in response to a query for an Empty Non-Terminal name.
        It causes no special processing on the part of validating resolvers.
        Queries for the ENT RR type itself at an actual Empty Non-Terminal
        MUST also elicit the response described in this section.
      </t>
    </section>

    <section numbered="true" toc="default">
      <name>Operational Implications</name>
      <t>
        A signed zone at an authoritative server implementing Compact
        Lies will never return a response with a response code of
        NXDOMAIN. Tools that rely on accurately determining non-existent
        names will need to infer them from the NSEC type bitmap pattern
        of "NSEC RRSIG".
      </t>
      <t>
        Address lookup functions typically invoked by applications won't
        see a practical impact from this indistinguishability.
        For a non-existent name, the getaddrinfo() function for example
        will return an exit code of EAI_NODATA rather than EAI_NONAME.
        But either way the effect on the caller is the same: it will
        obtain a response with a non-zero exit code and no available
        addresses.
      </t>
    </section>

    <section numbered="true" toc="default">
      <name>Implementation Status</name>
      <t>
        Cloudflare, NS1, and Amazon Route53 currently implement the base
        Compact Lies scheme. NS1 additonally implements the Empty
        Non-Terminal distinguisher in the NSEC type bitmap, using the
        private RR type code 65281.
      </t>
    </section>

    <section 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 Lies 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>
    </section>

    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>
        The Compact Lies technique (then called "Black Lies") was
        originally proposed in
        <xref target="COMPACT-LIES" format="default"/> by F. Valsorda
        and O. Gudmunsson, and implemented by Cloudflare. The Empty
        Non-Terminal distinguisher RR type was originally proposed in
        <xref target="ENT-SENTINEL" format="default"/> by S. Huque.
      </t>
    </section>

    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        IANA is requested to allocate a new DNS Resource Record type
        code for the Empty Non-Terminal distinguisher in the DNS parameters
        registry:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
         ENT  [TBD]  Empty Non-Terminal Distinguisher for Compact Lies
        ]]></artwork>
    </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.4033.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.5155.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7129.xml"/>
      </references>
      <references>
        <name>Informative References</name>
      <reference anchor="COMPACT-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>
      </references>
    </references>

  </back>

</rfc>
