Using Host Headers to Set Up a Multihomed Server

To get the most out of your Web servers, you want to pack as many Web sites as possible on each server. Multihoming lets a Web server support multiple Web domains, each with multiple Web sites. Before HTTP 1.1, multihoming required multiple IP addresses (one for each Web domain) and possibly multiple network cards; this solution isn't cost-effective. However, the requirements changed when HTTP 1.1 introduced host headers, a new element for identifying Web sites. Microsoft added support for host header identification in IIS 4.0. Host headers let you define multiple Web domains on one IP address and, therefore, cut costs and increase your server farm's productivity many times. This article explains what host headers are and how to set them up for an Internet production server. (This article assumes that you have contracted with an ISP to co-host your server and provide you with IP addresses and primary DNS services; this ISP will give you assistance in registering your domain names.)

Web Server Identification
You can host multiple domain names on one computer running IIS by using virtual servers. Each virtual server can host one or more Web sites. Each virtual Web server must have a unique identity so that the network can send traffic to it.

HTTP 1.0 defined a virtual server's unique identity with an IP address and a port number. Because DNS doesn't use port numbers—on the Internet, each virtual server must have its own IP address in this scheme—this approach quickly uses many IP addresses. HTTP 1.1 adds a third element, a host header that the Web server processes, to distinguish between different domains sharing the same IP address. Thus, the IIS 4.0/HTTP 1.1 specification defines three parts to a Web server's identity: the IP address, the port number, and the host header. Several servers can share two parts of the address, but the third part must be unique to a particular server.

Several servers can run on the same machine on the same IP address. For example, HTTP and FTP servers often share an IP address for a specific domain, but they each have a unique dedicated port on the IP address that they use to communicate. By default, the Web server uses port 80 and the FTP server uses port 21.

Defining multiple Web domains on one IP and having each Web domain listen on a different port is IP overloading. Developers commonly use this tactic to define multiple virtual Web servers on a development server with only one IP address and to redirect Web traffic to a Web-based application on the server. Any user trying to access a site defined for IP overloading must specify the full IP address followed by a colon and the port number. The problem with using this approach on the Internet is that DNS doesn't specify port numbers for the domain's IP addresses; it relies on the Web server to use default port 80. So, a Web domain defined with a port different from 80 doesn't appear in any DNS listing. This DNS attribute explains why you had to dedicate one IP address to each Web domain before HTTP 1.1 and IIS 4.0 and why you use host headers instead of different ports for multihoming.

The host header is the domain name that a user requests in the browser's location field. Beginning in HTTP 1.1, the HTTP Request Header contains a field that stores the host header. The browser puts the domain name portion of the URL into the Host Header field in the Request Header when it requests a page from the HTTP (Web) server. The Request Header is a data structure that the browser sends with the request for a URL, and it contains information about the browser and the requested URL. (For more information about HTTP Request Headers, see http://www.w3.org, HTTP 1.1 Request Headers.) For example, if the user types http://www.testersparadise.com into the browser's location field and presses Enter, the browser writes the host header www.testersparadise.com (without the http://) in the Host Header field of the HTTP Request Header.

DNS looks up the domain name and maps it to its IP address as usual, but when the request reaches the root or primary domain Web server listening on port 80 at that IP address, the Web server queries the Host Header field. The Web server routes the request to the specific virtual server running on the machine using that host header and IP address. In this example, the host header domains—www.testersparadise.com, www.ahsr.com, and www.eqeq.com—are all mapped to the same IP address in DNS. The primary or root domain is www.testersparadise.com. Each domain has one or more host headers, but they all share the same IP address.

Host Headers Aren't Perfect
Routing problems can arise if the virtual server requested is stopped or if the page request comes from an earlier (pre-HTTP 1.1) browser that doesn't have the Host Header field in its Request Header. In either case, the Web server sends the request to the primary or root Web server at the IP address, and the user gets the primary domain's home page. Host headers can fail—one of the major reasons that host headers aren't more widely in use today. If you don't manage the failure properly, the failed Web domain is essentially unreachable, which creates a big problem.

The documentation that ships with IIS 4.0 offers a programmatic solution for detecting and redirecting traffic from earlier browsers to the correct server directory structure. Rather than invest in coding, my company chose to use a simpler HTML-based solution that reduces administrative time, leverages additional advertising for hosted sites, and makes Web development, backup, and restore functions much faster and safer.

If you structure your directories on the hard disk, as Figure 1 shows, the primary domain directories will be at the root of a directory structure on the drive (e.g., F:testersparadise). You can structure your physical directories so that all the host header domains that share an IP address are subdirectories of the primary domain on the hard disk. This structure takes advantage of the virtual server inheritance property that automatically includes root subdirectories in the Web domain. This inheritance lets you address the subdirectories both as domains and as sub-Webs (e.g., in Figure 1, F:testersparadiseeqeq is mapped to both www.eqeq.com (domain) and www.testersparadise.com/ eqeq (sub-Web) on the Web server). The testersparadise home page has a hyperlink to www.eqeq.com, but the anchor in the hyperlink references www.testersparadise.com/eqeq; for example,

eqeq

This navigation will succeed even if the www.eqeq.com Web site is stopped because it references eqeq.com as a sub-Web of testersparadise. Another benefit of this approach is that it's easy to back up and restore the entire IP family of domains and their sub-Webs because they are all in one directory structure. For clarity, you can name the physical directories in accordance with the domain's main name. Therefore, the home directory of www.eqeq.com would be eqeq. This naming convention makes it possible for technical support to locate the home directory of any domain.

Many Internet hosting providers have been slow to adopt host headers because of fears that downlevel browsers might be unable to access the URL directly. However, about 90 percent of my company's Web traffic uses Microsoft Internet Explorer (IE) 4.0 or later, and although a few users have complained about the download speed of the Java used in the Microsoft FrontPage navigation buttons, no user has reported being unable to access a Web site. Nor have any users complained about following a hyperlink on another Web site to get to their final destination. Undoubtedly, large sites draw traffic from pre-HTTP 1.1 browsers, but most domestic ISPs and hosting services can benefit from host headers if they manage the rerouting of requests from earlier browsers.

Even with the directory structure solution in place, however, host headers aren't appropriate for all sites. Applications that require Secure Sockets Layer (SSL), PPTP, and encryption require dedicated IP addresses. Domains that use many database applications or handle a lot of traffic also require dedicated IP addresses. So, when a company starts writing database-driven, mission-critical applications, put them on a Web server where they're shielded from other clients and vice versa.

How to Set up Host Headers
To set up host headers, you need to set up your IP addresses, define and configure virtual Web servers, and then configure the host headers. Follow these steps.

Define multiple static IP addresses in your server. Before you define IP addresses, you need to acquire a block of IP addresses to use. In my company, I put about 20 domains and 40 to 60 Web sites on five or six IP addresses. I reserve one IP address on the primary machine address just to administer the server.

You're now ready to add the IP addresses to your machine's network configuration. Open the Control Panel Network applet. The Identification tab displays your computer's name and its network domain. Go to the Protocols tab, and select TCP/IP Protocol. Click Properties to display the Microsoft TCP/IP Properties window. The IP address on this page is the primary address for this machine. To add more IP addresses, click Advanced.

On the Advanced IP Addressing page you see in Screen 1, click Add. In the TCP/IP Address window that appears, enter an IP address and its subnet mask, and click Add. The IP addresses you add don't need to be sequential, but each IP address must have an entry under Subnet Mask. Also, make sure that you add each gateway you need to service the IP addresses. A group of IP addresses can share the same gateway; you need only one entry in this case. The Enable Security check box contains a check by default, and usually you'll want to keep it. Without security, your server is vulnerable to intruders. This check box can confuse people because they mistake this security for SSL and become uncertain whether they need to accept the default. The check indicates that you want Windows NT to provide the usual security on the IP addresses. After you enter the IP information, click OK twice to generate new bindings and restart NT.

Define and configure your virtual Web servers. Open the IIS 4.0 Microsoft Management Console (MMC). Right-click the machine name, and select New, Web Server. This action launches the Web Site Wizard and creates your domain's virtual Web server.

Follow the prompts in the wizard. First, give your site a friendly name (e.g., testersparadise). Click Next. All Unassigned is the default in Select the IP Address to use for this Web Site because, by default, Web servers listen on port 80 of all unassigned IPs in a machine. Click the drop-down arrow, and select the IP address for this primary domain. The wizard automatically selects port 80 after you select the primary IP address.

At the wizard's prompt, select the root directory of your new IP Virtual Server Root Domain. In this example, the root directory is F:testersparadise. The default access permissions are Allow Read Access and Allow Script

Access. If you're building an Active Server Pages (ASP) site, also select Allow Execute Access. After you've completed the steps in the wizard, the wizard creates the site in stopped mode. You must start the site before it can serve documents. This site is the primary domain because you've defined it with a specific IP address on port 80 and it has no host header.

Configure host headers. To add another identity for this Web site that includes a host header, right-click the site and select Properties. The Web Site tab shows the Web Site Identification for the new domain. This identification includes the IP address that you selected in the wizard. Click Advanced to display the Advanced Multiple Web Site Configuration window, which Screen 2 shows. Click Add, and define a second identity for the primary domain (on the same IP address) that includes a host header. The server identity now includes your host header entry (i.e., www.testersparadise.com). Click OK to add the new identity.

Screen 3 shows the Advanced Multiple Web Site Configuration page with the primary Web site and the host header Web site defined. Click OK on Advanced Multiple Web Site Identification and Configuration, click Apply on the Website Properties window, and click OK on the Website Properties window to close it. Now, the Web site is listening on port 80 for both the IP address and the host header www.testersparadise.com. The second definition isn't necessary for the site to work correctly; the primary domain responds because it's the only one without a host header. But, the mapping clearly shows the relationship of the Web sites. You can recognize the primary domain because it has no host header and it's the only one listening on port 80 of the IP address.

In the MMC, click Start to start the new virtual Web server. To add your first host header domain to this primary IP domain, right-click the new testersparadise domain and select New, Site. This option creates a new virtual Web server. What MMC calls a site becomes a domain when you assign a specific IP address (and, optionally, a host header) to it. Following the steps in the wizard, create the www.eqeq.com domain using the F:testersparadiseeqeq subdirectory and the same IP address as the primary domain. When you've finished creating the new site, right-click it and select Advanced. Select Edit in the Advanced Multiple Website Configuration. Add the host header www.eqeq.com to the IP identity for this Web domain, and click OK.

Users can access the home page of www.eqeq.com via http://www.eqeq.com (after you set up a DNS entry for the domain) and via http://www.testersparadise.com/eqeq. If the host header fails because the browser doesn't support it or the site is stopped, the requesting browser will present the primary domain (i.e., testersparadise) home page. Users can then click the www.testersparadise.com/eqeq hyperlink on the testersparadise home page to access eqeq. If you add more Web sites to the directory structure under the primary domain (www.testersparadise.com), those sites can also become host header domains if you define them as sites and give them host header names.

Repeat these steps until you've defined all the virtual servers you need for the IP address. Be sure to start your new sites, or all requests to them will fall through to the primary domain. Now, make the DNS entries (e.g., www.testersparadise.com = 205.174.179.83 and www.eqeq.com = 205.174.179.83). All the host header sites have the same IP address as their primary domain. The Web server (IIS 4.0) routes the Web page requests correctly because the primary virtual server routes each host header request to the appropriate Web site. Test your sites to make sure you have a home page in each site.

Get the Most Out of Your IP Addresses
My small Web site hosting company was quick to test and deploy the host header solution, and it has worked well. I cut the number of IP addresses needed to run a typical multihomed server from 20 to five. For more than a year and a half, I've saved the cost of renting, tracking, and administering at least 90 IP addresses and increased my server farm's revenue-producing capability by a factor of three.

Typically, one of my company's multihomed IIS 4.0 machines packs 40 to 60 FrontPage-based Web sites on a 200MHz Intel processor machine with 128MB of RAM and 6GB to 9GB hard disks, running NT 4.0 with Service Pack 3 (SP3). Most of our domains have sub-Webs (i.e., multiple Web sites), so one computer frequently hosts more than 60 Web sites. The host-header-based virtual servers remain stable and perform well longer than a comparison server running dedicated IP virtual servers.

At first, assigning 40 domains to five or six IP addresses might seem too risky. But my experience has been that most server failures are the result of an application locking up the entire server and, therefore, all IP domains in the machine. So, the risk of having something happen to one site and causing all the other sites on that IP address to become unavailable has never materialized.

Host headers are a cost-effective solution when you need to support many small domains, especially when each small domain needs to have unique permissions. Most of my company's customers are happy with FrontPage and its server-side programs interactivity.