As an advisory committee, our focus is to give ICANN and the community our best advice regarding security and stability issues for the domain name system and the addressing system. We are not a standards, regulatory, judicial or enforcement body; those functions belong elsewhere.

As we all know, VeriSign is in the process of suing ICANN on a number of matters, including ICANN’s response to their registry change last September. Although VeriSign now contends that a number of us on the committee are “Site Finder co-conspirators” the next steps are really up to the ICANN board, the ICANN staff and the many members of the technical and operating community who run the domain name system.

I’ll be happy to interact with the members of the community here on CircleID as time permits.

I think the best way to start is with the executive summary of the report titled “Redirection in the COM and NET Domains, A Report from the ICANN Security and Stability Advisory Committee (SSAC)”. These findings and recommendations were developed after extensive inputs by email and in two public meetings in October 2003. The transcripts of those meetings are available from the ICANN web site.

At the end of this summary below, I’ve added some comments on the proposed next steps.

Executive Summary

On 15 September 2003, VeriSign, Inc. changed the way that NET and COM registries responded to lookups on nonexistent—or uninstantiated—domain names. In so doing, the company changed the way that the domain name system (DNS), a fundamental component of the Internet architecture, provides services for two large top-level domains. VeriSign’s action was aimed at the World Wide Web but had unexpected effects on the other parts of the Internet. VeriSign refers to this set of changes as the introduction of its Site Finder service, focusing attention on the functionality provided to Web users who mistyped domain names and were routed to VeriSign’s servers. The specific technical change substituted a “synthesized response” for an error message, and applications that relied on the original error code unexpectedly failed. At ICANN’s insistence and after widespread protest from the technical community, VeriSign suspended the Site Finder service on 4 October 2004.

This report by the Security and Stability Advisory Committee (SSAC), an advisory committee to ICANN, describes VeriSign’s actions of September-October 2003 and the technical community’s responses to those actions and then analyzes the sequence of actions and reactions from the perspective of security and stability of the Internet. The Committee then presents its findings and recommendations. The Committee’s primary focus is not Site Finder, per se. Rather, our focus is two-fold: that core registry operations were modified, thereby changing existing services, and that the change was introduced abruptly without broad notice, testing, refinement or community agreement.

The Committee finds that VeriSign’s actions did not have network-shattering effects but did violate fundamental architectural principles and well-established codes of conduct and good practice intended to ensure stability. Users’ decisions and control were preempted and users were potentially subjected to violations of their privacy. Local responses, patches and work-arounds reduced overall coherence. Services that had been functioning satisfactorily were disturbed and the direct and indirect costs of these disruptions were imposed on third parties. Specifically:

Finding (1): VeriSign introduced changes to the NET and COM registries that disturbed a set of existing services that had been functioning satisfactorily. Names that were mistyped, had lapsed, had been registered but not delegated, or had never been registered in DNS were resolved as if they existed. As a consequence, certain e-mail systems, spam filters and other services failed resulting in direct and indirect costs to third parties, either in the form of increased network charges for some classes of users, a reduction in performance, or the creation of work required to compensate for the consequent failure.

Finding (2): The changes violated fundamental Internet engineering principles by blurring the well-defined boundary between architectural layers. VeriSign targeted the Site Finder service at Web browsers, using the HTTP protocol, whereas the DNS protocol, in fact, makes no assumptions - and is neutral - regarding the protocols of the queries to it. As a consequence, VeriSign directed traffic operating under many protocols to the Site Finder service for further action, and thus, more control was moved toward the center and away from the periphery, violating the long-held end-to-end design principle.

Finding (3): The mechanisms proposed by VeriSign to ameliorate the undesirable effects of their diversion on protocols other than HTTP put VeriSign in the implementation path of every existing and future protocol that uses DNS. For every such protocol, it would be necessary to consult with VeriSign to figure out how to simulate the response of the protocol to “no such domain.” This is an unacceptable invasion of clear layering.

Finding (4): Despite a long period of internal research and development, the system was brought out abruptly. The abruptness of the change violated accepted codes of conduct that called for public review, comment and testing of changes to core systems; this process exists to ensure that changes are introduced with minimal disruption to existing services and hence with minimal disruption to the security and stability of the Internet. It also precluded the possibility that administrators, IT departments, ISPs and other intermediaries on whom end users rely might be adequately prepared to deal with the consequences.

Finding (5): In response, workarounds and patches were introduced quickly, cumulatively reducing the overall coherence of the system and again violating the established practices of public evaluation, testing, discussion and review before core services are implemented and deployed. These workarounds further blurred the functional layers intrinsic to the Internet’s robust architecture and in some instances created additional—and unintended—harmful effects.

Finding (6): Information about intended e-mail senders and receivers was necessarily accepted by VeriSign’s servers without the knowledge or consent of either sender or receiver. VeriSign strenuously denied retaining this information.

Finding (7): The behavior of end users redirected to the Web site was observed by a program embedded in the Site Finder service, and users could neither accept it, reject it nor substitute another, similar service for it.

Finding (8): The cycles of changes and responses collectively undermined expectations about reliable behavior and in so doing reduced trust in the security and stability of the system. On the basis of these findings, the Committee makes the following recommendations:

Recommendation (1): Synthesized responses should not be introduced into top-level domains (TLDs) or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries over which the operator may have little control or influence. Although the wildcard mechanism for providing a default answer in response to DNS queries for uninstantiated names is documented in the defining RFCs (Requests for Comment), it was generally intended to be used only in narrow contexts (for example, MX records for e-mail applications), generally within a single enterprise, and is currently used in top-level domains that are generally small and well-organized.

Recommendation (2): Existing use of synthesized responses should be phased out in TLDs or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries.

Recommendation (3): There exist shortcomings in the specification of DNS wildcards and their usage. The defining RFCs should be examined and modified as necessary with a focus on producing two results: first, clarification of the use of synthesized responses in DNS protocols; second, provision of additional guidance on the use of synthesized responses in the DNS hierarchy.

Recommendation (4): Changes in registry services should take place only after a substantial period of notice, comment and consensus involving both the technical community and the larger user community. This process must (i) consider issues of security and stability, (ii) afford ample time for testing and refinement and (iii) allow for adequate notice and coordination with affected and potentially affected system managers and end users. Thirty years of experience show that this strategy ensures robust engineering and engenders trust in the systems and the processes surrounding their maintenance and development.