Internationalized Domain Names and ENUM Protocol Suite

Internationalized Domain Names and ENUM Protocol Suite
Minseok Pyo
Sunyoung Han
Keecheon Kim
Konkuk University
1 Hwayang-dong Gwangjin-gu
Konkuk Univ. Seoul, Korea
+82-2-450-3537
Konkuk University
1 Hwayang-dong Gwangjin-gu
Konkuk Univ. Seoul, Korea
+82-2-450-3537
Konkuk University
1 Hwayang-dong Gwangjin-gu
Konkuk Univ. Seoul, Korea
+82-2-450-3518
[email protected]
[email protected]
[email protected]
ABSTRACT
As the development of Internet usage and globalization of Internet,
the requests of Internationalized Domain Names (IDN) are being
increased. To solve this request, many IDN solutions are
developed. But there are problems of interoperability and
backward compatibility are emerged. In this paper, we suggest
IDN protocol which supports ENUM and IDN Test Suite on
IPv4/IPv6 dual-stack for guarantee interoperability and backward
compatibility.
Categories and Subject Descriptors
C.2.2 [Computer-Communication Networks]:
Network Protocols – application
General Terms
Standardization
Keywords
DNS, IDN, ENUM
1. INTRODUCTION
Many problems were brought up in Internet because the user of
Internet and the area of users are spread around the world as
growth of Internet and various developments of the applied
services. The problems of DNS are the part of new requirement
among them, and they need to be investigated more.
First, non-English speaking countries like Korea, China, Japan,
etc. can’t use Domain Name with their language because the
existing DNS has supported exceptional Domain Name which is
constructed only the type of ASCII such as alphabet, digit and
hyphen(-) [1], [2]. Indeed, as all of the Domain Names are
expressed only English which is based on ASCII, users who are in
non-English speaking countries has complained. Second, as the
Internet growth, various communication systems are integrated
into Internet. And, there are so many URI to remember and use.
Web, E-mail, FTP, Telnet, Phone, Fax and etc. And, it has been
brought up to be problems that it cannot help using the Domain
Name of the existing ASCII type in new applied environment
where the acting of DNS are increased as the home-networking
and mobile-networking are augmented. Those problems make
troubles in the popularization and the globalization of Internet and
the fixing of various applied environment.
Many countries have encouraged researches and developments of
Copyright is held by the author/owner(s)
Asia Pacific Advanced Network 2003, 25-29 August 2003, Busan,
Republic of Korea.
Network Research Workshop 2003, 27 August 2003, Busan, Republic of
Korea.
Internationalized Domain Names (IDN), but also E.164 Number
Mapping (ENUM) [6], [11] to solve these problems. And it brings
up the developments of IDN or ENUM relative solutions. For
example, mBIND, ngDN Kit (Korea), iDNS (Singapore) and
idnkit/mDNkit (Japan). But, there’s no solution that support IDN
and ENUM together.
Likewise, many countries have supported to the development of
various IDN relative solutions, but many problems remain yet.
First, the standard specification for the development of IDN is
setting up condition. Second, from this cause, each various
specifications and the methods of encoding have been used. Third,
the compatibility and interoperability among the existing IDN
solutions are also troubles. Fourth, apply IDN on ENUM service.
Fifth, interoperability with the existing DNS (BIND 4.x, BIND
8.x, and BIND 9.x) is a problem, too. Finally, the gearing
problems with various applied services for supporting Internet
services remain to solve.
In this paper, we suggest IDN protocol specification for IPv4/IPv6
dual-stack. Next, interoperability and backward compatibility are
examined by testing and developing of IDN Test Suite and the
constructing of international test bed. Through these testing
conclusions, it makes better circumstance for global Internet users.
This paper is constructed like this: In the second chapter, the
relational investigations such as IDN, encoding, nameprep and
ENUM are introduced. In the third chapter, IPv6 IDN protocol
suite. In the fourth chapter, International IPv6 IDN test bed. In the
fifth chapter, the test results of IDN solutions are examined. And
finally, this paper is concluded.
2. Relative works
2.1 IDN Protocol Mechanism
2.1.1 Internationalizing Domain Names in
Applications (IDNA)
IDN and a mechanism called IDNA for handling them in a
standard fashion. IDN use characters drawn from a large
repertoire (Unicode), but IDNA allows the non-ASCII characters
to be represented using only the ASCII characters already allowed
in so-called host names today. In particular, IDNA does not
depend on any changes to DNS servers, resolvers, or protocol
elements, because the ASCII name service provided by the
existing DNS is entirely sufficient for IDNA. This backwardcompatible representation is required in existing protocols like
DNS, so that IDN can be introduced with no changes to the
existing infrastructure.
This work is supported by NCA(National Computerization Agency) of
Korea for “Research of International Testbed Construction and IPv6
International Domain Name System (IDN)” Project 2002~2003.
IDNA works by allowing applications to use certain ASCII name
labels (beginning with a special prefix ‘xn— ‘) to represent nonASCII name labels. Adding IDNA support to an existing
application entails changes to the application only. If an
application wants to use non-ASCII characters (IDN) in host
names, then encode the IDN, add prefix ‘xn— ‘ and then send it to
DNS. This mechanism uses Punycode and Nemeprep. This
mechanism is IETF proposed standard. [3]
2.1.2 Internationalized Host Names Using Resolvers
and Applications (IDNRA)
IDNRA requires the updating of applications and resolvers, but
once a user has updated these, she or he could immediately start
using internationalized host names. This protocol mechanism
supports IDN by encoding it resolver or application. First,
resolver was updated. The resolver encodes IDN by ACE and
sends it to DNS. Second, application was updated. The
application encodes IDN and sends it to DNS through resolver.
Third, resolver and application were updated. The application
encodes IDN by using UTF-8 algorithm and sends it to resolver.
And, resolver encodes it by using ACE algorithm then resolves it.
This protocol mechanism is that only user applications and the
resolvers on user's systems are updated, no changes are needed to
the DNS protocol or any DNS servers. This mechanism was
merged into IDNA. [7]
2.1.3 Internationalized Domain Names Server
(IDNS)
IDNS requires the updating of DNS Servers. IDNS encodes the
IDN query on server-side and resolve it. So, it brings up the
problem of backward compatibilities and overload on encoding
procedure. But has an advantage that it could support legacy
application which couldn’t use IDN and there’s no change on
client-side.
2.2 IDN relative solutions
Today, many companies have supported the solution of IDN
around the world. The solutions of IDN are as following.
because the domain name which is encoded are satisfies with RFC
1034[1], RFC 1035[2]. [16].
2.2.3 idnkit/mDNkit
idnkit (mDNkit) by JPNIC is the kit which is able to develop
various applied methods in IDN. And it is constructed by the
patched BIND and DNS Proxy Server for supporting 8bit clean.
DNS Proxy Server can perceive various local characters set from
client, and it transmits the real DNS which is encoded by ACE or
UTF after perceiving languages. This DNS Proxy Server always
listens IP address of IDNS or Port number (53). As soon as the
packet reached, it usurps these packets, and encodes with the
information in constructed files. Likewise, it transmits the packet
to DNS. [17]
2.3 Encoding algorithms
2.3.1 ASCII Compatible Encoding (ACE)
ASCII compatible encoding for IDN. For examples, Punycode [4],
DUDE [8], RACE [9], BRACE, TRACE, SACE and etc. These
encoding algorithms encode IDN to ASCII format except ASCII
formatted host names. So, ASCII host names keep there form.
Host names that through these encoding algorithms are formed
ASCII. Therefore satisfy RFC1034 [1], RFC1035 [2]. Now,
Punycode is IETF proposed standard ACE encoding algorithm.
2.3.2 Unicode Transformation Format (UTF)
Unicode Transformation Format is the method of encoding to
transfer Unicode to specified bits letter, and methods to express
Unicode. For examples, UTF-5, UTF-6, UTF-8 [10] and UTF-16.
It also encodes ASCII letters except UTF-8.
2.4 Nameprep
A Stringprep Profile for Internationalized Domain Names.
Nameprep specifies processing rules that will allow users to enter
internationalized domain names in applications and have the
highest chance of getting the content of the strings correct.
Nameprep is used by the IDNA protocol for preparing domain
names. [5]
2.2.1 ngDN Kit
2.5 E.164 Number Mapping (ENUM)
ngDN Kit, the solution of Korean company (Netpia), is able to
distinguish IDN with MSS (Multi-lingual Scan System), and it
also supports all methods of hierarchical domain and keyword
domain. It services distributed native domain system which is able
to manage at the root server in distinguishing IDN. ngDN Kit,
which distinguishes each letter using MSS after receiving
questions from client and encodes it after distinguishing the
encoding of client’s question in using ESS(Encoding Scan
System), was made as the version so that BIND may perceive
8bits letter. [15]
ENUM uses E.164 numbers (telephone numbers) to identifier of
Internet resources. E.164 numbers are globally unique, language
independent
identifiers
for
resources
on
Public
Telecommunication Networks that can support many different
services and protocols. ENUM system is mapped E.164 number to
Internet addresses. So, E.164 numbers should be used as URIs. If
sender inputs E.164 number to ENUM system, then ENUM
convert that as URIs and returns it. Sender could select URI
among returned URIs and uses it to communicate. [11], [12], [13],
[14]
2.2.2 iDNS
3. IPv6 IDN protocol suite
iDNS solution in Singapore accomplishes the acting of Proxy
Name Server. Not it achieves the acting of real Name Server by
itself, but it accomplishes the functions of transmitting the
adapted type’s data packet from client to real DNS as a gobetween and giving back to client what are recollected the
returned data. iDNS supports ACEs, UTFs and various local
character set. When the client requests the resolving to iDNS
server, IDN letters are transformed into Unicode at first, and they
are transformed to apply UTF-5 encoding. iDNS has compatibility
of all standard Internet protocol and the existing client/sever
To solve the requests of IDN and ENUM, and the problems of
there’s. We propose IDN protocol suite on IPv4/IPv6 dual-stack.
This was consisting of next elements. First IDN protocol
specification which supports ENUM service. Second, IDN Test
Suite for test interoperability and backward compatibility among
IDN solutions and DNS. Third, ENUM client. In addition, we’ve
constructed International IPv6 IDN test bed. Figure 1 represents
IDN protocol suite’s architecture.
Figure 2 represents the specification.
IDN&ENUM server
Cellular Phone
IDN Query
ENUM Query
Web server
We’ve implemented prototype of this specification, which is
called mBIND (Multi-lingual BIND). mBIND based on BIND 9
and which was 8-bit clean set.
PDA
IPv4/IPv6
Internet
Computer
ftp server
3.2 IDN Test Suite
Client
mail server
Gateway
PSTN
IDN Test Suite
Other Client
Q:
IDN : http://건국대.대학.kr
A:
ENUM Client
202.30.38.109
2001:220:1017::2
IP Phone
ENUM : 8224503537
http://건국대.대학.kr
mailto:한선영@건국대.대학.kr
sip:한선영@건국대.대학.kr
Figure 1. IDN Protocol Suite Map.
3.1 IPv6 IDN protocol specification.
We propose IPv6 IDN protocol specification to support IDN and
ENUM service. First, specification supports various RR types and
reverses domains. For examples, A, AAAA, A6, DNAME,
ipv6.int, ipv6.arpa and etc. Second, uses IDNA mechanism which
was IETF’s proposed standard. Third, provides a client plug-in
module supports legacy application and non-IDNA application as
a solution in transition period. Fourth, uses NAPTR record to
support ENUM service.
An application which follows IDNA mechanism performs
resolving as same fashion with existing DNS. So the backward
compatibility was guaranteed and there’s no overhead on DNS
server. But, it takes long time periods to settle an IDNA
mechanism. In addition, perhaps many applications will not
support IDN, which was developed in English speaking country.
For that reason, we apply IDN plug-in module to specification for
support legacy application and non-IDNA applications. NonIDNA applications send query then plug-in module encodes it by
Punycode encoding algorithm and resolve it. This process should
be done by following steps. First, plug-in module checks the
query if which contains IDN. ASCII letters were assigned under
0x80 codes. So, if query contains over-0x80 codes, we could
decide the query includes IDN. This is only for DNS area, not for
other area. Second, if the query includes IDN then encode it by
Punycode encoding algorithm. Finally, DNS resolves the query
and returns result to client.
Today, IDN solutions have being operated in various operating
systems. And, it should be considered backward compatibility and
interoperability between the legacy DNS and the new one. For
testing backward compatibility and interoperability, we developed
IDN Test Suite (called Idnslook) which supports various encoding
algorithms and query types on multi-platform. First, it should
support not only basic letter row of ASCII type in the existing
DNS but also Punycode, RACE, UTF-8, Encoding-n and UTF-5.
Likewise, we can test the interoperability of IDN solutions which
is used various encodings. And we are also able to test backward
compatibility with the existing DNS. Second, it should support A,
PTR, MX, TXT, HINFO, CNAME and SOA to test various DNS
services. APIs which are in Java supports only simplified A, PTR
version, so we developed the resolving routine to support various
query type. It is easily extended by adding int form to the RR type
number. Third, It implemented by Java for supports multiplatform. Fourth, it should support GUI and CUI environments
for convenience. Finally, modulates resolving, encoding and GUI
part for support more reusability, flexibility and extensibility.
Therefore it could be extended functional module more easily.
IDN Test Suite is basically divided into three files. Encoder.java
with encoding related method and Resolver.java file that executes
the resolver are embodied to be used in other programs without
any change. In addition, Idnslook.java file which is the main
program and the part of GUI, it reads the user's input and shows
the result after producing each object that are used in the system.
Also, it has the function of restoring the various set up results into
the environment set up file. Figure 3 represents IDN Test Suite
(Idnslook) and Figure 4 represents query type and encoding type
choice.
Name server input
Query input
Query type choice
Application
Name Service
(A, AAAA or A6)
Encoding type choice
Punycode
Decoder
Punycode
Encoder
ENUM
Service
(NAPTR)
Result output
Query send button
Status display line
ENUM
Resolver
Name
Resolver
IDN & ENUM Check
Figure 3. IDN Test Suite – Idnslook.
[IDN Cl ient]
[IDN & ENUM Server]
Figure 2. IPv6 IDN Specification Design
Konkuk University Zone
Singapore University Zone
Root
Top Level IDN
Figure 4. Query Type & Encoding Type Choice.
3.3 ENUM Client
We developed ENUM client prototype which support IDN. User
inputs ENUM then sends it IDN/ENUM server. The result (URIs)
from server is displayed on client, and then user could choice to
use. ENUM client calls appropriate application for selected URI.
Web
kr
sg
Second Level IDN
ac
co
대학
회사
건국대
삼성
…
…
ac
敎育
ac
co
公司
建國大
三星
…
…
대학
싱가포르
…
co
회사
ac
敎育
co
公司
무역
新可坡
貿易
…
…
…
Figure 7. Domain Hierarchy.
Mail
5. Interoperability test
Phone
Fax
[ENUM Client (prototype)]
Figure 5. ENUM Client.
4. International IPv6 IDN Test bed
We’ve constructed IPv6 IDN test bed for interoperability and
compatibility test with Singapore national Univ, Singapore. But
also, local test bed. Konkuk Univ. manages root server for Korean
domains and local test bed. Singapore Univ. manages root server
for Singaporean domains and there local test bed. IDN root
servers were operated by using mBIND. These are connected
through KOREN and SingaREN. KOREN and SingaREN are
native IPv6 network. So, we could perform IPv6 IDN test. In
addition, we’ve performed IDN test through IPv6 tunneled
network. Figure 6 represents International IPv6 IDN Test bed and
extension plan. Figure 7 represents virtual domain hierarchy of
test bed. So, to access Konkuk Univ.'s web page, we could use the
existing DNS method, ‘http://www.kokkuk.ac.kr’, or also we
could use Korean like ‘http://건국대.대학.kr’.
IDNS Testbed
Testbed extension plan
Network extension plan
Interior Testbed
APAN-JP
XP Seoul
XP Tokyo
IPv6 IDN Root Server
vBNS, Abilene
CA*Net2, etc
TransPAC
KOREN
Singapore
Univ.
Dacom
ATM
Local Testbed
Euro GW
XP Singapore
SingaREN
TEN-155
Figure 6. International IPv6 IDN Test bed.
In this paper, we have tested mBIND and other IDN solutions on
the test bed. The interoperability test is progressed mainly of
International test bed. And, we have tested many encoding from
one DNS. But this test is only for test to confirm the movement of
encoding. Main test items were basic RR type and name query test
applying the encoding which is provided by IDN Test Suite to test
the interoperability of IDN solutions. The result of
interoperability test was produce successful results if they uses
same encoding algorithm or uses supported encoding algorithm
by IDNS. But, if they use different encoding algorithms which
was not-supported on other server-side than result is failure. We
can draw a conclusion from these results that the interoperability
is supported among those servers which look like they are using
the same or supportable encoding systems. Next, the backward
compatibility test. The testing method in this test executes English
domain names on various IDNS. The result of backward
compatibility is success when they use ACE or UTF-8 encoding
algorithm. The result is failure when they use UTF encoding
algorithms except UTF-8.
6. Conclusion
This paper is embodied for IPv6 IDN protocol suite for support
IDN and ENUM. Invented mBIND supports IDNA protocol
mechanism. IDN Test Suite has the characteristics of Java that is
executed in multi-platforms. Also it has various RR type and
encoding type test functions to interoperability and backward
compatibility test. These functions have food points that it can
provide the convenient user interface in testing by producing the
GUI environment, which is distinguished from the existing test
tools. We have tried various tests such as the interoperability and
backward compatibility test among the IDN solutions on test bed
and analyzed the results to find out the problems and presented
the solutions. In addition, we’ve developed ENUM client which
supports IDN.
mBIND, IDN Test Suite and ENUM client are still having many
problems. We’ll investigate stable mBIND version. Integrate IDN
Test Suite with ENUM client and fully support IPv6. In addition,
add functions on IDN Test Suite to robustness, stability and
availability test.
7. REFERENCES
[1] P. Mockapetris, “DOMAIN NAMES - CONCEPTS AND
FACILITIES”, RFC 1034, November 1987.
[2] P. Mockapetris, “DOMAIN NAMES - IMPLEMENTATION
AND SPECIFICATION”, RFC1035, November1987.
[3] P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March
2003
[4] A. Costello, "Punycode: A Bootstring encoding of Unicode
for IDNA", RFC 3492, March 2003
[5] P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", RFC 3491,
March 2003
[6] M. Duerst, "Internationalized Domain Names in URIs",
Internet Draft, November 2002
[7] P. Hoffman, P. Faltstrom, "Internationalized Host Names
Using Resolvers and Applications (IDNRA)", Internet Draft,
August 2000
[8] M. Welter, B. Spolarich, A. Costello, "Differential Unicode
Domain Encoding (DUDE)", Internet Draft, Jun 2001
[9] P. Hoffman, "RACE: Row-based ASCII Compatible
Encoding for IDN", Internet Draft, November 2000
[10] F. Yergeau, “UTF-8, a transformation format of ISO 10646”,
RFC 2270, January 1998
[11] P. Faltstrom, “E.164 number and DNS”, RFC 2916,
September 2000
[12] S. Hollenbeck, "Extensible Provisioning Protocol E.164
Number Mapping", Internet Draft, February 2003
[13] S. Lind, "ENUM Usage Scenarios", Internet Draft, June
2002
[14] P. Faltstrom, M. Mealling, "The E.164 to URI DDDS
Application (ENUM)", Internet Draft, May 2003
[15] Netpia’s website, http://www.netpia.com
[16] iDNS’s website, http://www.i-dns.net
[17] JPNIC’s website, http://www.nic.ad.jp