[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-sury-dnsop-cname-plus-dname

DNSext Working Group                                             O. Sury
Internet-Draft                                                    CZ.NIC
Updates: 1034 (if approved)                               April 15, 2010
Intended status: Standards Track
Expires: October 17, 2010


                      CNAME+DNAME Name Redirection
                    draft-sury-dnsext-cname-dname-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 17, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Sury                    Expires October 17, 2010                [Page 1]


Internet-Draft                  IXFR-ONLY                     April 2010


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  CNAME+DNAME Bundle  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Query processing  . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Processing by Authoritative Servers . . . . . . . . . . . . 4
     4.2.  Processing by Recursive Servers . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5




























Sury                    Expires October 17, 2010                [Page 2]


Internet-Draft                  IXFR-ONLY                     April 2010


1.  Introduction

   RFC 1034 [RFC1034] 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.

   However there is already existing exceptions to this rule.  RFC 4034
   [RFC4034] defines exception to RRSIG and NSEC records, which MUST
   exist for the same name as a CNAME resource record in a signed zone.

   RFC 2672 [RFC2672] 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.

   The DNAME RR and the CNAME RR RFC 1034 [RFC1034] 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.

1.1.  Terminology

   All the basic terms used in this specification are defined in the
   documents RFC 1034 [RFC1034], RFC 1034 [RFC1034], RFC 2672 [RFC1034]
   and RFC 2672bis.

1.2.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Motivation

   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



Sury                    Expires October 17, 2010                [Page 3]


Internet-Draft                  IXFR-ONLY                     April 2010


   Domain Label" or "IDL" RFC 3743 [RFC3743] 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.

   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.

   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.


3.  CNAME+DNAME Bundle

   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.


4.  Query processing

   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.

4.1.  Processing by Authoritative Servers

   The authoritative server implementations MUST allow CNAME record when
   there is a DNAME record for the same name and vice versa.





Sury                    Expires October 17, 2010                [Page 4]


Internet-Draft                  IXFR-ONLY                     April 2010


4.2.  Processing by Recursive Servers

   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.


5.  Security Considerations

   The security is the same as security of the individual CNAME and
   DNAME records.


6.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
              Engineering Team (JET) Guidelines for Internationalized
              Domain Names (IDN) Registration and Administration for
              Chinese, Japanese, and Korean", RFC 3743, April 2004.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.


Author's Address

   Ondrej Sury
   CZ.NIC
   Americka 23
   120 00 Praha 2
   CZ

   Phone: +420 222 745 110
   Email: ondrej.sury@nic.cz






Sury                    Expires October 17, 2010                [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/