Skip to main content

Message from Stuart Lynn to the Internet Architecture Board

To the Internet Architecture Board:

On Friday, [3 January 2003,] VeriSign Global Registry Services announced a set of steps relating to the implementation of internationalized domain name capabilities, including changes in the behavior of the authoritative name servers for the .com and .net zones. The announcement is at <[]>. The announcement appears to anticipate the RFC Editor's publication of the remaining component documents that define IDNA (Internationalized Domain Names in Applications), the standards-track output of the IETF's IDN Working Group.

In response to the VGRS announcement, some commentators have raised concerns that VGRS's plan for handling DNS requests containing non-ASCII octets would be contrary to DNS standards. In particular, see the communication from Paul Hoffman of the Internet Mail Consortium, included with attachment below.

In keeping with ICANN's commitment to seek authoritative technical guidance from the IETF about the relationship of actual or proposed DNS operations to the IETF's standards-track activities, we are requesting the advice of the IAB (together with the IESG or other IETF bodies, if appropriate) about the announced VGRS changes to the behavior of the .com and .net name servers. Although ICANN's focus must be on violations of standards VGRS has agreed to follow, we would also welcome any IAB comment on effects the VGRS changes may have on architecture for the protocols and procedures used by the Internet.

I am copying Brad Verd and Chuck Gomes of VGRS on this message, and also actively invite any input or response VGRS may wish to give. We will also be referring the issue raised in Paul Hoffman's e-mail to ICANN's IDN Committee and Security and Stability Committee.


Stuart Lynn

cc: Chuck Gomes, Vice President for Policy and Compliance, VGRS
Brad Verd, Resolution Systems Operations Manager, VGRS
Masanobu Katoh, Chair, ICANN IDN Committee
Steve Crocker, Chair, ICANN Security & Stability Committee

Attachment - Message from Paul Hoffman

From: Paul Hoffman / IMC
Sent: Sunday, January 05, 2003 7:18 PM
Cc: Louis Touton; Patrik Faltstrom
Subject: Serious technical problems with VGRS's announcement

Greetings. This message follows up on the announcement from VeriSign GRS (the com/net registry) that they will start responding to DNS requests that contain non-ASCII octets and giving positive answers when they should be giving negative answers. VGRS's announcement is at <>.

There are many technical problems with this change. It essentially undermines IDNA, which is now on standards track, by adding a level of guessing to the DNS that IDNA is explicitly designed to avoid. Further, it makes it appear that IDNs are only useful in domain names for web sites (and only for sites in .com and .net), and only at the second level. VGRS has said that their plug-in will not work with most of the ccTLDs, for example.

For example, if you enter <a-ring>.com in Internet Explorer for Windows, where "<a-ring>" is the single hex octet 0xE5, you see the screen shown in the attached file called "[lynn-message-to-iab-06jan03-]e5.tif". (Sorry about the TIFF image, but it's the only reliable format for PC screen dumps.) As you can see, VGRS makes wild guesses about what the user wanted, some of which are very clearly impossible. Worse yet, they do not include all of the legal guesses that they could have made. And, just to make it completely confusing to the user, not all of the choices work.

The DNS is not supposed to be a best-guess service, yet VGRS has turned .com and .net into this just before IDNA is to be an RFC. VGRS should not be allowed, through its monopoly on the .com and .net gTLDs, to destroy the coherence of the DNS for its own short-term profit. ICANN should demand that VGRS immediately stop giving incorrect answers to any query in .com and .net, and should instead follow the IETF standards. If VGRS refuses, ICANN should re-delegate the .com and .net zones to registries that are more willing to follow the DNS standards.

Please let me know if you have any further questions.

--Paul Hoffman, Director
--Internet Mail Consortium

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."