Extensions to DNS for Supporting Internationalized Domain Names

Transcription

1 Extensions to DNS for Supporting Internationalized Domain Names Dongman Lee 1, Hyewon Shin 1 Soon J. Hyun 1, Younghee Lee 1, Myoungchurl Kim 1, and Hee Yong Youn 2 1 Information and Communications University Taejon, Korea {dlee, hwshin, shyun, yhlee, mckim}@icu.ac.kr 2 School of Electrical and Computer Engineering Sungkyunkwan University, Suwon , Korea youn@ece.skku.ac.kr Abstract. As the Internet become popular around the globe, there have been several approaches to support internationalized domain names, that is, names consisting of non-ascii characters. However, they require modification of existing applications or significant changes in the existing DNS protocol. In this paper, we propose an extension to the existing DNS protocol for supporting internationalized domain names while maintaining interoperability and compatibility with the DNS. For this, we exploit the reserved field of Opcode in the DNS query to support Internationalized Domain Names. The proposed scheme uses a UTF-8 encoding scheme as a wire format since it allows ASCII names to remain intact. We implement the proposed scheme using BIND on Solaris, Sun Unix OS. The performance results show that the proposed scheme does not incur any significant overhead while it maintains the interoperability and compatibility with the existing DNS. 1 Introduction As the Internet becomes popular around the globe, there have been several efforts to allow users to use their mother tongue instead of English in accessing the Internet. Internet protocols such as HTML, XML, IMAP, FTP, and many other text-based protocols were at least partially internationalized [3]. However, the domain name system (DNS) is yet to follow this paradigm shift. It only allows names in ASCII characters, so called alphanumeric characters, which are difficult to remember or use for the people who are not familiar with English. There have been several approaches to support internationalized domain names, that is, names consisting of non-ascii characters. They can be classified into two approaches: application extension and DNS protocol extension. The former supports internationalized domain names without modifying or changing the current DNS protocol. IDNA [4] proposes a scheme in which the application encodes non-english domain names (hereafter, we call them internationalized domain names, IDNs) into names compatible with the existing DNS, that is ASCII characters. This allows users I. Chong (Ed.): ICOIN 2002, LNCS 2344, pp , Springer-Verlag Berlin Heidelberg 2002

2 792 D. Lee et al. to use IDNs at their application s user interface and yet these names to be handled by the existing DNS servers. However, this approach requires the modification of existing applications using the DNS protocol. UDNS [15] also requires the application to encode an IDN into ASCII-compatible names like IDNA when the underlying DNS does not support non-ascii characters. Some approaches propose using a UTF-5 based encoding scheme [16] that converts non-ascii characters into ASCII-compatible ones. However, this scheme requires even ASCII character based names to be encoded as well. Stuart Kwan suggests using a UTF-8 encoding scheme in which ASCII-based names remain preserved [12]. However, it does not provide interoperability with the systems supporting only ASCII-based names [6][20]. J. Klensin suggests a new class for IDNs [9][10]. Unlike the approaches described earlier, this allows non-ascii names to be handled separately from ASCII names. However, with this scheme, the current DNS query format should be extended, which in turn the whole DNS components should be modified as well as other related protocol [18]. We propose an extension to the existing DNS for supporting IDNs. We call the extension EDIDN *. As discussed above, we should consider interoperability and compatibility with the current DNS. For this, we exploit the reserved field of Opcode in the DNS query to support IDNs. The proposed scheme uses UTF-8 encoding as a wire format because UTF-8 encoding does not impose any changes into ASCII-based names. However, to support interoperability with conventional DNS servers or resolvers, it only uses a new Opcode when non-ascii names are asked to resolve. If a query containing a non-ascii name is sent to a server with the current DNS, that is, supporting only ASCII names, the resolver in the proposed scheme resends the query to servers supporting EDIDN. To distinguish errors from the servers supporting EDIDN, we use the reserved filed of RCODE in a DNS response message. We implement the proposed scheme using BIND [8] on Solaris, Sun Unix OS. The performance results show that the proposed scheme does not incur any significant overhead to the existing DNS. The rest of this paper is organized as follows. We discuss the existing approaches for supporting internationalized domain names in Section 2. Section 3 describes the proposed scheme in detail. Section 4 explains the implementation and performance analysis. Conclusion follows in Section 5. 2 Related Work The current DNS infrastructure does not support internationalized domain names. Approaches for supporting internationalized domain names in DNS can be divided into application extension and protocol extension. In this section, we describe both approaches including issues in them. *Extensions to DNS for supporting Internationalized Domain Names.

3 Extensions to DNS for Supporting Internationalized Domain Names IDNA (Internationalized Domain Name Application) IDNA [4] enables internationalized domain names in DNS name labels. IDNA works by allowing applications to use certain ASCII name labels to represent non-ascii name labels. In IDNA, applications perform the processing of internationalized domain names from users, and display internationalized host names to users. The IDNA protocol does not affect the existing DNS protocol. However all applications must have libraries for performing conversion from IDNs to ACE (ASCII-compatible encoding) names and vice versa. 2.2 IDNE (Internationalized Domain Name Using EDNS) IDNE [2] describes an extended mechanism based on EDNS that enables to the use of IDN without causing harm to the current DNS. IDNE enables IDN host names with as many characters as current ASCII-only host names. It fully supports UTF-8 character encoding set and conforms to the IDN requirements. The major drawback of IDNE is that all protocols, applications and DNS servers will have to be upgraded to support this proposal. 2.3 Internationalizing the DNS, New Class J. Klensin proposed a new Class and a new DNS lookup schemes [9][10][11]. The proposal considered future extension through the use of defining new Classes. All current usage in the Internet environment uses the IN class [10]. A new extended mechanism via a new Class scheme may have several reasons that extended and conventional DNS name labels and other fields are defined as an internationalization approach, not only ASCII. Extend DNS with new RR types and new class requires changes to name server, resolver, applications and all other related components. Potential future DNS extension does not allow conventional DNS to handle the new class and other related specific extension part. It requires changes in the current DNS protocols and related Internet protocols. 3 Design In this section, we describe the design considerations and the details of EDIDN protocol and how the existing DNS protocol is integrated into it. We present the proposed protocol including the resolver and name server specification.

4 794 D. Lee et al. 3.1 Design Consideration Internationalization The encoding of domain names in the Internet is restricted to a subset of 7 bits ASCII [13]. A domain name must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, or hyphens. There are also some restrictions on the length. Labels must be 63 characters or less [13]. They are restricted to DNS itself and many other protocols on Internet. In accordance with the use of internationalized domain name, the EDIDN protocol will require some changes in comparison with the current DNS. All internationalized domain names must be represented in one standard format. We consider the existing host name rule that is compatible with the current DNS encoding, complexity and range of characteristics of internationalized script. So the extended DNS protocol should process the Universal Character Set as ISO [17]. We select UTF-8 encoding as CES (Coded Encoding Set). It is compatible with the current ASCII-based protocols and it does not process ambiguous characters. The internationalized domain names may use several local character sets, but they must be encoded into Unicode and UTF-8 before being sent over a wire Compatibility and Interoperability To support internationalized domain names, DNS should also allow any UTF-8 octet characters to be processed and passed over the network. Therefore, the extended DNS protocol for internationalization must provide backward compatibility and interoperability with the current DNS [3][19]. In other words, the new protocol must be used with the current protocol with no or minimum changes. For this, we exploit the reserved field of the Opcode and RCODE in a DNS query since it requires no extension to the DNS protocol itself. The extension should also allow Internet protocols to handle names without conversion Canonicalization DNS indexes and matches domain names to look up a domain name from zone data [5]. In the conventional DNS, canonicalization is subject to US-ASCII only. However, every internationalized character must be canonicalized in its own rules for a DNS standardized matching policy, e.g. case-insensitive matching rule Operational Issues EDIDN needs an operation for interoperability with the current DNS. Therefore, it is needed to specify the operational guidelines for EDIDN. There could be three different cases when the extended protocol and the existing DNS protocol are used together: the existing resolver and the extended server, the extended resolver and the existing server, and the extended resolver and the extended server. The first and third cases should work with no modification or changes since the extended server can support ASCII-based domain name as well as IDNs. The second case requires an extra consideration since the existing server does not handle non-ascii based names.

5 Extensions to DNS for Supporting Internationalized Domain Names Proposed Extension to DNS for Supporting Internationalized DNS Protocol Extension EDIDN supports internationalized domain names while maintaining interoperability with the existing DNS and other protocols. For this, we use the existing DNS header format without modification and exploit the unused values of Opcode and RCODE in a DNS query / response message. Table 1 shows the Opcode field of a DNS query header. The Opcode section is composed of a four bit field that specifies the type of a DNS query. The field is set by the originator of a query and copied into the request [14]. To indicate an EDIDN query (EQUERY), we use an unused value which is 3. That is, if the value is 3, a given query contains an international domain name. Table 1. Opcode Field of EDIDN Query Bit Value Specifies kind of query 0 A standard query question (QUERY) 1 An in v erse query (IQ U E R Y ) 2 A server status request (STATUS) 3 An extended Q u ery (EQ UERY) 4-15 Reserved for future use A conventional RCODE is composed of six bits. The values, 0 to 5, are assigned for a conventional DNS response query [14]. There can be two error cases when an EDIDN sends a query to a conventional DNS server, that is, a server that cannot handle an international domain name: the DNS server only processes the opcode value of 0, 1, or 2 and the DNS server does handle the opcode value greater than 2 as well. In the former case, the server will return the RCODE with 4, not implemented, while the server will return the RCODE with 3, name error in the latter case. To allow a query with international domain names to be processed, we do not treat these RCODE values as an error. Instead, the EDIDN resolver resends the query to the next authoritative server until the name is resolved. To distinguish the same RCODE return values from an EDIDN server, which should be treated as an error, we use the unused RCODE values, 6 and 7 for this purpose. Table 2 shows the values of the RCODE field in an EDIDN query and their interpretation.

6 796 D. Lee et al. Table 2. Field of Extended RCODE Type Current NS EDIDN NS Response Message Response Message Interpretation No error condition Format error Server failure error Name error No error condition The name server was unable to interpret the query. The name server was unable to process this query due to a problem with the name server. Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist Not Implemented Refused The name server does not support the requested kind of query. The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data Resolver Extension If a name server is an EDIDN name server, it can process and save an extended query and reply an answer to the original EDIDN resolver. If a name server is a conventional name server, it cannot process and save an EDIDN query, and then sends an error status to the original EDIDN resolver. The EDIDN resolver sends a recursive query to other name servers and the forwarder to get a right answer as described above. 3.3 Operational Model We identify the following important design goals for EDIDN that enables internationalized domain name and conventional domain name at the same time. We should consider three cases of the usage of between EDIDN and conventional DNS: (i) it is interoperate with extended resolvers and conventional name servers, allowing users to seamlessly handle the internationalized domain name; (ii) it is interoperate with extended resolver and extended name servers. The extended resolver must continue to allow any queries and responses that result of EDIDN protocol and conventional DNS protocol. (iii) it is interoperate with conventional resolver and extended name servers. Fig 1, Fig.2 show EDIDN and DNS processing. [14].

7 Extensions to DNS for Supporting Internationalized Domain Names 797 User Program user query user response Extended Resolver Make query Send query extended query retrun the query extended response extended query Name Server EDIDN Name Server Fig.1. Extended Resolver with Conventional name server and extended Nam server User Program user query user response Resolver Make query ASCII query ASCII response EDIDN Name Server Send query Fig.2. Conventional resolver with Extended Name Server 4 Implementation We implement EDIDN on Solaris, written in C. We use BIND [8] which is an implementation of the Domain Name System protocols and provides an openly redistributable reference of implementation of the major components of the Domain Name System. In this section, we present the details of two main components of EDIDNS: resolver and name server. Fig 3 shows how these two components interact with each other to resolve domain names.

8 798 D. Lee et al. Applicaion (call by gethostbyname) *hname Search complete domain name res_search() Resolver Process and find a right domain name res_query() Make a suitable query packet res_mkquery() Send the query packet to name server res_send() Respond the state of name server ns_name() Name Server Fig. 3. Resolver and Name Server Library Routines 4.1 Resolver EDIDN uses a resolver library to communicate with a name server. The resolve issues to its name server a query that is used to resolve an internationalized domain name. It converts the local character set to UCS and then to UTF-8 using ucs4_to_utf8(). For reverse mapping, utf8_to_ucs4() is provided. res_search() is extended to search an internationalized domain name and made up full domain name and to call the res_query(). res_query() builds a query, sends and awaits a response from a server. This routine is extended to handle EDIDN queries. If a query contains an international domain name, the query s opcode is set to EQUERY by res_enmkquery(), which is added for EDIDN. Then, res_query() waits for a response from a server. If the RCODE value of the response is NXDOMAIN or NOTIMP, res_query is extended to try again for recursive query.

9 Extensions to DNS for Supporting Internationalized Domain Names Name Server We modify the name server library routine because we distinguish between conventional responses and EDIDN ones. We modify the opcode interpretation and RCODE assigning parts for handling EDIDN queries. ns_main() is extended to handle domain names encoded in UTF-8. We also extend the zone file editor which allows international domain names encoded in UTF-8 to be added into a zone file. 4.3 Experimental Results and Analysis We performed a set of experiments to measure the performance of the proposed extension, EDIDN System. The important metric for the experiments is execution time for resolving a query, compared with the current DNS. The experiments were run on PC as a client and on Solaris as a name server connected by 10 Mbps Ethernet. We measured the execution time in the three cases as follows: between current DNS resolver and DNS name server, between EDIDN resolver and EDIDN name server and between EDIDN resolver and DNS name server. We run the experiments 50 times for each case and the results were averaged out of them. Table 3 shows the execution time in each case. The execution time consists of query preparation and display at resolver, query transmission, and query resolution at server. Table 3. Execution Time of Each Case DNS Resolver and DNS Server EDIDN resolver and EDIDN server Resolver (ms) Transmission (ms) Server (ms) Total Execution Time (ms) As Table 3 shows, the total extension time for query resolution by the EDIDN resolver and server is almost the same (less than 4 % overhead) as that by the current DNS resolver and server. It is because we use the reserved bits values in the current DNS message format. The EDIDN resolver takes a little more time than the existing resolver since conversion from a local code to UCS to UTF-8 is required in the EDIDN resolver. Therefore, EDIDN does not incur any significant overhead into the current DNS system.

10 800 D. Lee et al. 5 Conclusion In this paper, we propose an extension to DNS for supporting an international domain name while supporting interoperability and compatibility with the existing DNS. For internationalized domain names, we use Unicode as character coding set and UTF-8 as an encoding scheme. For interoperability and compatibility, we consider three cases: the existing resolver and the extended server, the extended resolver and the existing server, and the extended resolver and the extended server. For this, we exploit the unused values of Opcode and RCODE in a query and a response, respectively, which requires no modification to the existing DNS. To indicate an EDIDN query (EQUERY), we use a separate Opcode value, 3. To distinguish the same RCODE return values from an EDIDN server, which should be treated as an error, we use the unused RCODE values, 6 and 7 when an EDIDN sends a query to a conventional DNS server, that is, a server that cannot handle an international domain name. In this case, the EDIDN resolver sends a query iteratively until a given internationalized domain name gets resolved. We implement EDIDN on Solaris, written in C using BIND The performance results show that the proposed scheme does not incur any significant overhead while it maintains interoperability and compatibility with the existing DNS. References 1. Albits, P., Liu, C.: DNS and Bind.3rd ed., O REILLY (1998) 2. Blanchet, M., Hoffman, P.: internationalized domain names using EDNS using EDNS (IDNE), Internet drafts, draft-ietf-idn-idne-02.txt, March Braden, R.: Requirements for Internet Hosts -- Application and Support. Internet Engineering Task Force, RFC 1123 (1989) 4. Faltstrom, P., Hoffman, P.: Internationalizing Host Names in Applications. Internet drafts, draft-ietf-idn-idna-05.txt (2001) 5. Gustafsson, A.: DNS Zone Transfer Protocol Clarifications. Internet draft, draft-ietfdnsext-axfr-clarify-03.txt (July 2001) 6. Hoffman, P.: Comparison of Internationalized Domain Name Proposals. Internet drafts, draft-ietf-idn-compare-01.txt (2000) 7. Hoffman, P.: Internationalized Host Names Using Resolvers and Applications (IDNRA). Internet drafts, draft-ietf-idn-idnra-00.txt (2000) 8. ISC Web Site: BIND Version Klensin, J.C.: A Search-based access model for the DNS. Internet draft, draft-klensin-dnssearch-02.txt (2001) 10. Klensin, J.C.: Internationalizing the DNS -- A New Class. Internet draft, draft-klensini18n-newclass-01.txt, (2001) 11. Klensin, J.C.: Role of the Domain Name System. Internet draft, draft-klensin-dns-role- 01.txt (2001) 12. Kwan, S., Gilroy, J.: Using the UTF-8 Character Set in the Domain Name System. Internet drafts, draft-skwan-utf8-dns-04.txt (2000) 13. Mockapetris, P.: Domain Names - Concepts and Facilities. Internet Engineering Task Force, RFC 1034 (1987) 14. Mockapetris, P.: Domain Names - Implementation and Specification. Internet Engineering Task Force, RFC 1035 (1987)

11 Extensions to DNS for Supporting Internationalized Domain Names Oscarsson, D.: Using the Universal Character Set in the Domain Name System. Internet drafts, draft-ietf-idn-udns-03.txt (2001) 16. Seng, J., Duerst, M., Tan,T.W.: UTF-5, a transformation format of Unicode and ISO Internet drafts, draft-jseng-utf5-01.txt (2001) 17. The Unicode Code Consortium: The Unicode Standard, Weider, C., Preston, C., Simonsen, S.: The Report of the IAB Character Set Workshop. Internet Engineering Task Force, RFC 2130 (1997) 19. Wenzel, Z. Seng, J.: Requirements of Internationalized Domain Names. Internet drafts, draft-ietf-idn-requirements-08 (2001) 20. Yergeau, F.: UTF-8, a transformation format of ISO Internet Engineering Task Force, RFC 2279 (1998)