[GTER] Fw: COM/NET informational message

Rubens Kuhl Jr. rubens at email.com
Fri Jan 3 21:57:00 -02 2003


Para os que tem domínios .com e .net, aviso importante.

Fred, teremos IDNs em .br ?


Rubens


----- Original Message -----
From: "Verd, Brad" <bverd at verisign.com>
To: <nanog at merit.edu>
Sent: Friday, January 03, 2003 3:49 PM
Subject: COM/NET informational message


|
|
| -----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 at 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-----




More information about the gter mailing list