Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Informational CNNIC
Expires: August 5, 2010 February 1, 2010
Problem Statement for Identical DNS Resolution of Bundle Names
draft-yao-dnsext-identical-resolution-00.txt
Abstract
This document specifies the problems related to the identical
resolution of bundle DNS names. With the emergence of
internationalized domain names, two names with the same meaning or
visual similarity sometimes require the identical resolution.
Current DNS protocols have not provided such ability to satisfy these
requirements.
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 August 5, 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
Provisions Relating to IETF Documents
Yao & Lee Expires August 5, 2010 [Page 1]
Internet-Draft bname February 2010
(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.
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.
Yao & Lee Expires August 5, 2010 [Page 2]
Internet-Draft bname February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Character Variants . . . . . . . . . . . . . . . . . . . . 3
2.2. Registration of Domain Name Variants . . . . . . . . . . . 4
2.3. Identical DNS Resolution for Bundle DNS Names . . . . . . . 4
3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Mapping or Redirection of Domain Names . . . . . . . . . . 5
3.1.1. Mapping itself . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Mapping its descendants . . . . . . . . . . . . . . . . 5
3.1.3. Mapping itself and its descendants . . . . . . . . . . 5
3.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. draft-yao-dnsext-identical-resolution-problem-statement
Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Yao & Lee Expires August 5, 2010 [Page 3]
Internet-Draft bname February 2010
1. Introduction
If one domain name is the alias of 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. There can have a lot of
names under the DNS zones. Some of these names are very similar.
The DNS was designed under the environment of ASCII characters, but
the naming similarity in English is not very popular; the
requirements of identical resolution of these names does not cause
the attentions of the IETF DNS engineers. With the internationalized
domain names protocols publishing in 2006 and updating in 2008, more
and more internationalized domain name labels [RFC3490] appear in the
DNS trees. Some labels [RFC3743] are equivalent in some languages.
For examples: For English speak users, color and colour are same; For
Chinese speak users, Chinese character U+56FD and its variant U+570B
look differently, but are identical in the meaning. The Internet
users hope them to be identical in the DNS resolution. For example,
color.exmaple.com==colour.example.com. On the other hand, ICANN's
"Final Implementation Plan for IDN ccTLD Fast Track Process" said
that the desired IDN TLD variants will be allocated, and may be put
into the root. ICANN currently does not find the perfect technical
solution to put the IDN TLD variants into the root.
1.1. Terminology
All the basic terms used in this specification are defined in the
documents [RFC1034], [RFC1035], [RFC2672] and [RFC3490].
2. Problem Statement
2.1. Character Variants
Many languages have the character variants. Although there is no
uniform definition of variants, the variants are popular in many
languages. The definition of variant characters in the JET
Guidelines [RFC3743]: One conceptual character can be identified with
several different Code Points in character sets for computer use. In
UNICODE, Some characters can be identified as the compatibility
variants of another character, which usually implies that the first
can be remapped to the second without the loss of any meaning. In
this document, variant characters are two or more characters that may
be similar in appearance or identical in meaning. ICANN is pushing
the IDN TLD into the root server. Some IDN TLD has the variants.
How to deal with the IDN TLD variant issue is a big challenge ahead
of us. For example, if the IDN TLD "China" (U+4E2D U+56FD) and its
Yao & Lee Expires August 5, 2010 [Page 4]
Internet-Draft bname February 2010
variant (U+4E2D U+570B) are put into the root, the first one (U+4E2D
U+56FD) is called as the original IDN TLD and the second one (U+4E2D
U+570B) is called as the IDN TLD variant. In an ideal way, the
original IDN TLD and its IDN TLD variant SHOULD be identical in the
DNS resolution. If case mapping is regarded as the variant, the
uppercase A is the variant of lowercase a. For example, the ".COM"
is the variant of ".com". These variants need to be identical in the
DNS resolution, which has been done so in the DNS protocols.
However, we can not find the ideal solution of identical DNS
resolution for the IDN TLD variants.
2.2. Registration of Domain Name Variants
With the development of internationalized domain names protocols,
more and more domain names and their variants appear in the Internet.
Without careful management of the domain name variants, there will
have more phising related security problems. [RFC3743] developed by
JET (Joint Engineering Team) gives a solution of how to manage the
registration of domain name and its variants. [RFC3743] proposed an
algorithm which will allocate the domain name and its variants to the
same domain holder. It means that the domain holder will get the
bundle of the domain name and its variants. [RFC4290] suggests the
practice in [RFC3743] to be used in registrations of
internationalized domain names. But [RFC3743] and [RFC4290] do not
define how these bundle of names get the identical DNS resolution.
[RFC4690] said that the "variant" model introduced in [RFC3743] and
[RFC4290] can be used by a registry to prevent the worst consequence
of the possible confusion, by ensuring either that both names are
registered to the same party in a given domain or that one of them is
completely prohibited. The principle of [RFC3743], [RFC4290] and
[RFC4690] have been accepted by many registries. In the technology
level, we can not guarantee that these bundle of domain names get the
identical DNS resolution.
2.3. Identical DNS Resolution for Bundle DNS Names
Identical DNS Resolution means that two domain names will finally get
the same result, in most cases the same IP address. The Internet
users hope that the domain names and its variants to be identical in
DNS resolution. In the history of DNS protocol development, there
has already two kinds of identical resolution:CNAME[RFC1034] which
maps or redirects itself and DNAME[RFC2672] which maps or redirects
its descendants. In the case of bundle Names, identical DNS
resolution of all levels' domain names including the domain name
itself and its descendants are expected. Current technologies do not
allow to do so. Some suggestions trying to use the current
technology are proposed in the draft of "IDN TLD Variants
Implementation Guideline" [IDN-TLD-Variants], but this is a mechanism
Yao & Lee Expires August 5, 2010 [Page 5]
Internet-Draft bname February 2010
of combination of both technology and policy, which is not a perfect
solution.
3. Possible Solutions
Currently, there are two possible solutions to the identical DNS
resolution of bundle names: Bundle Names direction[BNAME] and Zone
clone. Both solutions have their advantages and disadvantages. The
implementers may select one of them to be used
3.1. Mapping or Redirection of Domain Names
3.1.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 bundle of variant domain
names. But the CNAME only maps itself, not its descendants. In the
case of IDN TLD variants, IDN TLD variants need to map itself and its
variants.
3.1.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 [RFC2672] 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. If a DNS resolver sends a
query without EDNS[EDNS0], or with EDNS version 0, then a name server
synthesizes a CNAME record to simulate the semantics of the DNAME
record. 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.1.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.
Yao & Lee Expires August 5, 2010 [Page 6]
Internet-Draft bname February 2010
3.2. Zone Clone
Zone Clone proposed by Paul Vixie from Internet Software Consortium
is an alternative solution to getting the identical DNS resolution of
bundle domain names.
4. IANA Considerations
There is no IANA consideration.
5. Security Considerations
There may have more disscussions related to DNSSEC [RFC4033],
[RFC4034] and [RFC4035]in the future version.
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.
7. Change History
[[anchor15: RFC Editor: Please remove this section.]]
7.1. draft-yao-dnsext-identical-resolution: Version
00
o Domain Name Identical Resolution Problem Statement
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.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
Yao & Lee Expires August 5, 2010 [Page 7]
Internet-Draft bname February 2010
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 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, April 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290,
December 2005.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names
Yao & Lee Expires August 5, 2010 [Page 8]
Internet-Draft bname February 2010
(IDNs)", RFC 4690, September 2006.
8.2. Informative References
[BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name
Redirection", draft-yao-dnsext-bname-01.txt (work in
progress), 12 2009.
[IDN-TLD-Variants]
Yao, J. and X. Lee, "IDN TLD Variants Implementation
Guideline", draft-yao-dnsop-idntld-implementation-01.txt
(work in progress), 11 2009.
[RFC2672bis]
Rose, S. and W. Wijngaards, "Update to DNAME Redirection
in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
17.txt, 6 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 August 5, 2010 [Page 9]