Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: BCP CNNIC
Expires: April 16, 2010 October 13, 2009
IDN TLD Variants Implementation Guideline
draft-yao-dnsop-idntld-implementation-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
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 April 16, 2010.
Copyright Notice
Copyright (c) 2009 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
Yao & Lee Expires April 16, 2010 [Page 1]
Internet-Draft tld October 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
ICANN is pushing the IDN TLD into the root server. Some IDN TLD has
the variants. Currently, there are two proposals to implement the
IDN TLD variants in the root servers:1, implement it with the DNAME
record; 2, implement it with NS record. The IDN TLD variants may be
reserved or activated. If the IDN TLD variants are activated, these
variants will be allocated to the same TLD manager in order to avoid
the possible phishing problems. How to deal with the IDN TLD variant
issue is a big challenge ahead of us. This document discusses the
IDN TLD variants implementation issues related with DNAME and NS
resource record way. This memo also gives a proposal about how to
avoid the possible phishing problem after putting the IDN TLD
variants into the root.
Yao & Lee Expires April 16, 2010 [Page 2]
Internet-Draft tld October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IDN TLD Variant . . . . . . . . . . . . . . . . . . . . . . . 4
3. DNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Domain Name Resolution Failure . . . . . . . . . . . . . . 5
3.2. Zero TTL . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Mis-configuration . . . . . . . . . . . . . . . . . . . . 6
4. NS Resource Record . . . . . . . . . . . . . . . . . . . . . . 6
5. IDN TLD variants implementation guideline . . . . . . . . . . 6
5.1. The principle of IDN TLD variants implementation . . . . . 6
5.2. IDN TLD variants in the root . . . . . . . . . . . . . . . 7
5.2.1. DNAME is not proper for IDN TLD variants . . . . . . . 7
5.2.2. NS is good for IDN TLD variants . . . . . . . . . . . 7
5.3. The second level names under the IDN TLD variants . . . . 7
5.3.1. Apply DNAME . . . . . . . . . . . . . . . . . . . . . 7
5.3.2. Apply NS . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. draft-yao-dnsop-idntld-implementation: Version 00 . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Yao & Lee Expires April 16, 2010 [Page 3]
Internet-Draft tld October 2009
1. Introduction
ICANN is pushing the IDN TLD into the root server. Some IDN TLD has
the variants. Currently, there are two proposals to implement the
IDN TLD variants in the root servers:1, implement it with the DNAME
record; 2, implement it with NS record. The IDN TLD variants may be
reserved or activated. If IDN TLD variants are activated, these
variants will be allocated to the same TLD manager in order to avoid
the possible phishing problems. How to deal with the IDN TLD variant
issue is a big challenge ahead of us. This document discusses the
IDN TLD implementation issues related with DNAME and NS resource
record way. This memo also gives a proposal about how to avoid the
possible phishing problem after putting 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], [RFC3490] and [RFC3743].
Understanding of the [RFC2672] and [RFC3743] is necessary to
understand this document. In particular, the term "variant" is
defined in section 1.3.2 of [RFC4290]. the "normal domain name" is
the domain name which can be configured with the DNS Resource Record
directly.
2. IDN TLD Variant
In ASCII [ASCII] letters, the upper case "A" and lower case 'a' are
same in the meaning. In many cases, the upper case "A" and lower
case 'a' are exchangeable. We can regard the upper case "A" as the
variant of the lower case 'a'. 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 Domain Label" or "IDL" [RFC3743] are
composed of variant characters, we regard this kind of IDL as the IDL
variant. If these IDL variants are put into the root, they are
regarded as the IDN TLD variants. For example, if the IDL "China"
(U+4E2D U+56FD) and its IDL 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 ideal way, the original IDN TLD and its IDN TLD variant SHOULD be
identical in the DNS resolution. For example, the ".com" is
identical to ".COM" in the DNS resolution. Currently, we can not
find the ideal solution for the IDN TLD variants. Two proposals are
suggested to solve the problem: DNAME record and NS record.
Yao & Lee Expires April 16, 2010 [Page 4]
Internet-Draft tld October 2009
3. DNAME
A DNAME record is defined in [RFC2672]. DNAME provides redirection
from a part of the DNS name tree to another part of the DNS name
tree. DNAME does not direct itself (the owner name). The basic DNS
documents [RFC1034] and [RFC1035] were defined in the year of 1987
while the DNAME [RFC2672] was defined in the year of 1999. There are
12 years gap between them. So there are a lot of legacy DNS
applications which are unaware of DNAME. DNAME protocol itself also
has some kind of problems.
3.1. Domain Name Resolution Failure
The Section 4.1 of [RFC2672] specifies that DNS clients sending
Extended DNS [EDNS0] queries with Version 0 or non-extended queries
are presumed not to understand the semantics of the DNAME record, so
a server which implements this DNAME specification , when answering a
non-extended query or the query with the Extended DNS Version 0
[EDNS0], SHOULD synthesize a CNAME record for each DNAME record
encountered during query processing. This means that the synthesized
CNAME record is not always provided. If there has the Extended DNS
queries with Version 1 (EDNS1) in future, the resolver with EDNS1
query may not support DNAME and the synthesized CNAME may not
provided. This can be regarded as the hole of original DNAME
specification. The [RFC2672bis] has updated it to "A CNAME RR with
TTL equal to the corresponding DNAME RR is synthesized and included
in the answer section for resolvers that did not indicate
understanding of DNAME in queries." There are many legacy DNS
applications and resolvers which do not support DNAME. If the
synthesized CNAME resource record is not provided to these
applications or resolvers, the relative domain name under the DNAME
owner will not be resolved. It is unsafe to use the DNAME for some
very import domain name since there is an potential possibility that
the domain name may be unavailable to the internet users. In other
side, whether the DNAME-unaware cache server can provide the
synthesized CNAME to the DNAME-unaware resolvers are not clear. If
it can not, it will also cause some domain name resolving failure.
3.2. Zero TTL
The section 4.1 of [RFC2672] specifies that the synthesized CNAME RR,
if provided, MUST have TTL equal to zero. It means that the DNAME-
unaware resolver will not cache this resource record. The DNAME-
unaware resolver will go to other servers to lookup the relative
answers every time when the DNAME record is involved. This will
cause much load to the servers which provide the DNAME service. The
[RFC2672bis] has updated it to " A CNAME RR with TTL equal to the
corresponding DNAME RR is synthesized and included in the answer
Yao & Lee Expires April 16, 2010 [Page 5]
Internet-Draft tld October 2009
section for resolvers that did not indicate understanding of DNAME in
queries." In the current implementation based on [RFC2672], the TTL
for synthesized CNAME Resource record is 0, which means there will be
no cache in the resolvers. So every query from DNAME-unaware
resolvers has to go to the DNS servers which provide the DNAME
service. This will cause a big load to the DNAME DNS servers.
3.3. Mis-configuration
DNAME RFC specifies that resource records MUST NOT exist at any sub-
domain of the owner of a DNAME RR. Some DNS administrators may not
know it and still configure the RR in the sub-domain of the owner of
a DNAME RR, which may lead the failure resolving. The DNAMEed domain
name is not a normal domain name. The normal domain name itself can
be configured with the DNS resource record such as A or MX record.
Many DNS administrators will mis-configure it. The registrant of
this domain name may not understand the DNAME and regard the DNAMEed
domain name as the normal domain name.
4. NS Resource Record
The NS record is defined in the basic DNS documents [RFC1034] and
[RFC1035]. NS resource record is deployed widely. If IDN TLD
variants are delegated via the NS resource record way, the original
IDN TLD and its variants can be delegated to totally different
servers. In the DNS zone, they are the different domain names.
5. IDN TLD variants implementation guideline
5.1. The principle of IDN TLD variants implementation
In ideal way, the original IDN TLD and its variant ones SHOULD be
identical in the DNS resolution, such as ".com"== ".COM". Any policy
or technology SHOULD be used to guarantee that the IDN TLD and its
variant SHOULD belong to the same registry; the DNS administrators
SHOULD try their best to make the IDN TLD and its variants be
identical in the DNS resolution. There have 2 ways to deal with it.
In technique, the DNS operators may use some technology to implement
it; In policy, the DNS administrators can use some management policy
or some guideline to make the original IDN TLD and its variants be
identical in the DNS resolution. If the IDN TLD and its variants are
delegated to different registry, it will cause phishing problems. In
order to avoid the possible phishing, these IDN TLD SHOULD be
delegated to the same registry. Based on the current technology,
there are two technique: DNAME and NS records which can be used in
the IDN TLD variants implementation. The following section will
Yao & Lee Expires April 16, 2010 [Page 6]
Internet-Draft tld October 2009
discuss the usage of DNAME and NS resource records, and its relative
policy to manage the IDN TLD and its variants.
5.2. IDN TLD variants in the root
5.2.1. DNAME is not proper for IDN TLD variants
If the DNAME is implemented into the IDN TLD variants, some domain
names may not be resolved by the DNAME unaware resolvers. The
synthesized CNAME RR for the DNAME has the TTL Zero, which will cause
too much load to the root servers since many DNAME-unaware resolvers
will not cache the synthesized CNAME RR for the DNAME and lookup from
the root when they receive the requests related to DNAME. The easy
mis-configuration problem by the DNS administrator is also a problem
to make the DNS administrators and the registrant be confused about
the domain name availability. So the problems above make the DNAME
un-proper for applying the DNAME to IDN TLD variants.
5.2.2. NS is good for IDN TLD variants
The DNS administrators can apply NS records to IDN TLD variants. In
registration policy, the original IDN TLD and its IDN TLD variants
SHOULD be allocated to the same registrant. For the DNS
administration, the configuration of the original IDN TLD and its
variant SHOULD be same. That is that any parameters or configuration
applied to the original IDN TLD SHOULD be available to its variants.
This can guarantee that the resolution in the root for the IDN TLD
and its variants are identical.
5.3. The second level names under the IDN TLD variants
Whether DNAME or NS is used for the IDN TLD and its variants, the DNS
administrator can consider three factors:
o Are IDN TLD variants often used or resolved by the internet users?
o DNS servers' performance?
o The DNS administrators' knowledge of DNAME?
5.3.1. Apply DNAME
If some of the following criterias are satisfied, we can consider to
use the DNAME in the second level domain names.
o The IDN TLD variants are seldom used or resolved by the internet
users and the owner of the domain name can bear its potential
resolving failure
o The DNS servers' performance is good enough to support a lot of
resolution from the DNAME-unaware resolvers
Yao & Lee Expires April 16, 2010 [Page 7]
Internet-Draft tld October 2009
o The DNS administrator has the knowledge of DNAME, and can
configure it properly
We can use the following configuration form:
[the IDN TLD variants] DNAME TTL IN [the original IDN TLD]
Since the owner of DNAME does not redirect itself, the other RR
records except NS DNAME records under the IDN TLD variants SHOULD be
same with the original IDN TLD in the DNS administration.
5.3.2. Apply NS
If some of the following criterias are satisfied, we can consider to
use the NS in the second level domain names.
o The IDN TLD variants are often used or resolved by the internet
users and the owner of the domain name can not bear the possible
resolving failure
o The DNS servers' performance is not good enough to support a lot
of resolution from the DNAME-unaware resolvers
o The DNS administrator has not the knowledge of DNAME, and can not
configure it properly
In order to avoid the possible phishing or confusing, the
configuration of names under the original IDN TLD and its variant
SHOULD be same in the DNS administration. That is that any
parameters or configuration applied to the names of the original IDN
TLD SHOULD be available to the names of its variants. This can
guarantee that the resolutions in the IDN TLD and its variants are
identical.
6. IANA Considerations
There is no IANA consideration.
7. Security Considerations
If IDN TLD variants are implemented, this guideline is suggested to
be used to avoid the possible phishing
8. Acknowledgements
Some ideas are discussed in the ICANN IDN variant working group.
Some nice comments are from Harald Alvestrand in this group. Thanks
a lot to Sun Guonian for his helpful discussion with me about DNAME
technology.
Yao & Lee Expires April 16, 2010 [Page 8]
Internet-Draft tld October 2009
9. Change History
[[anchor18: RFC Editor: Please remove this section.]]
9.1. draft-yao-dnsop-idntld-implementation: Version 00
o IDN TLD variants implementation guidelines"
10. References
10.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",
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.
[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.
[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.
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290,
December 2005.
Yao & Lee Expires April 16, 2010 [Page 9]
Internet-Draft tld October 2009
10.2. Informative References
[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 April 16, 2010 [Page 10]