-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: [EMAIL PROTECTED]
-
-BEGIN PGP SIGNATURE-
Version: PGP 7.1
iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw
fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r
