One document matched: draft-sury-dnsext-cname-dname-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 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 RFC2672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2672.xml">
<!ENTITY RFC3743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3743.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-dname-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="IXFR-ONLY">CNAME+DNAME Name Redirection</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="April" 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>DNAME</keyword>
    <keyword>CNAME</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 DNAME record, which provides redirection for a
      sub-tree of the domain name tree in the DNS system.  By allowing
      this cooexistence, DNS system will have a way how to create a
      sub-tree redirection together with record owner.  This would
      allow parent zones to create full domain aliases.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	<xref target="RFC1034">RFC 1034</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 is 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="RFC2672">RFC 2672</xref> defines DNAME
	resource record, which provides redirection for a sub-tree of
	the domain name tree in the DNS system.  That is, all names
	that end with a particular suffix are redirected to another
	part of the DNS.
      </t>

      <t>
	The DNAME RR and the CNAME RR <xref target="RFC1034">RFC 1034</xref>
	cause a lookup to (potentially) return data corresponding to a
	domain name different from the queried domain name.  The
	difference between the two resource records is that the CNAME
	RR directs the lookup of data at its owner to another single
	name, a DNAME RR directs lookups for data at descendents of
	its owner's name to corresponding names under a different
	(single) node of the tree.
      </t>

      <section title="Terminology">
	<t>
	  All the basic terms used in this specification are defined
	  in the documents <xref target="RFC1034">RFC 1034</xref>,
	  <xref target="RFC1034">RFC 1034</xref>,
	  <xref target="RFC1034">RFC 2672</xref> and RFC 2672bis.
	</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>
	In some languages, some characters has the variants, which
	look differently or very similar but are identical in the
	meaning.  For example, Chinese character U+56FD and its
	variant U+570B look differently, but are identical in the
	meaning.  If Internationalized Domain Label" or "IDL"
	<xref target="RFC3743">RFC 3743</xref> are composed of
	variant characters, we regard this kind of IDL as the IDL
	variant.  If these IDL variants are put into the DNS for
	resolution, they are expected to be identical in the DNS
	resolution.  More comprehensible example is that we expect
	color.example.com to be equivalent with the colour.example.com
	in the DNS resolution.  Currently this is something we are
	unable to achieve without copying the data for the owner of
	the domain record (ie. for the color.example.com) and keeping
	it in sync by some external mechanism.  The CNAME+DNAME record
	placed in the parent zone will remove this need for
	synchronization.  Without this bundling mechanism, current
	mechanisms such as DNAME or CNAME are not enough capable to
	solve all the problems with the emergence of internationalized
	domain names.  The internationalized domain names may have
	alias or equivalence of the original one.
      </t>
      <t>
	The CNAME+DNAME is not limited to internationalized domain
	names.  This bundling could be used by TLD registries to offer
	additional service for it's registrants.  F.e. a hosting
	company could create generic record for it's service and with
	simple CNAME+DNAME bundle it can create all needed DNS
	resource records for providing this service.
      </t>
      <t>
	There are already such uses of CNAME which violates existing
	DNS standards by replying with CNAME records in the apex of
	the zone.  This proposal would allow these perpetrators to
	comply with the DNS standard again.
      </t>
    </section>

    <section title="CNAME+DNAME Bundle">
      <t>
	This proposal doesn't change wire formats of the existing
	CNAME and DNAME records.  It also doesn't change handling of
	the CNAME and DNAME on the resolver side.
      </t>
    </section>

    <section title="Query processing">
      <t>
	Existing rules for a DNAME RR and a CNAME RR are still valid
	with one exception: The DNAME resource record is allowed when
	there is a CNAME resource record for the same name.
      </t>
      <section title="Processing by Authoritative Servers">
	<t>
	  The authoritative server implementations MUST allow CNAME
	  record when there is a DNAME record for the same name and
	  vice versa.
	</t>
      </section>
      <section title="Processing by Recursive Servers">
	<t>
	  The recursive server implementations MUST NOT deny CNAME
	  record when there is a DNAME record already present in the
	  cache for the same name and vice versa.  Existing
	  implementations are already able to cope with CNAME usage
	  violations, so there shouldn't be a problem.
	</t>
      </section>
    </section>

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

    <section anchor="Security" title="Security Considerations">
      <t>
	The security is the same as security of the individual CNAME
	and DNAME records.
      </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.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.2672.xml"?-->
      &RFC2672;

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

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

    </references>

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