ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity
Files
99b792d88bcc69a1a4155e308f6114e5b663ba77
bind9/doc/draft/draft-ietf-idn-icu-00.txt
David Lawrence 9beb71d609 current idn working group drafts
2000-11-27 09:41:57 +00:00

515 lines
22 KiB
Plaintext
Raw Blame History

IETF IDN Working Group Seungik Lee, Hyewon Shin, Dongman Lee
Internet Draft ICU
draft-ietf-idn-icu-00.txt Eunyong Park, Sungil Kim
Expires: 14 January 2001 KKU, Netpia.com
14 July 2000
Architecture of Internationalized Domain Name System
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
1. Abstract
For restrict use of Domain Name System (DNS) for domain names with
alphanumeric characters only, there needs a way to find an Internet
host using multi-lingual domain names: Internationalized Domain Name
System (IDNS).
This document describes how multi-lingual domain names are handled in
a new protocol scheme for IDNS servers and resolvers in architectural
view and it updates the [RFC1035] but still preserves the backward
compatibility with the current DNS protocol.
2. Conventions used in this document
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 [RFC2119].
"IDNS" (Internationalized Domain Name System) is used here to
indicate a new system designed for a domain name service, which
supports multi-lingual domain names.
"The current/conventional DNS" or "DNS" (Domain Name System) is used
here to indicate the domain name systems currently in use. It
fulfills the [RFC1034, RFC1035], but implementations and functional
operations may be different from each other.
The "alphanumeric" character data used here is the character set that
is allowed for a domain name in DNS query format, [a-zA-Z0-9-].
3. Introduction
Domain Name System (DNS) has eliminated the difficulty of remembering
the IP addresses. As the Internet becomes spread over all the people,
the likelihood that the people who are not familiar with alphanumeric
characters use the Internet increases. The domain names in
alphanumeric characters are difficult to remember or use for the
people who is not educated English. Therefore, it needs a way to find
an Internet host using multi-lingual domain name: Internationalized
Domain Name System.
3.1 The current issues of IDNS
IDNS maps a name to an IP address as the typical DNS does, but it
allows domain names to contain multi-lingual characters. The multi-
lingual characters need to be encoded/decoded into one standardized
format, and it needs changes in the conventional DNS protocol
described in [RFC1034] and [RFC1035]. But it is required to minimize
the changes in the present DNS protocol so that it guarantees the
backward compatibility.
The IDNS issues have been discussed in IETF IDN Working Group. These
issues are well described in [IDN-REQ]. The main issues are:
- Compatibility and interoperability. The DNS protocol is in use
widely in the Internet. Although a new protocol is introduced for DNS,
the current protocol may be used with no changes. Therefore, a new
design for DNS protocol, IDNS must provide backward compatibility and
interoperability with the current DNS.
- Internationalization. IDNS is on the purpose of using multi-lingual
domain names. The international character data must be represented by
one standardized format in domain names.
- Canonicalization. DNS indexes and matches domain names to look up a
domain name from zone data. In the conventional DNS, canonicalization
is subjected to US-ASCII only. However, every multi-lingual character
data must be canonicalized in its own rules for a DNS standardized
matching policy, e.g. case-insensitive matching rule.
- Operational issues. IDNS uses international character data for
domain names. Normalization and canonicalization of domain names are
needed in addition to the current DNS operations. IDNS also needs an
operation for interoperability with the current DNS. Therefore, it is
needed to specify the operational guidelines for IDNS.
3.2 Overview of the proposed scheme
Our proposed scheme for IDNS is also subjected on the issues
described earlier to fulfill the requirements of IDN [IDN-REQ].
The proposed scheme can be summarized as following:
- The IN bit, which is reserved and currently unused in the DNS
query/response format header, is used to distinguish between the
queries generated by IDNS servers or resolvers and those of non-IDNS
ones [Oscarsson]. This mechanism is also needed to indicate whether
the query is generated by the appropriate IDNS operations for
canonicalization and normalization or not.
- The multi-lingual domain names are encoded into UTF-8 as a wire
format. UTF-8 is recommended as a default character encoding scheme
(CES) in the creation of new protocols which transmit text in
[RFC2130]. This scheme allows the IDNS server to handle the DNS query
from non-IDNS servers or resolvers because the ASCII code has no
changes in UTF-8.
- The UTF-8 domain names must be case-folded before transmission. It
minimizes the overhead on server's operations of matching names in
case-insensitive. It also guarantees that the result of caching
queries can be used without any further normalization and
canonicalization. If IDNS server gets non-IDNS query that is not
case-folded, it case-folds the query before transmitting to another
servers.
4. Design considerations
Our proposed scheme is designed to fulfill the requirements of IETF
IDN WG [IDN-REQ]. All the methods for IDNS schemes must be approved
by the requirements documents. The design described in this document
is based on these requirements.
4.1 Protocol Extensions
To indicate an IDNS query format, we use an unallocated bit in the
current DNS query format header, named 'IN' bit [Oscarsson]. All IDNS
queries are set IN bit to 1. Without this bit set to 1, we cannot
guarantee that the query is in the appropriate format for IDNS.
'IN' bit is to indicate whether the query is from IDNS
resolvers/servers or not. It also reduces overhead on canonicalizing
operation at IDNS server. It will be described further in <4.4.
Canonicalization>.
We devise new operations and new structures of resolvers and name
servers to add the multi-lingual domain name handling features into
the DNS. This causes changes of all DNS servers and resolvers to use
multi-lingual domain names. The new architectures for resolvers and
servers will be described in <5. Architectures>
4.2 Compatibility and interoperability
The 'IN' bit is valid bit location of query for the conventional DNS
protocol to be set to zero [RFC1035]. And operations and structures
of IDNS preserve the conventional rules of DNS to guarantee the
interoperability with the conventional DNS servers or resolvers so
that the changes are optional. These make this scheme for IDNS
compatible with the current protocol.
Although the current DNS protocol uses 7-bit ASCII characters only,
the query format of the current DNS protocol set is 8 bit-clean.
Therefore, we can guarantee the backward compatibility and
interoperability with the current DNS using UTF-8 code because the
ASCII code is preserved with no changes in UTF-8.
Note: There are also in use implementations that are compatible with
the current DNS but extend their operations to use UTF-8 domain names.
The IDNS described here interoperates well with these implementations.
The interoperability with these implementations will be described in
<5.4 Interoperability with the current DNS>.
4.3 Internationalization
All international character data must be represented in one
standardized format and the standardized format must be compatible
with the current ASCII-based protocols. Therefore, the coded
character set (CCS) for IDNS protocol must be Unicode [Unicode], and
be encoded using the UTF-8 [RFC2279] character encoding scheme (CES).
The client-side interface may allow the domain names encoded in any
local character sets, Unicode, ASCII and so on. But they must be
encoded into Unicode before being used in IDNS resolver. The IDNS
resolver accepts Unicode character data only, and converts it to UTF-
8 finally for transmission.
4.4 Canonicalization
In the current DNS protocol, the domain names are matched in case-
insensitive. Therefore, the domain names in a query and zone file
must be case-folded before equivalence test.
The case-folding issue has been discussed for a long time in IETF IDN
WG. The main problem is for case folding in locale-dependent. Some
different local characters are overlapped within case-folded format.
For example, Latin capital letter I (U+0049) case-folded to lower
case in the Turkish context will become Latin small letter dotless i
(U+0131). But in the English context, it will become Latin small
letter i (U+0069)
Therefore, we case-fold the domain names in locale-independent in our
new IDNS design with a method defined in [UTR21].
Multi-lingual domain names should be case-folded in IDNS resolvers or
IDNS servers before transmitting to other IDNS/DNS servers. That is,
IDNS resolver should case-fold the domain name and converts it to
UTF-8 before transmission. In case of IDNS server, if it gets a query
with IN bit set to 1, then it needs not to make the multi-lingual
domain name canonicalized anymore. If the IDNS server gets a query
with IN bit set to 0, then it cannot determine the query is
appropriate canonicalized format for IDNS server, so that it case-
folds that multi-lingual domain name in the query, and set 'IN' bit
to 1.
The current DNS queries contain the original case of domain names to
preserve the original cases. To be consistent with this rule, all
case-folded multi-lingual domain names should be stored by IDNS
resolvers or servers before case-folding, and should be restored
before sending response.
In the case of case-folding UTF-8 code, using the case-folding method
in [UTR21], the UTF-8 should be converted to Unicode and it must be
mapped to the mapping table finally. Of course that if we could make
a case-folding mapping table of UTF-8 character data, this overhead
could be reduced.
However it cannot avoid an overhead in IDNS servers for
canonicalization, because the canonicalization of international
character data is complicated.
To minimize this overhead, we use 'IN' bit to indicate that the
canonicalization for the query has been already handled. That means
it needs not canonicalization operation anymore. The detailed
operations according to the 'IN' bit are described later in <5.
Architectures>.
With international character data, the canonicalization (e.g. case-
folding) is much more complicated than the one with US-ASCII, and is
different from each other's by their locale contexts.
But this document doesn't specify any method or recommendation more
than case-folding. For canonicalization of international character
data, [UTR15] is a good start. It must be discussed further and
specified in the IDNS protocol specification.
4.5 Operational issues
In the current DNS scheme, it uses only ASCII code for a wire format.
But our new IDNS scheme uses UTF-8 code for a wire format. All the
IDNS resolvers must transmit queries encoded in UTF-8 and case-folded.
This format can be guaranteed by checking the IN bit: if IN bit is
set to 1, the query is encoded in UTF-8 and case-folded. Otherwise
the IDNS server cannot assure that the query is encoded in UTF-8 and
case-folded. Therefore it needs additional operations for encoding to
UTF-8 and case-folding, etc in this case.
The current DNS resolvers transmit the queries in ASCII code. But
it's not considerable in IDNS servers because the ASCII code is
preserved with no changes in UTF-8.
Some applications and resolvers transmit the queries in UTF-8
although they don't fit on the new IDNS resolvers' structures, e.g.
Microsoft's DNS servers. We cannot guarantee that those queries are
case-folded correctly. Therefore, the IDNS servers should convert
them to appropriate IDNS queries instead of the IDNS resolver in that
case.
All detailed operations of IDNS servers and resolvers are described
in <5. Architectures>.
5. Architectures
5.1 New header format
A new IDNS servers and resolvers must interoperate with the ones of
current DNS. Therefore, we need a way to determine whether the query
is for IDN or not. For this reason, we use a new header format as
proposed in [Oscarsson].
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA|IN|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The IDNS resolvers and servers identify themselves in a query or a
response by setting the 'IN' bit to 1 in the DNS query/response
format header. This bit is defined to be zero by default in the
current DNS servers and resolvers.
5.2 Structures of IDNS resolvers
To use multi-lingual domain names with IDNS servers, all the IDNS/DNS
resolvers must generate the query in a format of UTF-8 or ASCII. The
design of a resolver could be different with each other according to
the local operating systems or applications. We propose new design
guidelines of a resolver for a new standardization.
The IDNS resolver accepts Unicode from user interface for domain
names. The other character sets should be rejected. It encodes all
such character data into UTF-8 for transmission to name servers.
The procedures of the operation of an IDNS resolver are below:
<1>. If the resolver gets a domain name in Unicode or ASCII then it
stores the original domain name query. Otherwise the request for
lookup is rejected. In the current DNS protocol, the original case of
the domain name should be preserved. Therefore, the resolver must
store the original cases of the domain names before canonicalization
(e.g. case-folding).
<2>. Make the domain name case-folded with locale-independent case-
mapping table defined in [UTR21].
<3>. Convert it to UTF-8.
<4>. Set IN bit to 1. It indicates the query is from IDNS resolver
and the format is UTF-8, case-folded.
<5>. Send request query to name servers.
<6>. Restore the original domain name query into the response query
format.
<7>. Send response to the application.
5.3 Structures of IDNS servers
The operation of IDNS server is similar to the current one of DNS
server, but the IDNS server accepts UTF-8 queries and converts them
to the appropriate formats additionally.
The IDNS server distinguishes between the IDNS queries and DNS
queries by checking IN bit in the query/response format header.
According to the 'IN' bit, it operates differently.
The procedures of the operation of an IDNS server are below:
<1>. If the IN bit in the query/response format header is set to 1
then it matches the domain name within zone file data or forwards
request query to resolve. It operates as same as the operations of
the current DNS servers but retrieves UTF-8 code. In this case, it
needs not to make domain name canonicalized because the domain name
is already canonicalized in the previous procedures of IDNS resolvers
or IDNS servers. Go to step <7>.
<2>. Set IN bit to 1.
<3>. Store the original domain name query.
<4>. Make the domain name case-folded with locale-independent case-
mapping table defined in [UTR21].
<5>. Match the domain name within zone file data or send request
query to lookup.
<6>. Restore the original domain name query into the response query
format.
<7>. Send response for the query to the resolver or the other server
requested.
5.4 Interoperability with the current DNS
The DNS servers and resolvers accept domain names in ASCII only. But
IDNS servers and resolvers accept domain names in UTF-8. Therefore,
the queries from DNS ones to IDNS ones can be well handled because
the UTF-8 is a superset of ASCII code. But the queries from IDNS ones
to DNS ones will be rejected because the UTF-8 code is beyond the
range of ASCII code.
Note: There are some implementations which can handle UTF-8 domain
names although they don't fit on this specification of IDNS and fully
implemented with DNS protocol specification, e.g. Microsoft's DNS
server and resolvers. In this case, we cannot guarantee that the
queries from these 3rd-party implementations are encoded into UTF-8
and well canonicalized. But this queries are set 'IN' bit to 0, so
that the IDNS evaluates whether the domain name is the range of UTF-8
or not, and converts it into UTF-8 and makes it canonicalized finally.
6. Security Considerations
This architecture of IDNS uses 8bit-clean queries for transmission
and the UTF-8 code is handled instead of ASCII. The DNS protocol has
already allocated 8bit query format for domain names Therefore, the
IDNS protocol inherits the security issues for the current DNS.
Canonicalization of IDNS is defined in [UTR15] and case folding in
[UTR21]. All security issues related with canonicalization or
normalization inherits ones described in [UTR15, UTR21].
As always with data, if software does not check for data that can be
a problem, security may be affected. As more characters than ASCII is
allowed, software only expecting ASCII and with no checks may now get
security problems.
7. References
[IDN-REQ] James Seng, "Requirements of Internationalized Domain
Names," Internet Draft, June 2000
[KWAN] Stuart Kwan, "Using the UTF-8 Character Set in the
Domain Name System," Internet Draft, February 2000
[Oscarsson] Dan Oscarsson, "Internationalisation of the Domain Name
Service," Internet Draft, February 2000
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities," STD 13, RFC 1034, USC/ISI, November 1987
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification," STD 13, RFC 1035, USC/ISI, November
1987
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
[RFC2130] C. Weider et. Al., "The Report of the IAB Character Set
Workshop held 29 February - 1 March 1996," RFC 2130,
Apr 1997.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO
10646," RFC 2279, January 1998
[RFC2535] D. Eastlake, "Domain Name System Security Extensions,"
RFC 2535, March 1999
[UNICODE] The Unicode Consortium, "The Unicode Standard - Version
3.0," http://www.unicode.org/unicode/
[UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms",
Unicode Technical Report #15, Nov 1999,
http://www.unicode.org/unicode/reports/tr15/
[UTR21] Mark Davis, "Case Mappings," Unicode Technical Report
#21, May 2000,
http://www.unicode.org/unicode/reports/tr21
8. Acknowledgments
Kyoungseok Kim <gimgs@asadal.cs.pusan.ac.kr>
Chinhyun Bae <piano@netpia.com>
9. Author's Addresses
Seungik Lee
Email: silee@icu.ac.kr
Hyewon Shin
Email: hwshin@icu.ac.kr
Dongman Lee
Email: dlee@icu.ac.kr
Information & Communications University
58-4 Whaam-dong Yuseong-gu Taejon, 305-348 Korea
Eunyong Park
Email: eunyong@eunyong.pe.kr
Konkuk University
93-1 Mojindong, Kwangjin-ku Seoul, 143-701 Korea
Sungil Kim
Email: clicky@netpia.com
Netpia.com
35-1 8-ga Youngdeungpo-dong Youngdeungpo-gu Seoul, 150-038 Korea
View Git Blame Copy Permalink