Skip to main content

Message from Security and Stability Advisory Committee to ICANN Board

ICANN Security and Stability Advisory Committee


On September 15, 2003, VeriSign changed the way its COM and NET name servers respond when presented with a query for a COM or NET domain name for when no name server record exists [1]. This change was reported on September 5, 2003 [2] and September 9, 2003 [3], but the implications of the change were not broadly recognized until it was deployed.

Previously, such queries returned RCODE 3 ("name error"), the negative response defined in the official DNS protocol specification, RFC1035 [4]. VeriSign now returns an IP address for a special server, thereby creating the appearance the requested domain name exists. The special server handles the subsequent requests for application level services, e.g. web, email, etc.

This special server is currently listening on port 80 for HTTP (web) and port 25 for SMTP (email) transactions. The web server returns a page indicating the domain name is not registered and offers search and/or registration services. The email server originally bounced all email with a 550 error code, which indicates a permanent failure and would result in the message being bounced back to the sender. Its precise behavior is still subject to change in response to community feedback, substantially changing the way email is queued, routed, and responded to in the COM and NET domains.

Applications or protocols which previously relied on an RCODE 3 response for a non-existing domain have suffered by this change in behavior for COM and NET. Workarounds at the routing and DNS level have been deployed to stop the effect of these wildcards, and these workarounds are an additional source of potential instability.


The Security and Stability Advisory Committee is examining the situation from several viewpoints.

  • Conformance with the protocol specifications as defined by the engineering community.
  • Conformance with accepted best practices and operational procedures as defined by the engineering and operational communities.
  • Consideration of the technical stability and security of the domain name system and the Internet as a whole in light of the both the change introduced by VeriSign and the corresponding changes being introduced by others.
  • Current procedural and governance controls to assure review and analysis of changes to the critical components of the Internet.
  • Public confidence in the stability and reliable operation of the Internet. Security and stability is not limited to a narrow interpretation of the technical specifications of the protocol documents; it also includes engineering, operational, business, and policy issues.

To gather information on security and stability implications, we invite inputs from all interested parties. Send inputs to:

Further, we will meet publicly in the Washington, D.C. area on October 7, 2003, for interested parties to present factual information relevant to the security and stability of the Internet. Details will be available shortly.

Although we continue to gather inputs, there is already enough information to support the following opinions and recommendations.


VeriSign's change appears to have considerably weakened the stability of the Internet, introduced ambiguous and inaccurate responses in the DNS, and has caused an escalating chain reaction of measures and countermeasures that contribute to further instability.

VeriSign's change has substantially interfered with some number of existing services which depend on the accurate, stable, and reliable operation of the domain name system.

  • Many email configuration errors or temporary outages which were benign have become fatal now that the wildcards exist.
  • Anti-spam services relied on the RCODE 3 response to identify forged email originators.
  • In some environments the DNS is one of a sequence of lookup services. If one service fails the lookup application moves to the next service in search of the desired information. With this change the DNS lookup never fails and the desired information is never found.

VeriSign's action has resulted in a wide variety of responses from ISPs, software vendors, and other interested parties, all intended to mitigate the effects of the change. The end result of such a series of changes and counterchanges adds complexity and reduces stability in the overall domain name system and the applications that use it. This sequence leads in exactly the wrong direction. Whenever possible, a system should be kept simple and easy to understand, with its architectural layers cleanly separated.

We note that some networks and applications were performing similar services prior to VeriSign's change. In fact, some user applications and services worked differently depending on the network the user was using. However, VeriSign's change pushes this service to a much lower layer in the protocol stack and a much deeper place in the Internet's global infrastructure, which prevents the user from choosing what services to use and how to proceed when a query is made to a non-existent domain.


Recognizing the concerns about the wildcard service, we call on VeriSign to voluntarily suspend the service and participate in the various review processes now underway.

We call on ICANN to examine the procedures for changes in service, including provisions to protect users from abrupt changes in service.

We call on the IAB, the IETF, and the operational community to examine the specifications for the domain name system and consider whether additional specifications could improve the stability of the overall system. Most urgently, we ask for definitive recommendations regarding the use and operation of wildcard DNS names in TLDs and the root domain, so that actions and expectations can become universal. With respect to the broader architectural issues, we call on the technical community to clarify the role of error responses and on the separation of architectural layers, particularly and their interaction with security and stability.

[1] New York Times Announcement of VeriSign change

[2] Wall Street Journal report of VeriSign change

[3] Computer Business Review report of VeriSign change

[4] RFC1035, Domain Names - Implementation and Specification

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