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

Network Working Group                                             J. Yao
Internet-Draft                                                    X. Lee
Intended status: Informational                                     CNNIC
Expires: January 2, 2017                                    July 1, 2016

      Problem Statement for Fully Mapping One Name to Another Name
            draft-yao-bundled-name-problem-statement-00.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, two names may require to redirect one name space
   fully to another name space.  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 January 2, 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Yao & Lee                Expires January 2, 2017                [Page 1]
Internet-Draft                    bname                        July 2016

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Mapping itself  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Mapping its descendants . . . . . . . . . . . . . . . . .   4
     3.3.  Mapping itself and its descendants  . . . . . . . . . . .   4
     3.4.  Zone Clone  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Change History  . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  draft-yao-bundled-name-problem-statement: Version 00  . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   With the emergence of internationalized domain names and new TLDs,
   two names used for the same purpose may require to redirect one name
   space fully to another name space.  There are many use cases for it.
   Some examples are shown below.

   Use Case 1: Bundled domain names
   Bundled domain names are those who share the same TLD but whose
   second level labels are variants, or those who has identical second
   level labels for which certain parameters are shared in the different
   TLDs.  For example, public Interest Registry, request to implement
   technical bundling of second level domains for .NGO and .ONG.  So we
   have two kinds of bundled domain names.  First one is in the form of
   "V-label.TLD" in which the second level labels (V-label) are varants
   sharing the same TLD; Second one is in the form of "LABEL.V-tld" in
   which the second level labels(LABEL) are same with the different TLDs

Yao & Lee                Expires January 2, 2017                [Page 2]
Internet-Draft                    bname                        July 2016

   (V-tld).  Bundled domain names usually need to map itself and its
   descendants to another.
   for examples:
   example.com == example.net same label ending with different TLDs
   color.com == colour.com different labels ending with the same TLD

   Use Case 2: any two domain names
   One company registers 2 domain names, A and B.  A needs to map itself
   and its descendants to B in order to have a easy manangement.
   for examples:
   example1.com == example2.net

   Use Case 3: a company register the same label in different TLDs.
   With the emergence growth of gTLDs, it is very common to register one
   label under many TLDs for the same purpose. but the comany may just
   use one label under one TLD as the primary domain name, others as the
   less important one.  The company may want to have all these domain
   names share the similar/same DNS resolution results.  So the DNS
   administrator hopes to have some convinient 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,
   two names require to redirect one name space fully to another name
   space.  If one domain name wants to map itself to another domain
   name, the CNAME will be used for that name.  If the name wants to map
   its descendants to other domain, the DNAME will be used.  If the name
   wants to map itself and its descendants to another domain, what
   should we do.  The current protocols do not support to do so.  We
   need to design a mechanism to deal with this requirement.

3.1.  Mapping itself

   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
   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 itself and its variants.

Yao & Lee                Expires January 2, 2017                [Page 3]
Internet-Draft                    bname                        July 2016

3.2.  Mapping 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 its 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 alike the CNAME record, but while the CNAME record only applies
   for one name, with a DNAME record one can create alias for all the
   records for its sudbomain.

3.3.  Mapping itself and its descendants

   The bundle of variant domain names requires to map the whole tree of
   the domain space to another domain.  The current DNS protocols do not
   support this function.  A new DNS resource record [BNAME] may be
   invented to deal with this problem.  BNAME has been discussed a lot
   in the past years.  One reason to be halted is how to make BNAME to
   be 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

   Zone Clone was proposed in the past, which suggests 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.  The problem for zone clone is that it can not deal with the
   children names which are delegated.

4.  IANA Considerations

   There is no IANA consideration.

5.  Security Considerations

   TBD

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

Yao & Lee                Expires January 2, 2017                [Page 4]
Internet-Draft                    bname                        July 2016

7.  Change History

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

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

   o  Problem Statement for Fully Mapping One Name to Another Name

8.  References

8.1.  Normative References

   [ASCII]    American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange", ANSI X3.4-1968, 1968.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 3629, November 2003.

   [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,
              DOI 10.17487/RFC3743, April 2004,
              <http://www.rfc-editor.org/info/rfc3743>.

   [RFC4290]  Klensin, J., "Suggested Practices for Registration of
              Internationalized Domain Names (IDN)", RFC 4290,
              DOI 10.17487/RFC4290, December 2005,
              <http://www.rfc-editor.org/info/rfc4290>.

Yao & Lee                Expires January 2, 2017                [Page 5]
Internet-Draft                    bname                        July 2016

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

8.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 & Lee                Expires January 2, 2017                [Page 6]