Every so-called “computer geek” has no doubt had the pleasure of dealing with a user who is convinced that the entire Internet runs off of a central “Internet server”. How many times have you heard “I can’t get my email, the Internet server must be down!” (Okay, I’ll avoid pointing out the sheepish look on the guy in the back who has uttered those words himself.) It’s from this little piece of technical support lore that my friends and I have a running joke that I run the “Internet server” (for our group, of course) and every time it’s unreachable for some reason or another, we tell each other, “the Internet server’s down!”

So what am I trying to get to? Well, as of 20:00 EDT time on Monday, September 15, 2003, there is now an “Internet server”. Its name is sitefinder.verisign.com, currently found at the IP address of 64.94.110.11. Every request for an Internet domain name that doesn’t exist, has expired, or is simply misspelled, will be answered with this magical site. What does this mean? What’s wrong with VeriSign’s actions? Let’s take a look at the myriad of reasons from a technical and legal standpoint, and then we’ll finish off with the moral and ethical concerns that I, personally, along with many other network operators, have about this change.

Let’s start off with one very important point: the irresponsibility of making this change to the critical infrastructure of the Internet without the input of the thousands of network operators who, collectively, make the Internet work. VeriSign must realize that as the maintainer of the databases for the two most-used TLDs on the Internet, .com and .net, it has a great responsibility to the Internet as a whole and must put the health of the Internet before its own commercial interests.

The Technical Concern

As VeriSign has implemented this without prior notification or warning, there has been little time (about an hour and a half at the time of this writing) to fully examine the technical breakage that will occur as a direct result of this change. There are a few problems that are already evident, however. One is the operation of some anti-spam filtering software. Among the other protections that spam-blocking software employs, one method to block spam is by blocking messages that appear to be sent from non-existent domain names. This feature magically stopped working, as there is no way for a domain name lookup to fail. Next, there is VeriSign’s handling of SMTP connections aimed at their wildcard host. According to an “Implementation” document posted to NANOG (the North American Network Operator’s Group) list by a VeriSign employee, the SMTP listener on the sitefinder.VeriSign.com host should refuse all mail. To quote the document:

“The Site Finder response server runs a limited SMTP server that returns an SMTP 550 error response for any specified destination (i.e., any RCPT TO value). The error message includes explanatory text explaining that the message did not reach the intended recipient because the destination domain does not exist.”

However, this does not seem to be the case, as tested at 22:30 hours EDT on September 15:

% telnet asijfoawiejawoef.com 25
Trying 64.94.110.11…
Connected to sitefinder-idn.verisign.com.
Escape character is ‘^]’.
220 snubby1-wceast Snubby Mail Rejector Daemon v1.3 ready
help
250 OK
mail from:

250 OK
rcpt to:

550 User domain does not exist.
rcpt to:

250 OK data 221 snubby1-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel

This response is dramatically different from what is called for in VeriSign’s own Implementation documentation. Instead of returning a 550 error code for our example domain, the mail server continues with a positive, 250 OK response. The mail server gives up only after I attempt to send it the contents of the email message—this is handled by most mail transfer agents as a transient error and will continue retrying for several days to send the message. This will cause problems for legitimate e-mail whose mail addresses have been mistyped by the sender. Perhaps even more disturbing is the fact that VeriSign, at its choosing, could easily decide to intercept such misdirected e-mails by not closing the SMTP connection after the “DATA” command. Already VeriSign has a record of the sender of any messages whose destination addresses have been misspelled through this change. I haven’t even touched upon the professionalism of the “Snubby Mail Rejector” message and I am at a loss as to how the responses issued by this SMTP daemon provide explanatory text for an inexperienced Internet use that their message did not reach its intended recipient. The Legal Concern And that, in turn, provides a great segue into the legal aspects of VeriSign’s new “service.” Let me first emphasize that I am not a lawyer, and if I were, I wouldn’t be handing out free legal advice anyway. To start the legal discussion, we can continue where we left off with the mail service provided by VeriSign’s Site Finder wildcard DNS server. VeriSign itself admits, in the same Implementation PDF file, that all accesses to the Site Finder service are monitored and archived:

“2.4 Monitoring and Communication VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign’s Network Operations Center…. Several hours of the complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis.”

It is not fully disclosed how this monitoring information will be used by VeriSign internally, or whether VeriSign will voluntarily provide this data to law enforcement upon request. The privacy implications here can be staggering, as mistyped URLs can contain sensitive information, including usernames and passwords. In fact, it can be demonstrated for a fact that VeriSign is not ignoring data after the domain name in a URL by typing in, for example:

http://www.boguswebsiteforVeriSign.com/myuserid=blah&mypassword=blah

The URL that we’re redirected to is:

http://sitefinder.VeriSign.com/lpc?url=www.boguswebsiteforVeriSign.com/myuserid%3Dblah%26mypassword%3Dblah&host=www.boguswebsiteforVeriSign.com

This demonstrates that the redirection script on VeriSign’s servers is actively intercepting not only the domain name in the URL, but also any other data present in the URL. The Privacy Concern A further worry for users is the privacy policy and terms of service posted on the Site Finder service. Not only does the simple act of mistyping a URL implicitly cause you, the end user, to accept VeriSign’s Terms of Service and Privacy Policy without the chance to review and accept or decline either, but critical information as described above is not disclosed in either policy (as of this writing). The Privacy Policy clearly states:

“We do not collect any personal information from visitors to our Site Finder. Under no circumstances do we collect any personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life.”

(Interesting that they specifically point out union membership and sex life… I haven’t seen those singled out in any other privacy policy before…) The point, of course, is that at no point in this Privacy Policy does VeriSign disclose the active monitoring and archival of the site’s usage. The Privacy Policy goes on to say:

“We assure you that the information we gather from you about your visit is in aggregate form and solely for the purposes of operating and improving the performance of our Site Finder.”

To the contrary, there is no doubt in my mind that individually identifying information will be collected as part of an active monitoring and archival system, once again, as disclosed by VeriSign themselves in the Implementation document. Even after a thousand words or so, I haven’t even begun to discuss the abuse of VeriSign’s monopoly power to the exclusion of the hundreds of other accredited domain name registrars. I hope, however, that this quick document has at least begun to examine the latest Pandora’s Box that VeriSign has foisted upon the Internet community. I leave you with one question, put best by the subject of the ongoing thread at NANOG on this subject: “What *are* they smoking?”