Internet DRAFT - draft-yao-bundled-name-problem-statement
draft-yao-bundled-name-problem-statement
Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Informational CNNIC
Expires: April 30, 2017 J. Levine
Taughannock Networks
October 27, 2016
Problem Statement for Fully Mapping One Name to Another Name
draft-yao-bundled-name-problem-statement-03.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
tree fully to another domain name tree. 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 April 30, 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 April 30, 2017 [Page 1]
Internet-Draft bname October 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. Usee Case 2: a company registers the same label in
different TLDs. . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Mapping a single name itself . . . . . . . . . . . . . . 3
3.2. Mapping a name's descendants . . . . . . . . . . . . . . 3
3.3. Mapping a name and and its descendants . . . . . . . . . 4
3.4. Cloning a zone . . . . . . . . . . . . . . . . . . . . . 4
4. Application handling of bundled names . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
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
8.3. draft-yao-bundled-name-problem-statement: Version 02 . . 5
8.4. draft-yao-bundled-name-problem-statement: Version 03 . . 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 April 30, 2017 [Page 2]
Internet-Draft bname October 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. Usee Case 2: 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], [RFC3490]and [RFC6672].
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 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 the name and its variants.
3.2. Mapping a name's 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
Yao, et al. Expires April 30, 2017 [Page 3]
Internet-Draft bname October 2016
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 mapping of a whole tree
of the domain space to another domain. The current DNS protocols do
not support this function.
3.4. Cloning a zone
A mechanism for processing master files or their equivalent in a DNS
server could direct that 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. A problem for
this method is that it cannot deal with child names that 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.
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.
Yao, et al. Expires April 30, 2017 [Page 4]
Internet-Draft bname October 2016
6. Security Considerations
The CNAME, DNAME, and proposed BNAME records [BNAME] 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, 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 and Paul Hoffman help 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"
o Refine the text
8.3. draft-yao-bundled-name-problem-statement: Version 02
o Refine the text
8.4. draft-yao-bundled-name-problem-statement: Version 03
o Refine use cases and the text
Yao, et al. Expires April 30, 2017 [Page 5]
Internet-Draft bname October 2016
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), 05 2016.
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: xl@cnnic.cn
Yao, et al. Expires April 30, 2017 [Page 6]
Internet-Draft bname October 2016
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
Yao, et al. Expires April 30, 2017 [Page 7]