-----BEGIN PGP SIGNED MESSAGE----- This message explains an upcoming change in certain behavior of the com and net authoritative name servers related to internationalized domain names (IDNs). VeriSign Global Registry Services (VGRS) has been a longtime advocate of IDNs. Our IDN Test Bed has been active for over two years and we have followed and supported IETF developments in the IDN area. The protocol for IDNs developed by the IETF's IDN Working Group has been approved by the IESG and we anticipate that RFCs will be published soon. That protocol, Internationalizing Domain Names in Applications (IDNA), calls for changes to individual applications to support IDNs. VGRS has developed a plug-in, called i-Nav, for Microsoft's Internet Explorer browser to support IDNs in a manner consistent with IDNA. i-Nav is free and more information about it is available at <<http://www.idnnow.com>>. Before IDNA, some application developers had developed proprietary mechanisms designed to support IDNs. The Internet Explorer browser, for example, sends a DNS query in UTF-8 or another, local encoding when a user types a domain name with characters other than letters, digits and the hypen in the address bar. These efforts, however, were not entirely successful. For example, if such a domain name ends in com or net these queries reach the com/net name servers and fail. Our research indicates that the average user expects IDNs to work but does not understand the need for additional software to support this functionality. Such users attempt to enter IDNs in their browsers, but when the queries fail, they become frustrated and do not know what action to take to enable IDNs. They are unaware that downloading a browser plug-in such as i-Nav would enable IDN resolution. To improve this user experience and to encourage the adoption of an application that supports IDNA, VGRS is announcing a measure intended to stimulate widespread distribution of the i-Nav plug-in. Starting on January 3, 2003, some queries to the com/net name servers that previously failed with a DNS Name Error (NXDOMAIN) response will instead return an address (A) record. Any queries for A records with at least one octet greater than decimal 127 in the second-level label will trigger this A record response. For example, a query for the A record for "foo?.com", where "?" represents an octet with a value greater than 127, would return an A record rather than NXDOMAIN response. The goal is to match unrecognized domain names generated by browsers attempting to resolve IDNs. Since browsers construct DNS queries for such IDNs using UTF-8 or a local encoding, and since these encodings use octets with all possible values (i.e., from 0 through 255), the presence of octets with values greater than 127 as described above can indicate a web browser's failed IDN resolution attempt. The A record that will be returned by VGRS points to a farm of web servers that will attempt to resolve the query. The browser that sent the original DNS query will connect to one of these web servers and its HTTP request will contain a Host header with the representation of the IDN originally entered by the user in the address bar. The web servers will attempt to interpret the contents of the Host header. If the Host header corresponds to an IDN registered in VeriSign's IDN Test Bed, the web server will return a page that gives the user an opportunity to download the free i-Nav plug-in. The page will also allow the user to navigate to the corresponding IDN web site via an HTTP redirect. If the contents of the Host header cannot be matched to an IDN registered in the Testbed, the web server will return an HTTP 404 response. If a user downloads and installs the i-Nav plug-in, his or her browser will convert any IDNs entered to ASCII compatible encoding (ACE) format, according to the method described in IDNA. As a result, subsequent DNS queries will use ASCII characters only. The user experience for web browsing will change only slightly from the current experience if the contents of the Host header cannot be interpreted. If the web farm cannot match the Host header to an IDN, the user will see an error page resulting from the HTTP 404 error returned, rather than an error page resulting from a DNS NXDOMAIN response. The web servers refuse connections on all other UDP and TCP ports, so other network services are minimally affected. The overriding goal is to improve Internet navigation by encouraging widespread adoption of software supporting the emerging IETF standards for IDNs. These measures allow distribution of such software. - -------- Brad Verd Resolution Systems Operations Manager VeriSign Global Registry Services <<http://www.verisign-grs.com>> Email: bverd@verisign.com - -------- -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r JlaEmKgqKwjyVHVxxEmNYHQ0uU5V8khskWorhsobjDb+l5bPumkUaGsVnRvTMFGR CZTrHdn1bo1Q0IvfD1IBCq5qUugRimLc47TZdibYccCty8TmdtL/8jz4r6W90JPL KxXdjMpk6SOQj1SqErV/S6ypd5TFpXi1fEv6QEIrsqVoMCdELjFRZbmDTAMObvcR MpS75jUWbNmO7KENJCyacWzLTkh951+dszszwYig9jGIIXEpmrYGFA== =g2df -----END PGP SIGNATURE-----