User Tools

Site Tools


legacy:2003:sitefinder1

Verisign Sitefinder Service Guide

Date: 10/6/2003
Last Edited: 2/26/2004
Released to the public under the following license:
Copying and redistribution is permitted as long as proper credit is given to the Summit Open Source Development Group.


An end user's guide to the problems associated with the implementation of the Verisign SiteFinder service

On Sept. 15, 2003, Verisign (and its division, Network Solutions) implemented one of the most radical changes to the basic structure of Internet functionality. This change was done without consulting the Internet community, any of the standards board, the Dept. Of Commerce, or ICANN.

The change was a fairly simple one - what is known as a wildcard record was added to the top level domains (known further as TLD) .com and .net, two of the largest and most popular TLDs on the Internet. This wildcard record was designed to catch common typing errors when inputting a domain name into a web browser, such as Internet Explorer, Mozilla, Netscape Navigator, and Opera.

Instead of a 'domain not found' error, the wildcard would redirect the end user to the SiteFinder service (http://sitefinder.verisign.com) where they could either search the web for the information they were looking for, or choose a site with a similar name.

It should be noted that Internet Explorer and AOL both already implement a system like this for their respective users (it is done either via built in browser settings or in the case of AOL, their web proxies). This generates extra funds for both Microsoft and AOL and helps drive traffic to their own web search engines.

The methods used by Internet Explorer and AOL do not affect any other Internet provider or company, nor does it affect any service besides web browsing, unlike the Verisign method.

Unfortunately, the use of wildcards in the .com and .net TLDs do not just affect web browser activity, but every service which depends on the domain name services (known further as DNS). If DNS was only used for web browsing, the technical standpoint of the issue would be moot. Other services of the Internet, such as Electronic Mail (E-Mail) and Internet Relay Chat (IRC) also depend on the DNS system in order to function.

In this short document, we will discuss some common questions and issues that you, the end user might not personally see, but might affect how you use the Internet.

Competitive Issues

One of the most important issues brought up by the SiteFinder service is, "Who gets to control the content you see when you type in an incorrect domain name?" In the case of the SiteFinder service, total control is given to Verisign.

This has understandably caused major concerns with other companies who offer domain name services, such as Register.com and Go Daddy Software. Nothing stops Verisign from directing users to purchase domain names from its Network Solutions division from the SiteFinder service. This cuts out competition completely and effectively.

Years ago, Network Solutions (before it was bought by Verisign), was forced to give up its monopoly on domain names and allow competitors to offer direct registration of .com, .net, and .org domains. This caused a major boom in domain registrations because users could now choose the provider which best suited their needs. Network Solutions still controlled the TLD DNS servers, but had to allow their competitors access to the database.  The .org top level domain is no longer under Verisign control and has been turned over to Public Internet Registry (PIR).

This is not the first time Network Solutions has been called out for their actions. The Dept. Of Commerce/ICANN owned site InterNIC (http://www.internic.net) was essentially hijacked by Network Solutions and redirected to the Network Solutions main site many years ago.

It was also brought to the attention of the Internet community that Verisign was making a profit off of the SiteFinder service through its ties with the Overture paid search service and other advertising companies. Although the actual figures are unknown, it is believed to be many millions of dollars. These funds go directly to Verisign and are not distributed to groups like ICANN and other register services.

Verisign tries to justify the need for pay-per-click links by claiming that they need the money to continue to 'innovate' and improve the services that they offer to the Internet community.  Of course, it should be noted that Verisign does not run all of the root name servers.  It only maintains and controls the .com and .net name servers.

The .com and .net top level domain name servers do not provide resolution for all of the top level domains - the main root name servers are the central point of contact when an end user requests a domain name.  It should be noted that the root name servers are run and funded by various groups, including the ISC and Verisign.  These servers continue to run, privately funded, without interference and without needing to generate profit in on themselves.  These servers are provided for the benefit of the Internet community.

While the .com and .net top level domain name servers handle more then half of the queries for domain names due to the popularity of those two top level domains, they most likely do not see the same level of queries that the root name servers do.  As such, I do not completely understand the need for the .com and .net name servers to generate a profit except to provide revenue to a company that already abuses its monopoly powers at a level that comes very close to Microsoft (and, if carefully reviewed, many of the justifications that Verisign has for their actions are very similar to Microsoft's justifications for its monopoly on computer operating systems).

I do, however, understand the need for Verisign to support its root name server and the top level domain name servers it has.  The costs of running those servers are very high and time consuming.  But, you have to remember that Verisign makes a profit off of each domain registration that is handled not only by them, but every other .com and .net registrar like Register.com and GoDaddy.

Paid search results bring another issue into the mix - users can not be sure the results they see when they search the SiteFinder site are not being sponsored by a company (and thus making the results unfair towards other companies or groups, or confusing the end user). Services like Google's search engine are better implemented in that paid results are completely separate and marked as such, giving the end user the information they need while still allowing companies to reach users.

Another competitive issue that has been brought to my attention, is that the SiteFinder service, with its wildcard, essentially 'registers' all of the non-existent and expired domain names to Verisign.  While it does not mark the domain down in the database as being 'taken', it still appears as such to end users and applications that look for the NXDOMAIN response (no such domain).  For any other provider to do the level of registrations that Verisign is effectively doing, they would need to spend literally hundreds of millions of dollars (if not billions) to register every domain name and combination possible as allowed by accepted Internet standards.

Verisign, with its monopoly control over the .com and .net database, is not limited in this manner, and has bypassed this requirement.  If you register a domain yourself, it points to your servers, and is under your control.  The SiteFinder service does the same exact thing - it takes unregistered domain names (and expired, unpaid, and suspended domain names as well), and points them to Verisign owned servers, only without ever having to put forth the money that everyone else would, and without actually marking the domain as 'taken'.

Finally, it is brought to the attention of the Internet community that the SiteFinder service page contains a device called a Web Bug which provides advertisers information about your computer and its setup. This Web Bug is hidden in the page and not visible unless you select to view the page's source code. It is still unknown who gets this data, and how it is being used.

To help you understand the issues in this section, consider this. Remember the breakup of AT&T? What if, as the main custodian of the phone system, they decided to redirected all of the messages for misdialed numbers to a service which tried to help you guess which number you really meant to dial, and offers you suggestions? What if AT&T then took the information on the most popular misdialed numbers and offered to sell them to the highest bidder or placement rights in the error message? Imagine trying to call United Airlines, and instead getting an advertisement for American Airlines and an offer to call THEM instead. On top of it all, the phone company now has information on your dialing habits which might be of interest to third party marketers.

E-Mail Service Issues

A hot topic with the SiteFinder service issue is that the wildcard record in the .com and .net TLDs causes certain issues with E-Mail (both receiving and sending). To try and help mitigate this problem, Verisign implemented on their SiteFinder services a dummy Simple Mail Transport Provider (SMTP) service which returns errors when mail is sent to it. Unfortunately, this creates several issues.

First major question is, can Verisign be trusted not to collect E-Mail addresses and the contents of those messages accidentally directed to their service and sell them to a third party? Unfortunately, the answer is no. This means that should you accidentally mistype the E-Mail address of the person you want to send to, it could be captured, stored, reviewed, and even sold to another company by Verisign. This means your confidential communications with others could become public or used by others for their own gains.

Second, the wildcard causes delays in the end user finding out if they mistyped the domain name of the person they are trying to send to. This could mean lost time and money if you are a business and need to contact your customers or partners within a certain time frame. Normally, if the DNS servers return 'no such domain', your mail would be rejected right away and bounced back to you with an error. Now, it could take hours or even days before you see a proper bounce message, and you would never even know your message never went through.
Third, and one of the most important issues the wildcard records have caused is Anti-Spam provisions. In a normal and modern SMTP server, E-Mail that is received that has a domain name which doesn't exist is bounced back with an error. Spammers commonly include fake and non-existent domains in their E-Mails. This simple function would effectively cut down on much spam the server received.

Now, with the new wildcard record, all .com and .net domains come back as existing. This causes SMTP servers to blindly accept any and all mail addressed to them even if it doesn't contain a valid domain name. Further, evidence from providers and users alike, during the days after the wildcard was added, spam increased heavily as the Spammers realized they no longer had to carefully craft the addresses in their mails. Many providers had to resort to reprogramming their SMTP servers and adding in 'hacks' and workarounds to ensure that their servers continued to block non-existent domains. This created many hours of work (sometimes days) and much money spent by companies.

In the end, the load on SMTP servers continued to increase causing delays in legit E-Mail. This means you may have problems trying to contact your friends, family, businesses, co-workers, etc as administrators devote their time to fighting these major changes rather then maintaining their servers.

DNS Server Issues

While you, the end user may not have to deal directly with the operation of DNS, it is important to understand just what kind of changes are taking place due to what has happened with the introduction of the wildcard records.

First, some providers may decide to try and keep their users from seeing the SiteFinder service. This means you may not have to ever bother with it. Patches to the popular BIND DNS server (in use by almost everyone on the Internet) made this much easier for administrators to implement. Unfortunately, this requires changes to all of the DNS servers at a provider/company and can take several days to properly implement and test. Consider yourself very lucky if your ISP did this for you, as most have not taken the time or effort to do this.

Second, DNS does what is known as caching of the information your system may request. For example, if you want to visit www.sosdg.org, a request is sent from your computer to your providers DNS servers, which then gets passed over to the DNS servers which manage sosdg.org. The information is then stored on your ISPs DNS servers for a limited time (a few hours usually). This helps speed up your Internet access and keep traffic on the Internet down. It also helps groups like us from being overloaded from many users visiting our site in a short period.

With the new wildcard records, your ISP must now accept and cache each and every mistake you might type into your browser, rather then just caching the 'negative response' if the domain does not exist. This causes your ISPs DNS servers to use more memory and CPU resources, and slows down DNS lookups in general, making the Internet feel much slower then it really is.

Technical Support Issues

One of the unexpected side affects of the SiteFinder service is the increase of Tech Support calls to the Help Desk of ISPs and companies.

Because of implementation issues on the Verisign end, during the first week SiteFinder was active, the SiteFinder servers were either down or unavailable. This caused confusing errors on users computers as they tried to connect to the SiteFinder servers but were unable to. Many companies were left fielding many more calls then they normally would expect to handle.

When a customer forgets to pay their domain name bills, the domain name goes on a suspended list and is removed from the master DNS servers. Unfortunately, with the introduction of the wildcard, the domains no longer stop resolving, but rather point to Verisign's servers. This means all traffic destined for the customer's domain name is sent to Versign - web traffic, E-Mail, etc instead. This leads to problems as providers and support desks try to solve the cause of the customers real problem.

In short, it creates a nightmare for the people who help you keep your service running smoothly.

Internal Network Issues

The wildcard doesn't only affect the Internet. Your company may begin to have unusual problems with their internal network which connects you to services like printers and file servers.

A common setup on Windows servers is to use NetBIOS name services to help you locate other machines on your network. Windows works by first taking the name you give it of the service or computer and passes it to DNS. If the DNS server can not locate the service or computer itself, it would give back an error. Windows would then resort to WINS or NetBIOS name services to find the computer or service you are looking for. Unfortunately, with the wildcard record in place, DNS no longer fails, but instead directs your computer to look for the services or computer in question at Verisign! Not only does this keep you from accessing your printers, file servers, and computers, but it sends possibly sensitive data to Verisign.

There has been documented cases on the Internet and in the news where companies suddenly were unable to print on their whole network, or were unable to even login to their workstations! This required many companies to hire extra support to help solve the issue.

Conclusion

While Verisign has been on a campaign recently to prove to the Internet Community that the SiteFinder service is valuable, the truth of the matter is that the service is unwanted, unexpected, and causes even more confusion for end users.

This document was written in the hopes that it may help people better understand the real issues on hand about what was done to the Internet's basic structure.

legacy/2003/sitefinder1.txt · Last modified: 2014/04/12 11:13 by brielle