Internationalized Domain Name Resolution System and Its Localization

• Main Authors: Jeng-Wei Lin, 林正偉
• Other Authors: Feipei Lai
• Format: Others
• Language: en_US
• Published: 2005
• Online Access: http://ndltd.ncl.edu.tw/handle/89817967506255460856

博士 === 國立臺灣大學 === 資訊工程學研究所 === 93 === In recent years, many attempts have been made to lower the linguistic barriers for non-native English speakers wishing to access the Internet. However, traditional Internet domain names are restricted to being composed of ASCII letters, digits, and hyphens – abbreviated as LDH. In 1999, Internationalized Domain Names, (IDN), were introduced to allow an individual or organization to register a domain name in any major language – from Chinese to Russian to Arabic. In March 2003, IETF published three RFC (Requests for Comments) documents, referred to as IDNA, nameprep, and punycode, as the IETF Internet standard for IDN. These documents specify a name-preparation process for converting a Unicode IDN to an ASCII Compatible Encoding (ACE) string. Once an IDN is registered in an IDN registry, the latter stores the ACE string in the domain name server. When an IDNA-aware application looks for a host using its IDN, the application converts the IDN to an ACE string so that the current DNS can resolve the ACE string into the host''s IP address. However, some domain name strings embedded in multilingual content do not have any charset encoding tag, so they cannot be appropriately converted to the corresponding Unicode IDNs and, thus, the ACE strings. Although, IDNA can use the current DNS without modifying domain name servers and resolvers, it does require that an IDNA-compliant module be integrated into every Internet application in order to process IDNs properly. Through our participation in IDN-related activities, we observed that many Internet applications allow the use of non-ASCII characters in domain name slots. This motivated us to design an IDN server proxy architecture that provides IDN resolution in multiple encodings. In this architecture, ACE IDNs are stored in the domain name servers; hence, traditional domain name servers can be used without modification. An IDN server proxy, called Octopus, is employed on the domain name server side to facilitate servers by providing non-ACE IDN resolution. On receipt of a DNS query packet, Octopus converts the non-ACE IDN to ACE. The ACE string is then forwarded to backend domain name servers (where the traditional domain names and ACE IDNs are stored) for further processing. Based on the design and implementation of Octopus, we initiated a CDN trial service to further investigate the interoperability of Internet applications when CDNs are used. We studied several types of errors that cause unsuccessful WWW access via IDNs, such as improper web server configuration, generic multilingual text processing errors, etc. Solutions were then developed, including the use of an IDN-aware web redirection server. While Internet services can be significantly improved by introducing IDNs, the use of characters that have similar appearances and/or meanings has the potential to cause confusion. The introduction of IDNs has raised serious consumer concerns about the likelihood of widespread user confusion, new opportunities for cybersquatting, etc. IDNA does not address linguistic issues, such as Han character variants. Two Han characters are said to be variants of each other if they have the same meaning and are pronounced the same. A variant IDN derived from an IDN by replacing some characters with their variants should match the original IDN. In April 2004, IETF published RFC 3743, referred to the JET Guidelines, for the registration and administration of Chinese, Japanese, and Korean IDNs. The JET Guidelines suggest that zone administrators model the concept of equivalent IDLs (Internationalized Domain Labels) as an atomic IDL package based on zone-specific Language Variant Table (LVT) mechanisms. However, the Guidelines do not address various technical implementation issues. For example, an issue of scalability arises when the number of variant IDLs is large. We propose a resolution protocol that resolves the variant IDLs in an IDL package into its registered IDL with the help a small number of VarIdx RRs (resource records). In this process, each VarIdx RR uses a variant expression to enumerate some of the variant IDLs. An indexing function is designed to give the same variant index to the variant IDLs enumerated by a variant expression. This allows Internet applications to use one of the variant IDLs to look up the VarIdx RRs and find the registered IDL. We have studied different indexing functions. Experiment results show that, although individual zones may have their own rules about permitted characters and the variant relationships of these characters, an indexing function does exist for global use. We set up a redirection service that enables users to access the WWW via variant IDNs. The domain name servers are configured to return the IP address of the redirection server to the client when the queried domain name is not registered. The user request is then sent to the redirection server, which computes the variant index of the unregistered label and looks up the VarIdx RRs. If the right VarIdx RR is located, the server redirects the user request to the new URL by replacing the variant IDL with the registered IDL. Experiment results show that our resolution protocol successfully enables Internet access via variant IDNs. In this research, we first extend the functionality of the current DNS by providing IDN resolution in multiple encodings, and then extend it further by providing variant IDN resolution. Our study also suggests useful practices for software vendors to develop INDA-compliant Internet applications. While extending the functionality of DNS, we retain backward compatibility and reuse existing software as much as possible. Our study provides useful reference for software engineers to extend the functionality of a widely deployed system.