[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                             J. Yao
Internet-Draft                                                    X. Lee
Intended status: Informational                                     CNNIC
Expires: April 25, 2010                                 October 22, 2009


               IDN TLD Variants Implementation Guideline
              draft-yao-dnsop-idntld-implementation-01.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 25, 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 25, 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 25, 2010                 [Page 2]


Internet-Draft                     tld                      October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  IDN TLD Variant  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The principle of IDN TLD variants implementation . . . . . . .  5
   4.  IDN TLD variants implementation guideline  . . . . . . . . . .  5
     4.1.  The requirement of the root server operation . . . . . . .  5
     4.2.  Apply DNAME to IDN TLD variants in the root  . . . . . . .  5
       4.2.1.  DNAME issues . . . . . . . . . . . . . . . . . . . . .  6
       4.2.2.  DNAME should be scrutinized before being put into
               the root . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Apply NS to IDN TLD variants in the root . . . . . . . . .  7
       4.3.1.  NS issues  . . . . . . . . . . . . . . . . . . . . . .  7
       4.3.2.  Apply DNAME or NS to the second level names in the
               IDN TLD variants . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Change History . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  draft-yao-dnsop-idntld-implementation: Version 00  . . . .  9
     8.2.  draft-yao-dnsop-idntld-implementation: Version 01  . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

























Yao & Lee                Expires April 25, 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 25, 2010                 [Page 4]


Internet-Draft                     tld                      October 2009


3.  The principle of IDN TLD variants implementation

   Two principle of IDN TLD variants implementation are:
   o  Same DNS resolution to the names under the original IDN TLD and
      its variants
   o  the same names under the original IDN TLD and its variants belong
      to the same registrant
   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 TLDs SHOULD be delegated to the same registry.  Based on the
   current technology, there are two techniques: DNAME and NS records
   which can be used in the IDN TLD variants implementation.  The
   following section will discuss the usage of DNAME and NS resource
   records, and its relative policy to manage the IDN TLD and its
   variants.


4.  IDN TLD variants implementation guideline

4.1.  The requirement of the root server operation

   [RFC2870] points out that the resolution of domain names on the
   internet is critically dependent on the proper, safe, and secure
   operation of the root domain name servers while the root domain name
   servers are seen as a crucial part of the correct, safe, reliable,
   and secure operation of the internet infrastructure.  The Internet
   Corporation for Assigned Names and Numbers (ICANN) are responsible
   for making the total system performance, robustness, and reliability
   in the root name servers.  So the root server should guarantee that
   the server can run as stable as possible.  Any change or update to
   the root servers should be done in caution.

4.2.  Apply DNAME to IDN TLD variants in the root

   A DNAME record is defined in [RFC2672].  The main function of the
   DNAME is to provide the redirection from a part of the DNS name tree
   to another part of the DNS name tree.  The following two characters
   of DNAME can be considered to be two good arguments to support DNAME
   to be applied to the IDN TLD variants in the root.




Yao & Lee                Expires April 25, 2010                 [Page 5]


Internet-Draft                     tld                      October 2009


   o  redirection the whole sub-tree of the domain name tree to another
      one
   o  DNAME does not direct itself (the owner name).
   We can use the following configuration form:

     < the IDN TLD variants > TTL IN DNAME < its original one >

   If this model can be workable, DNAME can be considered as the
   simplest mechanism to make the DNS resolution of the names in the
   original IDN TLD and its variants to be same or identical.  For the
   IDN TLD operators, only one ZONE is needed to be kept instead of
   multiple zones for the IDN TLD variants.  The root helps the
   direction of the DNS resolution of the IDN TLD variants to the
   original IDN TLD.  This method makes the DNS resolution of the
   original IDN TLD and its variants to be identical via the root
   solution.  If DNAME is put into the root, some issues should be
   considered.  The following section will discuss these issues.

4.2.1.  DNAME issues

4.2.1.1.  DNAME is a new technology

   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.  Some interesting
   things may happen if DNAME is used.

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







Yao & Lee                Expires April 25, 2010                 [Page 6]


Internet-Draft                     tld                      October 2009


4.2.1.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.2.2.  DNAME should be scrutinized before being put into the root

   If the DNAME is put into the root for the IDN TLD variants, the
   synthesized CNAME RR for the DNAME has the TTL Zero according to
   [RFC2672], 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 the messages 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.  Whether the issues discussed above will make the root
   server running unreliable or unstable is unclear.  So the ICANN
   should scrutinize all the DNAME issues and consider whether these
   will impact the stable running of the internet before deciding to put
   the DNAME into the root.

4.3.  Apply NS to IDN TLD variants in the root

4.3.1.  NS issues

   The NS record is defined in the basic DNS documents [RFC1034] and
   [RFC1035].  NS resource record is deployed widely.  The practice in
   the root has proven that the NS resource record in the root is safe
   and reliable.  Putting the NS records in the root does not impact the
   root much.  If the 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
   delegation.  In registration policy, the original IDN TLD and its IDN
   TLD variants SHOULD be allocated to the same registry.

4.3.2.  Apply DNAME or NS to the second level names in the IDN TLD
        variants

   If the NS resources records are used in the root for the IDN TLD
   variants, some technology combined with some policy should be
   applied.  Whether DNAME or NS is used for the second level names in



Yao & Lee                Expires April 25, 2010                 [Page 7]


Internet-Draft                     tld                      October 2009


   the IDN TLD and its variants, the DNS administrator can consider the
   three factors:
   o  Are IDN TLD variants often used or resolved by the internet users?
   o  IDN TLD DNS servers' performance?
   o  The DNS administrators' knowledge of DNAME?

4.3.2.1.  Apply DNAME to the second level names in the IDN TLD variants

   If some of the following criterias are satisfied, we can consider to
   use the DNAME in the second level domain names.
   o  The names in the IDN TLD variants are seldom used or resolved by
      the internet users
   o  The DNS servers' performance is good enough to support a lot of
      resolution from the DNAME-unaware resolvers
   o  The DNS administrator has the knowledge of DNAME, and can
      configure it properly
   There are two ways to apply DNAME to the second level names in the
   IDN TLD variants zone.

   **Apply DNAME to all names

   We can use the following configuration form in the zone apex of the
   IDN TLD variants:

   <the IDN TLD variants> TTL IN DNAME <its original one>

   **Apply DNAME to the name which the registrant wants to be DNAMEed

   We can use the following configuration form in the zone of the IDN
   TLD variants:

<names in the IDN TLD variants> TTL IN DNAME <names in its original one>

   If the second method is used, the other resource records except NS
   DNAME records under the IDN TLD variants SHOULD be same with the
   original IDN TLD in the DNS administration since the owner of DNAME
   does not redirect itself.

4.3.2.2.  Apply NS to the second level names in the IDN TLD variants

   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
   o  The DNS servers' performance is not good enough to support a lot
      of resolution from the DNAME-unaware resolvers





Yao & Lee                Expires April 25, 2010                 [Page 8]


Internet-Draft                     tld                      October 2009


   o  The DNS administrator has not the knowledge of DNAME, and can not
      configure it properly
   The same name under the original IDN TLD and its variants should
   belong to the same registrant via some policy.  In order to avoid the
   possible phishing or confusing, the configuration of names under the
   original IDN TLD and its variants 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.


5.  IANA Considerations

   There is no IANA consideration.


6.  Security Considerations

   If IDN TLD variants are implemented, this guideline is suggested to
   be used to avoid the possible phishing.  If we apply NS to the second
   level names in the IDN TLD variants, we can not guarantee that every
   level of domain names under the IDN TLD and its variants are
   configured to be same.  We can only specify some policy to make the
   same name under the IDN TLD and its variants to be owned by the same
   registrant.  The registrant is unlikely to phishing itself via the
   name under the IDN TLD and its variants.


7.  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.  The authors thanks the following experts for the kind
   comments and suggestions to this draft: Andrew Sullivan, Paul
   Hoffman, Alfred Hones and more.


8.  Change History

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

8.1.  draft-yao-dnsop-idntld-implementation: Version 00

   o  IDN TLD variants implementation guidelines





Yao & Lee                Expires April 25, 2010                 [Page 9]


Internet-Draft                     tld                      October 2009


8.2.  draft-yao-dnsop-idntld-implementation: Version 01

   o  adjust the sections arrangement
   o  change the category from BCP to INFO
   o  refine some contents based on the comments from DNSOP and DNSEXT
      mailing list


9.  References

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

   [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
              Name Server Operational Requirements", BCP 40, RFC 2870,
              June 2000.

   [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



Yao & Lee                Expires April 25, 2010                [Page 10]


Internet-Draft                     tld                      October 2009


              Internationalized Domain Names (IDN)", RFC 4290,
              December 2005.

9.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 25, 2010                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/