Skip to main content

Letter from Rusty Lewis to Stuart Lynn (With Attachment Responding to IAB Statement)

Global Registry


February 7, 2003

Mr. Stuart Lynn
Internet Corporation for Assigned Names and Numbers (ICANN)
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601

RE: VeriSign's IAB Response and IDN Program Update to ICANN

Dear Stuart,

At ICANN's request, we have included our response, as attachment A, to the IAB's statements made to ICANN on January 25, 2003, concerning VGRS's IDN program.

VGRS continues to fully support the IDN standard. We welcome the IAB's advice and we believe that modifications that we have underway will address their technical concerns. Attachment A documents VGRS's responses and modifications. We also believe that the recent news about the anticipated publication of the IDN RFCs is a very positive development. VGRS will move to migrate its IDN systems to Punycode once the IDN standard has been published. Collaboration with the broader Internet community will deliver a better IDN service. To build our IDN program, we have and will continue to work with the IDN Implementation Committee, JPRS, KRNIC, CNNIC, TWNIC, other registry operators, and the standards bodies such as the IETF.

In June 2002, recognizing that application providers needed time to deploy IDN applications and Internet users demanded a solution, VGRS launched the i-Nav plug-in for the Internet Explorer browser. The i-Nav plug-in today implements the earlier RACE encoding of IDNA for Microsoft's Internet Explorer browser and Outlook email client applications. The Punycode version of the i-Nav plug-in will be delivered when the IDN RFCs have been published. While the Internet community positively received the i-Nav solution, VGRS received consistent feedback that the i-Nav plug-in solution did not go far enough to provide a ubiquitous solution to every Internet user around the world. Internet users, registrars, and registrants told us that IDNs should not only be supported through an IDNA-based plug-in solution, but also that the IDN's should be resolvable from any Internet browser address bar where the end user could also have the opportunity to download the plug-in. VGRS takes the obligation very seriously to provide a working IDN service to our registrars, their IDN registrants, and the 665 million Internet users around the world.

To this end, on January 3, 2002 VGRS launched two new improvements to its IDN program, Web-based Navigation and an update to the June release of the i-Nav plug-in. For more information see our January 14, 2003 press release at Web-based Navigation allows an Internet user from a browser address bar to use a valid IDN with or without a plug-in solution. If the IDN exists, then the user is presented with the option to download the i-Nav plug-in or to resolve to the website associated with the IDN. Attachment A provides a detailed technical overview of how Web-based Navigation works and how planned modifications to Web-based Navigation will address the IAB's concerns. VGRS views both the Web-based Navigation and the i-Nav plug-in as interim IDN steps while application providers such as Microsoft provide ubiquitous support for IDNA in their software. The Web-based Navigation and the i-Nav plug-in solutions have been in production since January 3, 2003. VGRS' IDN program today has over 900,000 registered IDNs. Operational experience has not revealed any instability to the Internet. Internet users, registrants and registrars are actively using IDNs and usage continues to grow. The feedback from these constituencies has been extremely positive. More importantly, millions of Internet users around the world can now navigate the Internet with an IDN.

VGRS welcomes the publication of the IDN-related RFCs – IDNA, Nameprep and Punycode. When the standard is published, VGRS will migrate from RACE to Punycode, as much of the work for this migration is already complete. Recognizing that the migration to Punycode will place an extra workload on registrars, VGRS delayed the migration to Punycode until the Punycode prefix is announced so that registrars would only have to do one migration. We believe that the Punycode implementation will deliver a better IDN service to our customers.

Separately, and unrelated to the IAB or its concerns, you may recall that the character variant topic surfaced at the ICANN meeting in Shanghai with a report produced by TWNIC. Since the ICANN meeting in Shanghai, the VGRS team has been actively working with members of the newly formed IDN Implementation Committee and the Asian registry operators to develop a practical solution to address character variants. VGRS looks forward to participating on the IDN Implementation Committee and developing a common set of guidelines that registry operators may follow. VGRS agrees with the IETF position that the IDNA, Nameprep, and Punycode RFCs should not address character variants. The core issue is that languages continue to change over time and no absolute variant solution can ever be created. Using the CDNC table, VGRS has identified a minimal number of simplified and traditional Chinese IDNs with character variants. We know that the number of new registrations using the simplified and traditional Chinese scripts containing character variants will be minimal. We believe that we have a good technical solution that can be delivered in the second quarter of 2003 to address character variants associated with the simplified and traditional Chinese scripts. We are building the solution so that other language character variants can also be addressed.

VGRS looks forward to further interactions with you on the IDN program. We are addressing the needs of the Internet user while following the IDN standards laid out by the IETF. In 2003, we believe that IDNs will represent the most significant and much needed improvement to the navigation experience for Internet users of all languages.



Rusty Lewis
Executive Vice President and General Manager
VeriSign Global Registry Services

Attachment A – VGRS's Response to the IAB's Advice on VGRS's IDN Announcement to ICANN (dated 1/25/02)

This document responds to the recent message on January 25, 2003 from the Internet Architecture Board ("IAB"), to ICANN concerning recent modifications that VeriSign Global Registry Services ("VGRS") made to its Internationalized Domain Name ("IDN") program.

On January 3, 2003, VGRS launched two improvements to its IDN program, Web-based Navigation and the i-Nav browser plug-in. These solutions allow all users to navigate the Internet in their native language. VGRS appreciates the IAB's constructive feedback on how the Web-based Navigation solution can be improved. We fully support and remain committed to the anticipated standard for IDNs, and through our improvements to the IDN program encourage its deployment. The Web-based Navigation and i-Nav plug-in are initial solutions intended to improve the user experience while software vendors add support for the IDN standard to Web browsers and other applications. The i-Nav plug-in is consistent with the direction of the IDN standard. Web-based Navigation provides a useful service for users without a plug-in to navigate to a Web site and, if the user chooses, download the plug-in. The next version of the Web-based Navigation solution will have modifications that we believe address the IAB's technical concerns. Our planned modifications and specific responses to the IAB are respectfully noted in the remainder of this document.

The current Web-based Navigation solution replaces some DNS Name Error/NXDOMAIN responses with an Address (A) record of HTTP servers that help users navigate to their intended destination. Specifically, the domain name in each query (QNAME) received by the .com and .net name servers is examined for non-ASCII characters. If the query is for A records and if the second-level label of the QNAME contains at least one octet with a value greater than decimal 127, the query is potentially for an IDN. In this case, the .com and .net name servers return an A record pointing to HTTP servers run by VGRS that provide free navigation assistance and offer VGRS's i-Nav browser plug-in.

In its response, the IAB identified several issues with VGRS's current solution. Our planned modifications will address the concerns. In the modified solution, rather than synthesizing A records, the .com and .net authoritative servers will synthesize NS records in response to queries for non-existent domains. The RDATA of these NS records will point to a set of name servers run by VGRS. These ancillary name servers will be authoritative for any conceivable undelegated second-level .com or .net subzone. Under certain circumstances described below, type A record queries to the ancillary name servers will result in a response with the A record of the HTTP servers supporting Web-based Navigation. VGRS has calculated several possible representations (e.g., UTF-8 and various regional encodings) for all registered IDNs. The ancillary name servers will compare an A record query's QNAME against this list of possible representations. Only if the QNAME matches a known representation of a registered IDN will an A record be returned. Other queries to these ancillary name servers will result in a Name Error/NXDOMAIN response or "no data" response, as appropriate.

The remainder of this letter answers each of the specific technical issues raised by the IAB to ICANN.

1. IAB: "The system deployed for .com and .net does not follow the specification for targets not in a zone. Instead, it examines the target and decides whether to give the specified negative response or a synthesized record based on whether the target contains a code point above 127. This is a violation of the DNS protocol as described in RFC 2308, Section 2.1."

VGRS: The deployed system returns Name Error/NXDOMAIN responses instead of "no data" responses under some circumstances. The modifications to the DNS portion of the system described above address this issue. We also point out that nothing in RFC 2308 prohibits the synthesis of records. The set of synthesized records is finite, but these records are synthesized rather than represented statically for the sake of efficiency. It is important to note that responses from the .com and .net name servers are and will continue to be deterministic and consistent across all authoritative servers.

2. IAB: "This implies that the zone as currently served by VeriSign cannot be transferred using either AXFR or file transfers in master file format."

VGRS: The mechanism by which the .com and .net zones are replicated to the appropriate authoritative servers is strictly a VGRS operational matter and does not affect the ability of these servers to properly serve the .com and .net zone information to the Internet. We also note that the use of AXFR to transfer a zone is optional according to RFC 1034, section 4.3.5. As noted in the previous response, the behavior of all .com and .net authoritative servers and the .com and .net zone information served by these servers has been and continues to be consistent.

3. IAB: "…queries against these new synthesized entries should follow the same specifications as those for any other entry in same zone. The system deployed for .com and .net does not."

VGRS: This concern is addressed by the modifications to the DNS portion of the system described above. In response to queries for non-existent domains, the .com and .net name servers will issue referrals to the ancillary name servers. These name servers, in turn, will respond with an A record or the appropriate negative response.

4. IAB: "The IAB notes that the system deployed for .com and .net cannot be administered under any current proposal for DNSSEC without maintaining an online signing key."

VGRS: This concern is addressed by the modifications to the DNS portion of the system described above and the use of DNSSEC enhancements currently being discussed within the IETF.

5. IAB: "Since these synthesized entries have no corresponding entries in the information service protocol, the normal diagnostic methods of following data from one protocol to another will fail."

VGRS: There is no requirement, nor do we believe that there is an expectation in the user community, that every piece of data in a TLD zone also be available via other information service protocols. Such an expectation would not be reasonable in light of other synthesis mechanisms such as a wildcard. For example, other TLD registries operate zones containing wildcards, apparently without significant user confusion regarding the synthesized vs. static entries.

6. IAB: Regarding handling of application protocols other than HTTP: "While VeriSign has handled this issue for SMTP, the more general case is still a problem."

VGRS: The modifications to the DNS portion of the system described above address the concerns raised by the IAB. The current behavior returns the HTTP server A record for a relatively large set of queries. The new behavior will only return an A record when the specific QNAME can be correlated to a registered IDN. This discrimination is currently only performed on the HTTP servers supporting the solution, but will extend to DNS as well under the modifications described above. Thus the set of Names producing an A record response will be considerably smaller, resulting in fewer non-HTTP-speaking applications attempting to send traffic to these HTTP servers.

In addition, while we appreciate the IAB's concern regarding the handling of other protocols, this position contrasts with our operational experience. We are not aware of any instances where this solution has caused any problems for the user community. We will continue to monitor for operational problems and work with the user community to address any issues discovered. Examination of network traffic indicates that the HTTP servers supporting this solution receive relatively little non-HTTP traffic. Of this traffic, the most-received protocol after HTTP is SMTP, which is effectively managed by the current solution. We also note that applications must be sufficiently robust to accommodate the error condition of attempted communication with hosts not supporting the application's particular protocol: this situation occurs frequently throughout the Internet today.

7. IAB: "The first response is a misuse of the [HTTP] 404 response code as described in RFC 2616, section 10.4.5; an application level error like [HTTP] 404 is not a replacement for the DNS-level NXDOMAIN."

VGRS: This concern is addressed by the modifications to the DNS portion of the system described above. Because a check for registered IDNs will be performed against the QNAME by the ancillary name servers, those name servers will only return an A record for queries for which a meaningful Web page can be produced. In other words, users will no longer see HTTP 404 errors: a user will receive either a DNS negative response (Name Error/NXDOMAIN or "no data", as appropriate) or the A record of an HTTP server providing a meaningful Web page.

8. IAB: "In the case where a web page is returned, the IAB is particularly concerned that the page contains guesses about what domain might have been the target. Part of this concern arises because the domains, which are presented, are not consistent from platform to platform and the inputs, which result in a particular response, do not seem to follow the expected standards. The greater part of the concern, however, comes from a fundamental bias against presenting multiple choices to a DNS query, even mediated by an HTTP-based application."

VGRS: VGRS, like the IAB, finds ambiguity at the DNS level untenable, which was why the solution was designed to resolve this ambiguity in the context of a Web application. Fundamentally, the IAB's objection deals with the overall behavior of the solution, and not the specific DNS implementation. There is no ambiguity from a DNS perspective. A given string produces a deterministic response, consistent among all .com and .net name servers.

VGRS chose a very conservative approach. In cases where the user is provided with a web-based response from our servers, it is clear that the original connection the user sought has not been completed as desired, and an alternate navigation service has been reached. The solution never attempts to guess a user's intent. If there is any potential for ambiguity, the solution presents the user with a choice. We believe Web-based Navigation provides a useful and needed service to the Internet community. We do not understand the technical justification for the bias against these search-like characteristics, which we believe are a reasonable and useful innovation."

VGRS remains committed to the standards process. We welcome the IAB's constructive feedback on our current implementation. In the interim, Web-based Navigation and the i-Nav plug-in have now been in production since January 3, 2003. Internet users, registrants and registrars are actively using IDNs and usage continues to grow. The feedback from these constituencies has been very positive. More importantly, millions of non-English-speaking Internet users around the world can now navigate the Internet with an IDN. We are all focused on the same goal, which is to deliver the best experience to the Internet user.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."