Problem Statement for Fully Mapping One Name to Another Name
draft-yao-bundled-name-problem-statement-01

Network Working Group                                             J. Yao
Internet-Draft                                                    X. Lee
Intended status: Informational                                     CNNIC
Expires: February 24, 2017                                     J. Levine
                                                    Taughannock Networks
                                                         August 23, 2016

      Problem Statement for Fully Mapping One Name to Another Name
            draft-yao-bundled-name-problem-statement-01.txt

Abstract

   This document specifies the problems related to fully mapping one
   name to another name.  With the emergence of internationalized domain
   names and new TLDs, it is often useful to redirect one domain name
   subtree fully to another name subtree.  Current DNS protocols have
   not provided such ability to satisfy these requirements.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 24, 2017.

Copyright Notice

   Copyright (c) 2016 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
   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

Yao, et al.             Expires February 24, 2017               [Page 1]
Internet-Draft                    bname                      August 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Use Case 1: Bundled domain names  . . . . . . . . . . . .   2
     1.2.  Use Case 2: any two domain names  . . . . . . . . . . . .   3
     1.3.  Usee Case 3: a company registers the same label in
           different TLDs. . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Mapping a single name . . . . . . . . . . . . . . . . . .   3
     3.2.  Mapping a name and its descendants  . . . . . . . . . . .   4
     3.3.  Mapping a name and and its descendants  . . . . . . . . .   4
     3.4.  Zone Clone  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Application handling of bundled names . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Change History  . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  draft-yao-bundled-name-problem-statement: Version 00  . .   5
     8.2.  draft-yao-bundled-name-problem-statement: Version 01  . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   With the emergence of internationalized domain names and new TLDs,
   two names may be used to identify the same thing.  In this case, it
   use useful to redirect one name space fully to another name space.
   There are many use cases for it.  Some examples are shown below.

1.1.  Use Case 1: Bundled domain names

   Bundled domain names share the same TLD but their second level labels
   are variants, or have identical second level labels in specific TLDs.
   For example, Public Interest Registry, has implemented technical
   bundling of second level domains in .NGO and .ONG.  So we have two
   kinds of bundled domain names.  The first one is of the form
   "V-label.TLD" in which the second level labels (V-label) are varants
   sharing the same TLD; The second one is of the form "LABEL.V-tld" in
   which the second level labels (LABEL) are the same, but in different
   TLDs (V-tld).  Bundled domain names usually need to map themselves
   and their descendants together.

Yao, et al.             Expires February 24, 2017               [Page 2]
Internet-Draft                    bname                      August 2016

   For example:

      example.com == example.net same label ending with different TLDs

      color.com == colour.com different labels ending with the same TLD

1.2.  Use Case 2: any two domain names

   One company registers 2 domain names, A and B.  It wishes to map A
   its descendants to B and its descendants for easier manangement.

   For example:

      example1.com == example2.net

1.3.  Usee Case 3: a company registers the same label in different TLDs.

   With the emergence growth of gTLDs, it is very common for a
   registrant to register one label under many TLDs, but the registrant
   may just use one label under one TLD as the primary domain name, with
   others less important.  The registrant may want to have all these
   domain names share similar or the same DNS resolution.  So the DNS
   administrator wants a convenient method to configure these domain
   names in DNS.

2.  Terminology

   All the basic terms used in this specification are defined in the
   documents [RFC1034], [RFC1035], [RFC6672] and [RFC3490].

3.  Problem Statement

   With the emergence of internationalized domain names and new TLDs, a
   DNS operator often wishes to redirect one name space fully to another
   name space.  A CNAME record can in some cases map a single name to
   another single name.  If one domain name is mapped another domain
   name, the CNAME will be used for that name.  A DNAME can map a name's
   descndants to descendants of another domain.  If we want to map both
   a name and its descendats, there's no way to do so with current
   protocols.  We need to design a mechanism to deal with this
   requirement.

3.1.  Mapping a single name

   A host can have many names.  The Internet users need these multiple
   names to be resolved to the same IP address by a DNS server.  CNAME
   record [RFC1034], an abbreviation of Canonical Name Records, is
   responsible for the aliases of the real host name of a computer.  In

Yao, et al.             Expires February 24, 2017               [Page 3]
Internet-Draft                    bname                      August 2016

   some cases, the CNAME can work for these bundled domain names.  But
   the CNAME only maps itself, not its descendants.  The bundled names
   need to map both the name and its variants.

3.2.  Mapping a name and its descendants

   In order to maintain the address-to-name mappings in a context of
   network renumbering, a DNAME record or Delegation Name record defined
   by [RFC6672] creates an alias for all of a name's subdomains.  In
   contrast, the CNAME record creates an alias only of a single name
   (and not of its subdomains).  Like the CNAME record, the DNS lookup
   will continue by retrying the lookup with the new name.

   A DNAME record is very much like a CNAME record, but while the CNAME
   record only applies for one name, with a DNAME record one can create
   aliases for all the the names in its sudbomains.

3.3.  Mapping a name and and its descendants

   The bundle of variant domain names requires mappping of a whole tree
   of the domain space to another domain.  The current DNS protocols do
   not support this function.  A new DNS resource record [BNAME] has
   been proposed to deal with this problem.  BNAME has been discussed a
   lot in the past years.  One unresolved problem is how to make BNAME
   compatible with DNSSEC.  Some experts from DNSEXT suggested that this
   document should be moved to the new WG for furhter discussion.  The
   new version of BNAME has been updated to be compatible with DNSSEC.

3.4.  Zone Clone

   A Zone Clone record has also been proposed.  It directs a DNS server
   to exactly replicate the content of a DNS zone into one or more other
   DNS zones so that the content is reachable by multiple names at
   different zone apexes.  An unresolved problem for zone clone is that
   it can not deal with child names which are delegated.

4.  Application handling of bundled names

   Even if the DNS publishes records for all of the names in a bundle,
   applications frequently do not work because they do not recognize the
   names.  One of the authors sampled names in the .CAT top-level-
   domain, which uses DNAME records to map versions of domain names with
   accented characters to the unaccented version.  In most cases, web
   servers returned an error page or a default page for the accented
   versions of names, because they were not configured to recognize
   those names.

Yao, et al.             Expires February 24, 2017               [Page 4]
Internet-Draft                    bname                      August 2016

   It would be techincally straightforward in many cases for servers to
   automatically configure themselves to handle variant names.  for
   example, if a web server received a request with an unrecognized
   name, it could do a DNS lookup on the name and if it found, say, a
   BNAME record, it could treat the request as equivalent to a request
   to the target of the BNAME.

   This introduces security issues, described below.

5.  IANA Considerations

   There is no IANA consideration.

6.  Security Considerations

   The CNAME, DNAME, and proposed BNAME records all provide the ability
   to make a name or set of names "the same" as target names without
   cooperation or permission from the target.  This could allow a
   malicious party to point a deceptive or misleading name at an
   innocent victim name.  If applications automatically configured
   themselves to handle BNAMEs, as described above, this could create
   inadvertently deceptive web sites.

   The CLONE record largely avoids this problem, since the set of alias
   names is under control of the owner of the target names.

7.  Acknowledgements

   Many ideas are from the discussion in the DNSOP and DNSEXT mailling
   list.  Thanks a lot to all in the list.  Many important comments and
   suggestions are contributed by many members of the DNSEXT and DNSOP
   WG.  Yoshiro YONEYA helps to review this document and gives good
   comments.

8.  Change History

   [[CREF1: RFC Editor: Please remove this section.]]

8.1.  draft-yao-bundled-name-problem-statement: Version 00

   o  Problem Statement for Fully Mapping One Name to Another Name

8.2.  draft-yao-bundled-name-problem-statement: Version 01

   o  Adding section "Application handling of bundled names"

   o  Adding section "Security Considerations"

Yao, et al.             Expires February 24, 2017               [Page 5]
Internet-Draft                    bname                      August 2016

   o  Refine the text

9.  References

9.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,
              <http://www.rfc-editor.org/info/rfc3490>.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <http://www.rfc-editor.org/info/rfc6672>.

9.2.  Informative References

   [BNAME]    Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name
              Redirection", draft-yao-dnsext-bname-06.txt (work in
              progress), 12 2009.

Authors' Addresses

   Jiankang YAO
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing

   Phone: +86 10 58813007
   Email: yaojk@cnnic.cn

   Xiaodong LEE
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing

   Phone: +86 10 58813020
   Email: lee@cnnic.cn

Yao, et al.             Expires February 24, 2017               [Page 6]
Internet-Draft                    bname                      August 2016

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg, NY  14886

   Phone: +1 831 480 2300
   Email: standards@taugh.com

Yao, et al.             Expires February 24, 2017               [Page 7]