Skip to main content

IAB Response to Verisign GRS IDN Announcement, January 2003

Document Type IAB Statement
Title IAB Response to Verisign GRS IDN Announcement, January 2003
Published 2003-01-25
Metadata last updated 2023-08-09
State Active
Send notices to (None)

Subject: Re: Request for Advice on VGRS IDN Announcement 
To: "M. Stuart Lynn" <> 
Cc: Leslie Daigle <>, 
Chuck Gomes <>, 
Brad Verd <>, 
Masanobu Katoh <>, 
Steve Crocker <>, 
Vint Cerf <>, 
Louis Touton <>, 
Andrew McLaughlin <>, 
Date: Sat, 25 Jan 2003 10:19:37 +1100

Dear Stuart,

Thanks for your message. After reviewing the announcement, examining the behavior of the deployed system, discussing the issue with colleagues external to the IAB, and meeting with VeriSign’s technical staff to go over the system’s aim and implementation, the IAB has come to the following consensus.

The IAB feels that the system VeriSign had deployed for .com and .net contains significant DNS protocol errors, risks the further development of secure DNS, and confuses the resolution mechanisms of the DNS with application-based search systems. The IAB understands the efforts that VeriSign has made to limit the applicability of this system to queries which would normally not correspond to registered domains, and it recognizes the importance of the distribution of IDN-capable systems to end users. While the IAB agrees with VeriSign that rapid adoption of IDN-capable systems is desirable, the IAB feels that the very limited gain in distribution cannot balance the shortcomings of this deployment strategy.

The IAB has begun the process of shepherding the creation of an Informational RFC on concerns with operational practices with the DNS. We anticipate discussing the issues raised in your notes in more detail as part of that document. Given the scope of the issue, and our desire to ensure that it will have adequate review by the (DNS) operational community, we will be enlisting the help of the broader IETF community through relevant IETF working groups. In advance of that document, we have outlined below the issues with the VeriSign system which led us to the conclusion above.

As a lookup system, the DNS is designed to provide authoritative answers to queries. The DNS protocol specifies behavior for queries whose targets do occur in a zone by describing the data format for the specific resource records and the wire format for the response. The DNS protocol also specifies behavior for queries whose targets do not occur in a zone by describing the wire format for a negative response.

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. While it is possible within the DNS protocol to include wildcard records which cover all queries not otherwise specified by a zone, this is not what VeriSign has done. Negative answers for records which do not contain code points above 127 continue to be sent.

It would, of course, be theoretically possible to add zone entries for all records containing code points above 127. Given that the Verisign system does not recognize “.” as a label delimiter for testing these records, the size of the resulting zone is unimaginably large. VeriSign confirms that they are not managing a zone of the size this would imply and is, instead, synthesizing these entries. This implies that the zone as currently served by VeriSign cannot be transferred using either AXFR or file transfers in master file format. Though the choice of who may employ AXFR or file transfer to get copies of a zone is a policy decision, the IAB notes that the current system does not allow any of the standard methods for transfer to be used.

More importantly, 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. Queries for A (Address) RRs for the name \ return A RRs, but queries for other types such as NS (name server) or MX (mail exchange) return an NXDOMAIN (no such domain) response, which would implies that there are no records of any type at the name \ To put this more strongly: a DNS implementation with negative response caching enabled (highly recommended, in order to reduce the number of unnecessary queries sent to the root and TLD servers) would come to different conclusions about the existence of the A RRs for the name \ depending on the precise order of query operations it had processed in the recent past. For the order of the queries issued to result in different responses is a serious data integrity issue.

Other data integrity issues are commonly cited as key reasons for the deployment of DNSSEC. 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. There are well-known security threats to any online signing system, but this also poses a significant risk of denial of service, because the combination of synthesized records and online signing is prohibitively expensive. While DNSSEC is not yet deployed, the IAB believes that this design sets a precedent which, if it remains or has spread elsewhere when DNSSEC deployment starts, would cause serious operational problems.

Without DNSSEC, operators often rely on data checks using related data sources. As a registry, the .com and .net zone operator would normally provide data on entries in the .com and .net zones via provisioning protocols (such as EPP) and information service protocols (such as whois). 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.

The system VeriSign has deployed for .com and .net has made some provisions to assist in the diagnosis of problems. The hosts corresponding to the A records returned to these queries listen on two ports: 25 (SMTP) and 80 (HTTP). Efforts to connect to send mail via port 25 are met by immediate failure at the MTA level, and an explanatory message is sent; this allows the sending or intermediate MTA to immediately return an error and thus avoids queuing of mail sent to addresses using these names. HTTP connections are examined and their host and user-agent headers used to construct a response.

While the effort is well meant, there are several problems with this approach. First, any attempt to connect to ports other than 25 and 80 is refused. For any application which treats connection refused errors as transient, that application’s external time-out must be reached before the user is notified and any queued traffic is discarded. While VeriSign has handled this issue for SMTP, the more general case is still a problem.

Second, the examination of the host and user-agent headers to construct a response results in essentially two messages: a 404 error indicating that the resource is unavailable or a web page which presents a guess about what domain or domains might have been the target of the query and possibly a pointer to the VeriSign plug-in. The first response is a misuse of the 404 response code as described in RFC 2616, section 10.4.5; an application level error like 404 is not a replacement for the DNS-level NXDOMAIN. Though this may appear to be a minor error since the user experience is often similar, it is important to remember that not all systems using the DNS have human users. While a human user may have the insight to recognize that a 404 error occurred because the host is not present, despite a previously successful DNS response, systems or agents without human users cannot make a similar deduction.

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. The DNS is not a search service, and presenting speculative mappings based on HTTP inputs is not the service that the registry is expected to provide.

At the core of all of the IAB’s concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet’s infrastructure that converting it to an application-based search service, as the deployed system does, is not appropriate even in the case where the query presented would not normally map to a registered domain.

To restore the data integrity and predictability of the DNS infrastructure, the IAB believes it would be best to return the .com and .net TLD servers to the behavior specified by the DNS protocols. VeriSign should, of course, be free to continue to distribute its plug-in in other ways, and we hope with them that the deployment of IDN-capable systems is as rapid as possible.

best regards,


per Geoff Huston

IAB Executive Director

Subject: Request for Advice on VGRS IDN Announcement From: M. Stuart Lynn <> To: Leslie Daigle <> CC: Chuck Gomes <>, Brad Verd <>, Masanobu Katoh <>, Steve Crocker <>, Vint Cerf <>, Louis Touton <>, Andrew McLaughlin <> Date: Mon, 06 Jan 2003 11:37:59 -0800

Dear Leslie,

Below is a note seeking IAB advice on a technical question pertinent to ICANN DNS coordination activities. I would very much appreciate your consulting with the IAB and letting me know any advice at your earliest convenience.

Warm regards,


To the Internet Architecture Board:

On Friday, 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

-----Original Message----- Subject: Serious technical problems with VGRS's announcement From: Paul Hoffman / IMC [] To: Cc: Louis Touton; Patrik Faltstrom Date: Sunday, January 05, 2003 7:18 PM

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 .com in Internet Explorer for Windows, where “” is the single hex octet 0xE5, you see the screen shown in the attached file called “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