Forwarding by request. Please direct replies to John Fraizer. ------------ Forwarded Message ------------ Date: Wednesday, October 8, 2003 11:41 AM -0400 From: John Fraizer <nanog@overkill.enterzone.net> To: Owen DeLong <owen@delong.com> Cc: Brian Bruns <bruns@2mbit.com>, nanog@merit.edu, charles.cooper@cnet.com, cook@cookreport.com, nanog@merit.edu Subject: Re: Verisign's public opinion play Owen, et all: I wrote a piece as soon as I read McLaughlin's PR spewage. I sent it to the addresses I could find at cnet but, I have not geard from them. PS: Owen, I don't have NANOG-post access. Can you echo this to the list for me? Dear Editor, In response to the article presented by Mark McLaughlin on October 6, 2003 at CNET.News.Com, "Innovation and the Internet," I would like to present the following rebuttal. McLaughlin states when a user mistypes a URL and are presented with an error, "That error page can lead to a dead end, with no options on how to get to where you tried to go." I guess we should thank our lucky stars that VeriSign is there to save us from ourselves. After all, none of us are resourceful enough to actually look at the URL we typed and notice that we have made a typo. In the event that we are unsure of the exact domain name, none of us are resourceful enough to consult Google, Yahoo or any one of the numerous other search engines. We will simply sit and stare at the error page and our personal productivity will suddenly screech to a halt. VeriSign to the rescue, right? Not quite. McLaughlin states that someone typos a domain name 20 million times per day and that "people have used [Site Finder] more than 40 million times". VeriSign deployed "Site Finder" on September 15th 2003, and subsequently bowed to overwhelming public pressure to remove the wildcard entries in the .COM and .NET DNS Zones that facilitated their directing "lost" users to their "Site Finder" service on October 4th, 2003. So, according to McLaughlin's own numbers, over the 20-days that "Site Finder" was in service, of the 400 million "typos" that VeriSign redirected to its "Site Finder" service, only 10% of those who were redirected made use of the service. It would seem to me that this would indicate that 90% of the users do not find the "Site Finder" service as useful. McLaughlin goes on to say, "ICANN cast a vote last week for the status quo by forcing VeriSign to shut down the service." This is an inaccurate claim and is obviously worded to incite the public perception that ICANN has forced VeriSign to shut their "Site Finder" service down. Nothing could be further from the truth. ICANN demanded that VeriSign remove the "wildcard" records from the .COM and .NET DNS Zone files. The "Site Finder" service is still operational at http://sitefinder.verisign.com/ and any person who desires to use that service can do so by simply typing that URL into their browser. The difference is that users are not being FORCED to use the "Site Finder" service. This brings us to a very important point - one that VeriSign, with much help from the press, has gone to great lengths to obfuscate. "Wildcard" records in the .COM and .NET DNS Zones are NOT the "Site Finder" service. The wildcard records in question were implemented in the following form: "* IN A [IP address of Site Finder service]" ICANN did not demand that VeriSign shut down it's "Site Finder" service. They simply demanded that VeriSign remove the "wildcard" records from the .COM and .NET TLD DNS Zones. In operation, the existence of this record in the .COM and .NET DNS Zones would cause any typo in the domain portion of a fully qualified domain name to be redirected to an IP address operated by VeriSign on which they had implemented their "Site Finder" service. This "hijacking" of typos has many security, privacy and interoperability implications, all of which VeriSign have failed to address in a satisfactory manner. (1) The "Site Finder" service is subject to "man-in-the-middle" type attacks in which traffic to/from "Site Finder" can be intercepted. For a person using a web browser, this will expose information about the site(s) they are attempting to access. In the case of email, the entire contents of an email message may be captured by a third party. This email may very well contain sensitive information that has now been compromised. Prior to the implementation of "wildcard" records in the .COM and .NET DNS Zones by VeriSign, a simple typo in an email or URL did not expose users to this very probable and easy to implement attack. (2) Anthony F. Lo Cicero, Esq., on behalf of Register.com, outlined several interoperability implications in his letter to Brian Davis, Esq., Chief Litigation Counsel, VeriSign, Inc., dated September 19, 2003. Lo Cicero states, "As VeriSign is well aware, many registrars, including Register.com have long-established business practices of disabling the DNS of recently-expired domain names, as a means of notifying the customers of their need to renew their registrations. Contrary to its public claims, VeriSigns SiteFinder service interferes with these active registrations, hijacking their DNS and pointing them to a monetized search engine." Lo Cicero goes on to say, "Certain other names being redirected by VeriSign to the SiteFinder web site are also active registrations for which the registry fee has been paid. For example, names for which customers have chosen to disable the DNS and registrations that have been seized by Register.com, and for which it has disabled the DNS, all now point to SiteFinder." (3) Dr. Paul Twomey, President and CEO, ICANN, in his letter dated September 22, 2003 states, "Because the VeriSign Site Finder server makes it appear that a non-existent domain exists, the service introduces significant problems to the critical Internet infrastructure. Many other important Internet protocols rely heavily on proper DNS behavior. The impact of VeriSigns Site Finder is unclear with respect to security of the DNS. Site Finder unilaterally precludes the use of a prevalent type of anti-spam filter that uses DNS to validate the domain of legitimate emails. Because VeriSign's servers are authoritative for the .COM and .NET TLDs, the most prevalent of the TLDs, Internet users have little protection against the implication of this flawed system." (4) Web browsers all over the world stopped displaying "page not found" in the local language and character set of the users when given incorrect URLs rooted under the .COM and .NET TLDs. Instead, browsers presented an English language search page from a web server operated by VeriSign. For visually impaired users who make use of computer generated voice software to dictate the contents of web sites to them, the actions of VeriSign present a significant barrier to their enjoyment of the Internet. As stated by the Internet Architecture Board on September 19, 2003, "Even if these were acceptable changes, the new mechanism has poor scaling properties, and unless the operator [VeriSign] chooses to invest significant resources in maintaining a large, robust web server setup, the user experience is going to get even worse: instead of either a local language error message or an English search page, the user is going to get 'attempting to connect...' followed by a long wait." (5) All email addressed to misspelled or nonexistent domains flowed to VeriSign's server where it was bounced back to the sender. This has many ramifications. Operators now have heavier mail handling load than they did under the previous DNS operation where the email would be bounced locally. Operators were dependent on the performance of the bounce server operated by VeriSign. If VeriSign's server slowed or failed, mail that would previously have been bounced by the operators server would queue at the SMTP relay for that relay's queue time before bouncing back to the user. Emails that would have previously bounced back to the user immediately went unnoticed for days while they sat in the SMTP delivery queue. Operators were also dependent on the correct operation of VeriSign's bounce server. VeriSign's bounce server experienced bugs that caused mail that would have previously bounced to not bounce at all and may have been reported to the user as having been delivered when in all actuality, it simply vanished without a trace. In cases where domain owners had misconfigured backup mail exchangers (MX's) with a particular MX pointing to a non-existent domain name, mail that would have previously been eventually delivered bounced. If a user misconfigured their mail client to point to a non-existent domain name, the client would connect to the bounce server and be presented with an error indicating that the recipient address was wrong when in all actuality, this was not the problem. (6) Network printer configuration tools commonly check the validity of the print spooler. With VeriSign's wildcard records in place in the .COM and .NET TLDs, an error that would have been reported early in the configuration process would have only been noticed when printing failed to work. Additionally, it is quite possible that proprietary and confidential information was routed to VeriSign's servers when users attempted to print to misconfigured network printer spools. (7) The wildcards installed in the .COM and .NET TLDs broke several simple spam filtering techniques commonly used on mail servers as well as more complex filtering that checked for the existence of a sending domain to screen out obviously bogus senders. (8) VeriSign intercepted HTTP and SMTP requests that were routed to their server as a result of the wildcards they placed in the .COM and .NET TLDs. The internet is much more than the Web and Email however. FTP, Telnet and SSH, as well as an enormous number of other protocols that are in use on the internet that made connection attempts to a misspelled domain name received at best a TCP reset message and in some cases, simply had their packets dropped with no error. Prior to VeriSign's implementation of the wildcard records in the .NET and .COM TLDs, these attempts would have received DNS error messages. With VeriSign's wildcard scheme in place, these messages were replaced by mysterious connection failures. (9) The response from the VeriSign "Site Finder" service was typically around 17000 bytes of information. Prior to VeriSign's implementation of wildcard records in the .COM and .NET TLDs, the user would have received a response that was typically more than 10 times smaller. In the case of transfer based billing for Internet access (as in the case of most wireless data services) the recipient had to pay significantly more in access charges. McLaughlin states, "ICANN appears to have bought into claims that the Internet has broken or will break. Anyone who has used it in the last three weeks knows that claim to be false. More likely, ICANN caved under the pressure from some in the Internet community for whom this is a technology-religion issue about whether the Internet should be used for these purposes." The claims that ICANN "bought into" are not unfounded or anecdotal. They are documented cases of previously functioning systems and protocols that ceased to function as desired when VeriSign implemented the wildcard records in the .COM and .NET TLDs. VeriSign does NOT OWN .COM and .NET. - They are entrusted with their stewardship. Their actions with respect to adding wildcard records to those Zones, with the purpose of profiting millions of dollars by selling the traffic generated by typos under the thin veil of "offering a service" was not consistent with the terms of their contract. DNS operates much in the same way that the telephone translations database operates. Much in the same manner that you receive a recorded announcement indicating "the number you have dialed is not in service" if you dial a non-existent telephone number, the DNS protocol presents a "no such name" response when a lookup is performed against a non-existent domain name. There would be bloody hell to pay if AT&T, for example, poisoned the telephone translations database and routed all non-existent telephone numbers to an automated "directory assistance" service that featured recorded "commercials" from third parties yet, VeriSign seems to think it is OK to do practically the same thing with the TLD DNS Zones for .COM and .NET, sending all "typos" to their "Site Finder" server, complete with paid advertisements and listings by third parties. VeriSign has spared no expense in their attempts to sway public opinion. They have tried to portray the image that they are being attacked for their generous offering of the "Site Finder" service. It would appear that a staggering number of news outlets have bought into this obvious spin of the facts. I sincerely hope that you will publish this article so that the general public has opportunity to digest the technical FACTS of the matter to draw their own conclusions rather than basing those conclusions on knee-jerk reactions to the fodder being spewed by the Public Relations army at VeriSign. Biography John Fraizer is the President of EnterZone Network Services, LLC. He is also an active member of the Internet Security community. Prior to founding EnterZone, Fraizer worked for Digital Equipment Corporation and Alltel Mobile Communications. Fraizer is also an honorably discharged United States Marine. ---------- End Forwarded Message ----------