Advisory Concerning Demand to Remove VeriSign's Wildcard

On 15 September 2003, VeriSign unilaterally instituted a number of changes to the .com and .net Top Level Domain zones, including the deployment of a "wildcard" service. VeriSign's wildcard creates a registry-synthesized address record in response to lookups of domains that are not otherwise present in the zone (including reserved names, names in improper non-hostname format, unregistered names, and registered but inactive names). The VeriSign wildcard redirects traffic that would otherwise have resulted in a "no domain" response to a VeriSign-operated website with links to alternative choices and to a search engine.

Since that time, there have been widespread expressions of concern about the impact of these changes on the security and stability of the Internet, the DNS and the .com and .net domains. The Internet Architecture Board concluded that the changes made by VeriSign had a variety of impacts on third parties and applications, including (1) eliminating the display of "page not found" in the local language and character set of the users when given incorrect URLs rooted under these top-level domains, and instead causing those browsers to display an English language search page from a web server run by VeriSign; (2) causing all mail to non-existent hostnames in the .com and .net TLDs to flow to VeriSign's server (in addition to other effects on certain email programs and servers); (3) eliminating the ability of some applications to inform their users as to whether a domain name is valid before actually sending a communication; (4) rendering certain spam filters inoperable or ineffective; (5) affecting interaction with other protocols in a number of ways; (6) adversely affecting the performance of certain automated tools; (7) in some cases (where volume-based charging is applicable) increasing the user cost simply by increasing the size of the response to an incorrectly entered domain name; (8) creating a single point of failure that is likely to be attractive to deliberate attacks; (9) raising serious privacy issues; (10) interfering with standard approaches to reserved names; and (11) generating undesirable workarounds by affected third parties.

The combination of these effects, according to the IAB, "had wide sweeping effects on other users of the Internet far beyond those enumerated by the zone operator, created several brand new problems, and caused other internet entities to make hasty, possibly mutually incompatible and possibly deleterious (to the internet as a whole) changes to their own operations in an attempt to react to the change.”

The ICANN Security and Stability Advisory Committee, consisting of approximately 20 technical experts from industry and academia, issued a statement on 22 September 2003 that concluded that:

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.

In addition, ICANN has received communications on this subject from the Internet Society, the .au Domain Administration (the operator of the .au (Australia) top level domain), AFNIC (the operator of the .fr top level domain), Public Interest Registry (the operator of the .org Top Level Domain), Melbourne IT (a large ICANN accredited registrar), the GNSO Registrars Constituency (the body that represents all ICANN-accredited registrars) and ICANN's At Large Advisory Committee, all expressing concerns about the impact and appropriateness of these changes. ICANN is also aware of communications from Register.com (another large ICANN registrar) and Cigref (an association that represents the 117 largest French Internet user companies) to VeriSign expressing similar concerns, and of the fact that at least three lawsuits have been filed challenging the specific changes introduced by VeriSign. Many of these communications are collected on the information page established by ICANN relating to VeriSign's wildcard deployment, http://www.icann.org/general/wildcard-history.htm. Finally, ICANN has established a separate comment list accessed at that same URL, and has received a significant number of comments from users, operators, and members of the business community such as Time Warner.

The scope and magnitude of these concerns would, in and of itself, counsel for return to the prior operation of .com and .net until all these issues can be reviewed and evaluated by those affected and those, like ICANN, charged with promoting Internet security and stability. This was the reason ICANN requested, on 19 September 2003, that VeriSign suspend its changes until these concerns could be properly considered. On 21 September 2003, VeriSign responded, refusing to honor that request.

In the 10 days since that response, ICANN has had further opportunity to consider the technical and practical consequences of these changes, and to evaluate whether these unilateral actions by VeriSign were consistent with its contractual obligations to ICANN. As set forth in today's letter to VeriSign, ICANN's preliminary conclusion is that the changes to .com and .net implemented by VeriSign on 15 September have had a substantial adverse effect on the core operation of the DNS, on the stability of the Internet and the .com and .net top-level domains, and may have additional adverse effects in the future. Further, VeriSign's actions are not consistent with its contractual obligations under the .com and .net registry agreements. The contractual inconsistencies include, violation of the Code of Conduct and equal access obligations agreed to by VeriSign, failure to comply with the obligation to act as a neutral registry service provider, failure to comply with the Registry-Registrar Protocol, failure to comply with domain registration limitations, and provision of an unauthorized Registry Service.

For all these reasons, ICANN has today insisted that VeriSign suspend the SiteFinder service, and restore the .com and .net top-level domains to the way they were operated prior to 15 September 2003. If VeriSign does not comply with this demand by 6:00 PM PDT on 4 October 2003, ICANN will be forced to take the steps necessary to enforce VeriSign's contractual obligations.

ICANN is sympathetic to concerns that have been expressed by VeriSign and others about the process by which proposed changes in the operation of a top-level domain registry are evaluated and approved by ICANN. To deal with these concerns, ICANN's President and CEO Paul Twomey is asking the Generic Names Supporting Organization to formulate a proposal for a timely, transparent and predictable procedure for the introduction of new registry services, including as to how a reasonable determination of the likelihood that a proposed change will have adverse effects. This process, to be conducted under the GNSO's new streamlined policy development process, should be completed by 15 January 2004.