Unicode Resource Records of DNS Host Information for Internationalized Domain Names
draft-park-idnabis-unirr-00

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 April 22, 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 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

Although Internationalized Domain Names in Applications (IDNA) contributes the population of the Internationalized Domains, it forces human DNS managers to handle unreadable DNS records. In order to enable human managers to easily edit or modify DNS records, DNS servers should allow Unicode resource records. This document defines the formats of DNS Resource Records and a translation process that supports Unicode Resource Records without ruining the interoperability with existing DNS infrastructure.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Statements
    3.1.  Applicable types of DNS Resource Records
        3.1.1.  Administrative Resource Records
        3.1.2.  Host Information Resource Records
    3.2.  Translation Process
4.  DNS Resource Records
    4.1.  A Resource Record
    4.2.  AAAA Resource Record
    4.3.  CNAME Resource Record
    4.4.  PTR Resource Record
5.  Translation Process
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

Internationalized Domain Names in Applications (IDNA) [RFC3490] [1] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) has applications use an "ACE label" (ACE stands for ASCII Compatible Encoding) to represent an Internationalized Domain Names (IDN). The main advantage of IDNA is that lower-layer protocols need not be aware of the existence of IDNA. For the reason, IDNA is widely accepted where IDN is needed, especially Web browsers. Though it does not require any changes of existing DNS actors including DNS servers, resolvers, and protocol elements, it demands the use of ACE label in DNS database. Since an ACE label is difficult for human to read or infer, human managers cannot directly edit DNS database and cannot easily examine the validness of DNS records.

In order to use a Unicode label instead of an ACE label in the DNS database, several technical factors should be considered. First, the types of DNS Resource Records should be decided. Some types are not adequate to hold Unicode [3] (, “The Unicode Consortium. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).,” .) label due to the interoperability with other DNS standards. Second, a translation process of DNS server that does not hurt the interoperability with IDNA should be considered. By inserting a thin translation process between DNS database and DNS protocols, the support of Unicode Resource Records is possible while maintaining the interoperability.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [2].

Unicode (, “The Unicode Consortium. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).,” .) [3] is a coded character set containing tens of thousands of characters. A single Unicode code point is denoted by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two hexadecimal numbers separated by "..", with no prefixes.

A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". (The zero-length root label described in [STD13], which can be explicit as in "www.example.com." or implicit as in "www.example.com", is not considered a label in this specification.) IDNA extends the set of usable characters in labels that are text. For the rest of this document, the term "label" is shorthand for "text label", and "every label" means "every text label".

An ACE label is an internationalized label that can be rendered in ASCII and is equivalent to an internationalized label that cannot be rendered in ASCII.

3.  Problem Statements

3.1.  Applicable types of DNS Resource Records

A large number of Resource Records have been defined over the 25 years of the DNS specification. However, applicable types are restricted due to not all Resource Records can hold IDN data. The applicable types can be grouped with the purpose of administrative and host information.

3.1.1.  Administrative Resource Records

SOA, NS, and MX Resource Records are defined for the administrative purpose. SOA Resource Record describes the global characteristics of the zone. NS Resource Record defines name servers that are authoritative for the zone. MX Resource Record defines the mail servers for the zone. These Resource Records are in close connection with other standards and this document does not have any intention to update the existing standards so IDNA standard does. Unless the related standards are revised to invite the use of IDNA, these Resource Records SHOULD NOT be the target of this standard.

3.1.2.  Host Information Resource Records

A, CNAME, PTR, and AAAA Resource Records are defined for holding host information of the zone. A and AAAA Resource Records are used to indicate IPv4 and IPv6 address for the target domain name respectively. CNAME Resource Record is used to allows one host be defined as the alias name for another host. PTR Resource Record stands for resolving IP address into host name.

3.2.  Translation Process

An ACE-encoded Resource Record is necessary to support the interoperability of existing DNS standards, but human mangers suffer for handling it. In order to resolve this issue, DNS Resource Records should be written with Unicode characters. However, this approach will conflict existing DNS infrastructure. To avoid this conflict, a DNS server should translate an ACE-encoded Resource Record in a DNS query packet into a Unicode Resource Record. Reversely, it should also translate a Unicode Resource Record into an ACE-encoded Resource Record in a DNS answer packet. By adopting this translation process into a DNS server, human managers can freely use Unicode Resource Records while maintaining the interoperability with IDNA.

4.  DNS Resource Records

4.1.  A Resource Record

In A Resource Record, the name field of host name MAY be written with Unicode character strings. 'hangang'{U+D55C U+AC15} represents Han River in Seoul, Korea. Actually, {U+D55C U+AC15} will be replaced with the corresponding Korean characters in DNS Resource Record. A sample record is as below.

{U+D55C U+AC15} IN A 192.168.0.4

4.2.  AAAA Resource Record

In AAAA Resource Record, the name field of host name MAY be written with Unicode character strings. A sample record is as below.

{U+D55C U+AC15} IN AAAA 2001:db8::1

4.3.  CNAME Resource Record

In CNAME Resource Record, the name field and the canonical-name of the host name MAY be written with Unicode character strings. A sample record is as below. 'Arisoo'{U+C544 U+B9AC U+C218} represents the ancient name of Han River.

{U+C544 U+B9AC U+C218} IN CNAME {U+D55C U+AC15}.example.com

4.4.  PTR Resource Record

In PTR Resource Record, the right side of the PTR record can be written with Unicode character strings.

4 IN PTR {U+D55C U+AC15}.example.com

5.  Translation Process

When a Unicode-supporting DNS server receives a DNS query packet having an ACE-encoded Resource Record, the server extracts the Resource Record from the packet and translates it into the corresponding Unicode Resource Record. The converted Unicode Resource Record is used to find the matching host information in the DNS database. If the server finds the matching data, it makes a DNS answer packet containing an ACE-encoded Resource Record converted from the matching Unicode Resource Record.

The components and interfaces between them can be represented pictorially as:

   +-----------------------------------+
   |  +-----------------------------+  |
   |  |        Application          |  |
   |  |   (ToASCII and ToUnicode    |  |
   |  |      operations may be      |  |
   |  |        called here)         |  |
   |  +-----------------------------+  |
   |                  ^                | End system
   |                  |                |
   |Call to resolver: |                |
   |             ACE  |                |
   |                  v                |
   |          +----------+             |
   |          | Resolver |             |
   |          +----------+             |
   |                ^                  |
   +----------------|------------------+
      DNS protocol: |
                ACE |
                    |
   +----------------|------------------+
   |                v                  |
   |  +------------------------------+ |
   |  | Unicode/ACE label translator | |
   |  +------------------------------+ |
   |                    ^              | DNS servers
   |   Resource Access: |              |
   |          Unicode   |              |
   |                    v              |
   |  +------------------------------+ |
   |  |   Unicode Resource Records   | |
   |  +------------------------------+ |
   |                                   |
   +-----------------------------------+

6.  Security Considerations

All securuty issues related to IDNA should be samely considered.

7.  IANA Considerations

This document has no actions for IANA.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses