One document matched: draft-sury-dnsext-cname-at-apex-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC1033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1033.xml">
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
]>
<?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 category="std" docName="draft-sury-dnsext-cname-at-apex-00" ipr="trust200902" updates="1034">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

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

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Apex-CNAME">CNAME at the zone apex</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <!-- XXX: this should be Ondřej, Surýbut 
              the IETF is Unicode-phobic -->
    <author fullname="Ondrej Sury" initials="O.S." surname="Sury">
      <organization>CZ.NIC</organization>

      <address>
        <postal>
          <street>Americka 23</street>

          <!-- Reorder these if your country does things differently -->

          <city>120 00 Praha 2</city>

          <country>CZ</country>
        </postal>

        <phone>+420 222 745 110</phone>

        <email>ondrej.sury@nic.cz</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="August" year="2010" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup>DNSext Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>DNS</keyword>
    <keyword>CNAME</keyword>
    <keyword>SOA</keyword>
    <keyword>NS</keyword>
    <keyword>zone apex</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document proposes a modification to CNAME record to
      coexist with SOA and NS records at the zone apex.  This proposal
      will improve aliasing in the DNS system.  The users are often
      forced to manually add duplicate A, AAAA and MX records by
      copying data from the target zone to the aliased zone.  This
      forces zone owner to keep track of target domain name since the
      mismatch in the data could cause failures.  This administrative
      burden will be eliminated by allowing CNAME to coexist with NS
      and SOA resource records.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	<xref target="RFC1033">RFC 1033</xref> defines CNAME
	resource record for cases when there are multiple names for
	single host.  A CNAME resource record identifies its owner
	name as an alias, and specifies the corresponding canonical
	name in the RDATA section of the resource record.  If a CNAME
	resource record is present at a node, no other data MUST be
	present; this ensures that the data for a canonical name and
	its aliases cannot be different.  This rule also insures that
	a cached CNAME can be used without checking with an
	authoritative server for other resource record types.
      </t>
      <t>
	However there are already existing exceptions to this
	rule.  <xref target="RFC4034">RFC 4034</xref> defines
	exception to RRSIG and NSEC records, which MUST exist for the
	same name as a CNAME resource record in a signed zone.
      </t>

      <t>
	<xref target="RFC1034">RFC 1034</xref> defines the data
	that defines the top node of the zone.  They are logically
	part of the authoritative data, the RRs that describe the top
	node of the zone are especially important to the zone's
	management.  These RRs are of two types: name server RRs that
	list, one per RR, all of the servers for the zone, and a
	single SOA RR that describes zone management parameters.
      </t>

      <t>
	The Start Of Authority (SOA) record designates the start of a zone.
	It must be present in the zone apex.
      </t>

      <t>
	The NS (Name Server) record lists the name of a machine the
	provides domain service for a particular zone.  The NS record
	is placed both in the parent and the child zone and should be
	same.  The NS record(s) are also mandatory in the zone.
      </t>

      <section title="Terminology">
	<t>
	  All the basic terms used in this specification are defined
	  in the documents <xref target="RFC1033">RFC 1033</xref>,
	  <xref target="RFC1034">RFC 1034</xref>.
	</t>
      </section>

      <section title="Requirements Language">
	<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">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="Motivation">
      <t>
	The aliasing in the DNS system is usually done by placing
	CNAME for each individual record which needs to be aliased.
	There is one notable exception - the zone apex which has to
	include the SOA and NS RRs.  Because of that the zone owner is
	unable to place CNAME record there and this can lead to
	several failure conditions.  Either the data in the apex is
	copied by hand and new administrative burden is created to
	keep the data in the sync, or there is no alias in the apex at
	all.
      </t>

      <t>
	The aliases zone is prone to several types of errors when the
	copy method is used.  The target domain can change the data
	and while subdomains (like www.example.net) still works the
	zone apex A record (example.net) doesn't work.  This could go
	overlooked for some time if the zone owner doesn't do regular
	checks.  Same condition can happen with MX records causing
	failure to deliver email or it could even lead to malicious
	use if the bad guys happen to own previous manually copied MX
	records.  Also there could be a semi-failures, f.e. if the
	target zone adds AAAA record for IPv6, it will not be copied
	to aliased zone automatically causing IPv6 resolution failures.
      </t>
    </section>

    <section title="CNAME at the apex">
      <t>
	This proposal defines new rules for the CNAME record. <xref target="RFC1034">RFC 1033</xref> defines that:
      </t>
      <t>
	There must not be any other RRs associated with a nickname of the
	same class.
      </t>
      <t>
	This rule is changed with full compliance with DNSSEC RFCs to:
      </t>
      <t>
	There must not be any other RRs with the same owner as the
	CNAME RR with the exception of NS, SOA, DNSKEY, RRSIG and
	NSEC RRs.
      </t>
    </section>

    <section title="Query processing">
      <t>
	Because of the change of the existing behaviour in the CNAME
	processing there is a need to add a signaling bit for the
	queries issued by resolvers understanding CNAME at the zone
	apex.
      </t>
      <section title="Processing by Authoritative Servers">
	<t>
	  The authoritative server implementations MUST allow CNAME
	  resource record in the zone apex to coexist with NS, SOA,
	  DNSKEY, RRSIG and NSEC resource records.  They MUST NOT
	  allow any other resource record types in the zone apex when
	  the CNAME resource record is placed in the zone apex.
	</t>
	<t>
	  The authoritative server will return an answer containing
	  specific resource record type when asked for SOA, NS,
	  DNSKEY, RRSIG or NSEC RR type.  The authoritative server
	  will return an answer containing the CNAME if any other RR
	  type is requested in the query.  If the query contains the
	  CNAME-at-apex signaling bit then the authoritative server
	  will use correct TTL in the zone for the requests in the
	  zone apex.  If the query doesn't contain the CNAME-at-apex
	  signaling bit then the authoritative server will override
	  TTL in the zone and will return answer with 0 TTL for all
	  resource requests in the zone.  This should prevent the
	  resolvers to store the result in the cache and thus breaking
	  the internal rules for the CNAME.
	</t>
      </section>
      <section title="Processing by Recursive Servers">
	<t>
	  The resolver compliant with this proposal will issue a query
	  which has the CNAME-at-apex signaling bit.  Such resolver
	  MUST NOT deny CNAME if it already has other resource record
	  in the cache with the same owner with the SOA, NS, DNSKEY,
	  RRSIG or NSEC resource record type.  It MUST NOT deny SOA,
	  NS, DNSKEY, RRSIG or NSEC resource records if it already has
	  a CNAME resource record in the cache.  The compliant
	  resolver SHOULD NOT deny CNAME in the case it has any other
	  RR type in the cache and it SHOULD NOT deny any other RR
	  types if it already has CNAME records in the cache.
	</t>
	<t>
	  The rules for the authoritative server is same for the
	  compliant resolver acting as an upstream cache.
	</t>
      </section>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Security" title="Security Considerations">
      <t>
	The author is not aware of any security consideration, but he
	is aware that this proposal could create problems for the name
	servers not following the Robustness principle - Be
	conservative in what you send; be liberal in what you accept.
      </t>
    </section>
  </middle>

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

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1033.xml"?-->
      &RFC1033;

      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"?-->
      &RFC1034;

      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml"?-->
      &RFC4034;

    </references>

    <!-- Change Log
      2010-04-15 version 00
      -->
  </back>
</rfc>