VeriSign Inc. has been slapped across the face with a blistering 85-page report that found much to criticize and little to praise in the company’s controversial and short-lived Site Finder service.
An advisory committee to the Internet Corporation for Assigned Names and Numbers (ICANN) released a report on Friday that blasts Site Finder, which altered how the Internet’s domain name system (DNS) dealt with nonexistent .net and .com domain names.
When a Web user requested a .net or .com domain name that didn’t exist, VeriSign, which manages the .net and .com domains, automatically redirected the user to the Site Finder Web site. In the past, the user would have landed on a Web page with an error message. The Site Finder Web site offered alternative spellings to the nonexistent domain names, a search feature and a directory of Web sites, which VeriSign maintained was much more useful than an error Web page.
Site Finder, launched Sept. 15, 2003, quickly drew criticism both for the way in which it operated, which caused trouble for some existing applications, and for the way VeriSign launched it, which some viewed as sudden and unexpected. Under mounting criticism from a variety of users and vendors, ICANN ordered the service eliminated. VeriSign shut down Site Finder on Oct. 4, 2003 and it remains unplugged.
The report from ICANN’s Security and Stability Advisory Committee (SSAC) unequivocally states that Site Finder critics were correct in complaining about the service, and it sharply criticizes VeriSign for what the SSAC views as serious missteps.
“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,” the report reads. “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.”
VeriSign isn’t surprised by the report’s findings because it knows that key members of the advisory committee were against Site Finder from the start, said Tom Galvin [cq], VeriSign’s vice president of government relations. VeriSign participated in hearings held last year to discuss this matter and had two of its employees on this advisory committee, he said. “What we do find surprising is that nine months after they held hearings, they still have no data or evidence to support their claims that we were disrupting the security of the Internet,” Galvin said. “That wasn’t the case.”
ICANN ordered Site Finder shut down before VeriSign had a chance to address the problem areas, he said. VeriSign continues to work on improving the service, although it hasn’t decided whether it will relaunch it. In the meantime, it is pursuing its lawsuit against ICANN over the matter, he said. VeriSign filed the suit in February 2004. It alleges ICANN’s conduct with regard to Site Finder violates federal antitrust laws and state law and breaches ICANN’s registry agreement with VeriSign, according to the complaint.
Unless VeriSign can fix the technical problems Site Finder caused, it’s unlikely Site Finder will again see the light of day, said Niki Scevak, a Jupiter Research analyst.
The report goes to ICANN’s board, which will decide what, if anything, it will do based on the findings and recommendations, an ICANN spokesman said. He declined to speculate what actions the board might take. The report’s two main recommendations are: 1) to avoid introducing services such as Site Finder that modify how the DNS deals with nonexistent domains, and to phase out existing services; and 2) make sure that changes to Internet registry services be adopted only after “a substantial period” of testing and discussion involving technical users and end users.
The report explains that a variety of applications and systems have been built over the years whose proper operation depends on the recognition that a domain name doesn’t exist, an action also known as a “no such name” response. Site Finder disrupted these applications and systems by resolving errant DNS queries through its redirection action and thus making them seen legitimate, the report states.
Redirecting a user to a page in a case like this “may be, in a sense, a false positive since the system appears to be providing a valid response when in fact it is masking an error, and an error is a legitimate form of information,” the report reads. “Applications that rely on the ‘no such name’ response fail since the ‘no such name’ response no longer occurs.”
This caused some Web browsers, spam filters, e-mail systems and other automated tools to malfunction when Site Finder was launched, the report states.
Compounding the matter was VeriSign’s decision to introduce Site Finder “abruptly, without public notice, without coordination, without independent testing and refinement, and without agreement from the community of users affected by the change,” the report states. When problems started cropping up unexpectedly after the Site Finder launch, many system administrators at Internet service providers (ISPs) and businesses scrambled to implement fixes, which added to their workload and often created other problems because they had to be implemented in a hurry.
Another problem with Site Finder is that it assumed it would be handling DNS queries primarily from Web surfers, when in fact the system had an effect on other Internet applications, such as e-mail communications, file transfers and remote access, the report says.
The report also takes VeriSign to task for implementing Site Finder without giving users a choice to opt out of it. Site Finder automatically became the de facto response to a nonexistent domain name, eliminating not only the traditional error Web page but also other responses that users can configure their browsers to make. “VeriSign’s action had the effect of disabling existing services and depriving users of a choice as to which service, if any, is to be provided at the desktop and how to configure it. All those choices were removed,” the report reads.
Even more troubling, Site Finder was designed in a way that it could potentially compromise users’ privacy, the report says. “Analysis of Site Finder revealed that a ‘web bug’ had been embedded in the page so that information about behavior of users of the page was sent to a company named Omniture, which monitors Web traffic. Information about users of Site Finder was thus passed off to a third party, again without the consent of the users and perhaps without their knowledge,” the report states.
There was also evidence that Site Finder circumvented strong filters which organizations such as public school systems put in place, which sent public school administrators scrambling to restore their filter protections, the report says.
The report acknowledges that systems such as Site Finder, commonly referred to as “wildcard” systems, have existed for years, but said their potential pitfalls have been widely documented. These systems are recommended only for limited and controlled implementation, for example, within a company, where the entity implementing the wildcard system has control over the affected users and where the effects of the wildcard system don’t affect users outside the organization. Other instances in which it could work properly is in smaller domains, such as the .museum domain, the report states.
