IDN server proxy architecture for Internationalized Domain Name resolution and experiences with providing Web services

The composition of traditional domain names are restricted to ASCII letters, digits, and hyphens (abbreviated as LDH). This makes it difficult for many to use their native language to name and access their Internet hosts. The IETF IDN (Internationalized Domain Name) Working Group proposes a mechanism, IDNA (Internationalizing Domain Names in Applications), for internationalized access to multilingual domain names. The proposal uses a preparation process that converts a Unicode IDN into an ACE (ASCII Compatible Encoding) string that uses only LDH. Thus, applications can look up the ACE string by using the existing DNS infrastructure. However, some of the domain name strings embedded in multilingual content do not have any charset tag so they cannot appropriately be converted into ACE strings. We noticed that many Internet applications allow users to use non-ASCII domain names. We were motivated to design an architecture for IDN resolution as well as to minimize the cost of modifying legacy Internet applications. We specifically focus on designing an IDN server proxy, which is located on the domain name server side, to handle domain names in multiple encodings. In this article, we study several architecture design issues including detection of charset encoding, routing of non-ACE IDN lookup requests, and so on.With respect to these design issues, we present an IDN server proxy architecture which stores ACE IDNs in domain name servers. Note that traditional domain name servers can be used without modification. An IDN server proxy, called Octopus, is employed on the domain name server side. Octopus converts a non-ACE IDN string into ACE upon receiving an IDN lookup request from remote users or autonomous systems. The ACE string is then forwarded to backend domain name servers (where the traditional domain names and ACE IDNs are stored) for further processing. This allows Internet users to access IDNs without having to upgrade their software.Based on the design and implementation of Octopus, we deployed a CDN (Chinese domain name) trial in July 2002. In this article, we present the results of testing Octopus IDN lookup functions as well as our experiences in providing CDN Web services. Several types of errors can occur if applications are unable to handle IDNs adequately. For example, a Web browser may erroneously parse an IDN within a URL. Many legacy Web servers are unable to process the IDN of a virtual host. Web application servers may have trouble completing some actions such as redirecting Web pages to alternative Web pages. Our studies help service providers understand potential problems when non-ASCII domain names are used and the best common practice at this stage. As well, the experiences give some guidance for software developers to develop IDNA-compliant Internet applications.