One document matched: draft-ogud-fake-nxdomain-type-00.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1035 PUBLIC "" "./reference.RFC.1035.xml">
  <!ENTITY rfc1995 PUBLIC "" "./reference.RFC.1995.xml">
  <!ENTITY rfc2119 PUBLIC "" "./reference.RFC.2119.xml">
  <!ENTITY rfc3833 PUBLIC "" "./reference.RFC.3833.xml">
  <!ENTITY rfc4034 PUBLIC "" "./reference.RFC.4034.xml">
  <!ENTITY rfc4035 PUBLIC "" "./reference.RFC.4035.xml">
  <!ENTITY rfc4471 PUBLIC "" "./reference.RFC.4471.xml">
]>

<rfc category="std" docName="draft-ogud-fake-nxdomain-type-00" 
     ipr="trust200902" updates="1035">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes"?>
  <?rfc compact="yes" ?>

  <front>
    <title abbrev="NXDOMAIN via NSEC type map">
      Signaling NSEC record owner name nonexistence
    </title>
     
    <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
      <organization>CloudFlare Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94107</code>
          <country>USA</country>
        </postal>
        <email>olafur@cloudflare.com</email>
      </address>
    </author>

    <author fullname="Filippo Valsorda" initials="F." surname="Valsorda">
      <organization>CloudFlare Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>London</city>
          <region></region>
          <code></code>
          <country>UK</country>
        </postal>
        <email>filippo@cloudflare.com</email>
      </address>
    </author>

    <date />
      
    <area>Operations</area>
      
    <workgroup>DNSOP</workgroup>
      
    <abstract>
      <t> DNSSEC was to large extent designed for off-line signing. A
	number of new opportunities arise when on-line signing is used. In
	negative answers case there is no real need for the wildcard proof and the
	server can just state that the queried name and type do not exist in a single
	NSEC/NSEC3 record. But such a minimally covering NSEC record that
	shares the name with the query name can not set the NXDOMAIN RCODE.
	Still, some applications want to explicitly know if the name does exist.
	This document allocates a new DNS RRtype that can be used to
	signal nonexistence of the owner names of NSEC/NSEC3 records.
      </t> 
    </abstract>
  </front>

  <middle>
    <section title="Introduction"> 
      <t>The <xref target="RFC4035">DNSSEC Specification</xref> is
	  largely designed for <xref target="RFC4471">off-line signing</xref> with
	  minimal thought for as how on-line signing systems can give out
	  smaller/better answers.
      </t>
      <t>One way to give a validate-able negative answer for a question when
	  the name does not exist is to state that the name exists but the type
          does not. This allows to generate one NSEC instead of two.
	  This works great for resolvers as they see that what was asked for
	  does not exist and thus tell the application that.
      </t>
      <t> There is a sub-class of applications that care if
	the name exists rather than the type and the question is asked
	to check for the existence of the name and not the type. The above
	approach makes life hard for these applications.
      </t> 

      <t>To support both of the above expectations we propose to
	define a RRtype, that has no body and never exists (i.e. a meta-type). When the
        bit for this type is set in the NSEC/NSEC3 bitmap the application can
        take that to mean "the right RCODE for this answer would be NXDOMAIN".
	</t> 

    </section>

    <section title="Requirements Notation">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as
	described in <xref target="RFC2119"/>.</t>
    </section>

    <section title="Protocol Changes">
      <t> This document specifies a special DNS RRType <xref target="RFC1035"/>
      that can only appear in NSEC/NSEC3 bitmaps <xref target="RFC4034"/>
      to signal that:
    <list style="bullets"> 
      <t> this is an on-line signed answer </t>
      <t> none of the owner name nor the target name or any
      name in between them exist </t>
      <t> this name is not covered by any wildcard</t>
    </list>
    The purpose of this is to signal that the "right answer" for this query was
      RCODE=3 and multiple NSEC/NSEC3 records in the authority section, but
      because the answer was signed on-the-fly it was pretended that the
      query name exists but the type does not, thus answering with RCODE=0
      and one NSEC record in the authority section. 
      We call this RRType FakeNXDOMAIN or FDOM, type code is TBD. 
     </t> 
	
      <t>An authoritative DNS server SHOULD NOT be extended to load
      this type or any other meta type. 
      </t>
      <t>A resolver MAY translate the returned NSEC record in a
      RCODE=3 answer, if it so chooses, to clients that do not ask for
      DNSSEC answers. 
      </t> 
    </section>

    <section title="IANA Considerations">
      <t>We request an assignment in the "Domain Name System (DNS)
      Parameters" registry sub-registry "Resource Record (RR) TYPEs" for a
      type code FDOM (Fake DOMain name) suggesting using the lowest
      Meta-Type code available 128. 
      </t>
    </section>

    <section title="Security Considerations">
      <t>While the content of the answer changes with this technique, its actual
        meaning is the same and such an answer can't be replayed by an attacker
        to mean anything else than its intended meaning.
      </t>
      <t>An application sensible to the difference between a nonexistent name and
        a nonexistent type SHOULD support the RRType defined in this document,
        and can rely on it to retrieve the information they look for securely
        since the NSEC/NSEC3 bitmap is signed.
      </t>
    </section>

    <section title="Implementation Experience"> 
      <t>TBD</t>
    </section> 
<!--
    <section title="Acknowledgements">
      <t> Editors want to thank following people, in random order, for
	useful feedback: 

      </t>
    </section>
--> 
  </middle>

  <back>
    <references title="Normative References">
      &rfc1035;
      &rfc2119;
      &rfc4034;
      &rfc4035;
    </references>

    <references title="Informative References">
      &rfc4471;
    </references>


    <section title="Document history"> 
      <t>This section (and sub-sections) should be removed before
        publication.</t>

      <section title="Abridged Revision History">
        <t> 00 Initial draft.</t>
      </section>
   </section>
  </back>
</rfc>