Several interesting user trends have likely caused administrators some heartburn (or at least some extra work) over the past year. One such user-driven trend centered around the .org (and other) suffix used in organizations’ domain names. In February 2000, several well-established organizations started experiencing what I call the dot-com trend—suddenly, every URL had to end with .com. This trend occurred because users were trying to use a URL ending with .com rather than .org. When they couldn’t access these organizations’ Web sites, they started complaining. Although the organizations weren’t pleased about having to buy additional domain names, the only alternative was to handle a lot of complaints and lose visitors. The October 2000 user logs for one major organization I hosted showed that 85 percent of all users used the .com ending on the domain name to access the Web site. The organization has never published the domain name with a .com ending. I discovered that only referrers, such as search engines, are using the .org version of the domain name.

The latest user trend is to forget about the www part of a URL when surfing the Web. Business domains, especially areas such as support, commonly don’t use the www prefix in their URLs (e.g., http://support.microsoft.com). For most nontechnical users, shorter is better, so they’re accessing public and private domains on the Internet without the www in their URLs.

After the rush earlier this year to purchase and define all those .com names, I was feeling rather smug back in October when I began the task of defining new host headers for every domain in my server—without the www. I figured that I would be able to spare my customers being plagued by users complaining that they couldn’t access a site without the www. Before I was halfway through creating the new host headers for the domains, I received an email message from one of my hosting customers. In the message, she forwarded a note from someone trying to visit her online store. The user was trying to access the site by typing a URL without the www in front of the domain name. I asked my customer why she thought that the URL should work. After she looked at the domain name again, she responded that it had just "looked right." She was right: She didn’t buy the www when she bought her domain name.

The Solution: Use Host Headers to Reuse an IP Address
Last year, when I wrote about setting up host headers on IIS, it was news. (See "How to Build a Web Development Environment," November 1999, and "Using Host Headers to Set Up a Multihomed Server," October 1999.) Today, hosting companies commonly use host headers to address most domains that don’t require a dedicated IP address (Secure Sockets Layer—SSL—sites are examples of sites that do require a dedicated IP address).

Before host headers, each domain name required a unique IP:Port combination. Port 80 is the default and is the only port that DNS uses. So, before host headers, clients that wanted to use more than one domain name to get to their site needed to have more than one IP address.

Using host headers, you can reuse the same IP address for many different domains. For example: I can use the same IP address and port number for www.myweb.com, myweb.com, and www.somebodyelsesweb.com. Both the www.myweb.com and myweb.com domains would be defined in the same virtual server and would take the user to the same home page. The other host header can use the same IP and port, but it could be defined in a different virtual server and take the user to a different home page. The specification is that one of the three elements (i.e., the host header name, the IP address, or the port number) must be unique. Using host headers to add several different domain names to one Web site is easy. You add the names on the Advanced Multiple Web Site Configuration dialog box, which Figure 1 shows. To access this dialog box, open the Microsoft Management Console (MMC) Internet Information Services snap-in, right-click the virtual Web server you’re interested in, and select Properties. On the Properties dialog box, click the Web Site tab, then click Advanced.

As always with host headers, the caveat is that if users try to access a domain for which a DNS entry exists but you’ve defined no host header matching the URL they’re using for the IP address, then IIS presents the user with either the home page of the root domain defined on that IP address or an error message, depending on the file requested. The root domain is the one domain that has a definition that uses only the IP address and port 80 with no host header. ISPs usually define their home page as the root domain on all IP addresses in the machine, so users end up somewhere they didn’t expect—but at least they don’t receive an error message.