Virtual domain hosting with Linux

Internet service providers (ISPs) have discovered an additional, quite lucrative revenue stream to providing connectivity: hosting "virtual domains." But in fact, hosting a virtual domain is a fairly simple DIY (do it yourself) and usually entails nothing more than configuring a few files.
Posted November 4, 1999

Jay Link

(Page 1 of 2)

sendmail tutorial

Internet service providers (ISPs) have discovered an additional, quite lucrative revenue stream to providing connectivity: hosting "virtual domains." But in fact, hosting a virtual domain is a fairly simple DIY (do it yourself) and usually entails nothing more than configuring a few files.

Here you will learn everything you need to know to set up and host a new virtual domain yourself. You will need:

  • the Linux OS
  • the Sendmail e-mail server
  • BIND (Berkeley Internet Name Domain), including named (pronounced name-dee)
  • the Apache Web server
  • While it is certainly possible to use other server programs such as qmail to accomplish these same goals, I'll limit my discussion to what I have listed above. Not only do these programs have widespread usage, they're what I've chosen to use for my own server.

    What is a virtual domain?

    You've undoubtedly become familiar with the concept of the Internet domain; and are two everyday examples. In fact, you probably typed in a domain name to reach this Web site. But what differentiates a "real" domain with one that's "virtual"?

    In the old days, each individual "dot-com" needed to have its own server, and all domains were "real." This limitation was dictated by HTTP 1.0, the first version of the Web protocol. However, possibilities were expanded with the release of the following version, HTTP 1.1. For the first time, a single computer could host multiple (or virtual) domains.

    Hosting multiple domains on one machine is both convenient and economical. Many Web sites have low enough traffic that they don't require their own dedicated server. Does it not make sense, then, to combine several sites onto one machine? Of course. That's precisely what virtual hosting allows you to do.

    Without any further ado, here's what you need to do to host a virtual domain:

      1) Register your domain
      2) Configure DNS (named)
      3) Configure the Web server (Apache)
      4) Configure the e-mail server (Sendmail)
      5) Provide your customer access to files

    For the purposes of this article, I'm going to pretend I've been hired to host Here's an in-depth look at what I need to do to make it happen.

    Domain registration

    The first step in hosting a domain, real or virtual, is to register it with InterNIC, or rather Network Solutions, or another company authorized as a registrar (for a list, see here). The cost is $70.00 for the first two years and then $35.00 per each following year.

    In addition to the .com, .net, and .org "top-level" domains, there are individual country-coded domains such as .uk. If you need to use one of these, you'll find a list of every available country code and their respective contact information at the IANA (Internet Assigned Numbers Authority).

    Regardless of what top-level domain you decide to put your domain under, you'll need to provide the registrars with the IP addresses of the machines that will be handling DNS lookups for your new domain.

    If the domain you'll be hosting isn't new (i.e., if it's a transfer from another hosting company), you'll need to submit the transfer request in much the same way as you'd request a new domain. Fortunately, transfers are free.


    DNS, or the Domain Name System, matches domain names (such as with IP addresses ( This process is managed in part by InterNIC, which maintains the gigantic database of .com, .net, and .org domains.

    If you type "whois" (without quotes) on the command line, you'll see the information that InterNIC maintains on (Being a smart person, you can probably extrapolate that you can get the registry information on any .com, .net, or .org domain by typing "whois <domain>"). In addition to the contact info, there's a small section on the bottom that states:

       Domain servers in listed order:

    This is what we care about! It states that DNS requests for should be directed to (, and, failing that, should be redirected instead to (, the backup. There could be several backups listed, but the minimum is one, as we have here.

    Now, what happens when gets a DNS request? We can presume that ns5 has a copy of "named" running. Named, which is part of the BIND package, is what handles these requests.

    Named is normally started at boot time. You probably have an entry for it in one of your /etc/rc.d files. Mine is in /etc/rc.d/rc.inet2 and looks like this:

       # Start the NAMED/BIND name server.
       if [ -f ${NET}/named ]; then
          echo -n " named"

    The first thing named needs to do on startup is, like many other daemons, read its configuration file. In this case, it's /etc/named.boot. There's usually a "directory" line that tells named where it can find the DNS files. It looks like this:

       directory /var/named

    This simply states that all the DNS files will be in the /var/named directory. The directory could be /abc/123; it makes no difference as long as that's where the files are.

    Then, there will be an entry for each domain that you host. They look like this:


    This tells named that the DNS file for (assuming I hosted that) is called "", and that we will be the primary host. Again, the file could be called "spaghetti" if you wanted it to be. All that matters is that the actual file name matches up with what you have listed in named.boot.

    Now that we've told named where the DNS files are, let's have a look at the contents of /var/named/

    $ORIGIN com.
    opensourceit   IN    SOA (
                   IN     NS
                   IN     NS
                   IN     MX     0
    www            IN     A
    @              IN     A

    Now, it'd take a book to explain what all this means (and, in fact, several good ones have been written), but you can basically just copy this as a template and exchange your information with what I have here. With that in mind, here's a brief explanation:

    In a DNS file, all names not ending with a period are appended with your domain name. This appending name (your domain name) is called the "origin", and presumably, in this case, it'd be "". We don't want that, so we override it with:

       $ORIGIN com.

    Now the "opensourceit" on the next line will be read as "".

    SOA means "Start of Authority" and basically means that the important stuff starts here. Note that "" is the e-mail address of the domain's administrator; the "@" is replaced with a period as is proper DNS file syntax.

    The "IN NS" lines reflect what we have listed with InterNIC:

       IN     NS
       IN     NS

    "IN NS" stands for INternet Name Server. Then, the "MX" (mail exchange) line tells DNS where to direct e-mail. The 0 means that is the primary mail server; a low number has a higher priority.

       IN     MX     0
    Finally, we change the $ORIGIN variable to be the full domain name, and we say that is the same thing as plain ol' The IP numbers are the right ones for
       www            IN     A
       @              IN     A
    Many people find DNS confusing but it generally suffices to swap the names you need with those found in a template like I have here.

    Once you've added your "primary" line to named.boot and created, you'll need to restart named by sending it a SIGHUP: kill -HUP <process number of named>. For instance, if "ps -ax" told you that named was process 76:

       76  ?  S    0:16 /usr/sbin/named
    you'd type:
       kill -HUP 76
    Alternately, you could wait until you're done with everything and then restart your server.

    A cautionary tale: When I first attempted to get named going on my own machines, I had a heck of a time. I wanted to transfer DNS control from my upstream provider but nothing I did seemed to work. No matter how I configured my files (and everyone tells you differently), it never got going correctly. Finally, close to desperation, I realized my fault: I had a bad binary! After a quick upgrade of named, I was up and running.

    Web server

    This part is fairly easy. You'll just need to edit your httpd.conf, which on my system is /http/conf/httpd.conf. At the end, there's a place to put virtual domain entries. Here's what they look like:
    #DocumentRoot /www/docs/
    #ServerAlias domain.tld *.domain.tld
    #ErrorLog logs/
    #TransferLog logs/
    So, in this case, here's how your entry might look:
    DocumentRoot /home/openuser
    DirectoryIndex index.html
    ServerAlias *
    ErrorLog logs/error_log
    TransferLog logs/access_log
    Starting from the top, we have the IP address of the hosting machine (same as before, with DNS) located within the VirtualHost brackets. This is followed by the admin's e-mail address, ServerAdmin. Then, there's the DocumentRoot, the directory where the actual Web pages can be found. I've specified this as the /home/openuser directory, but once again, this is entirely arbitrary. Do whatever meets your needs.

    Next, the DirectoryIndex is the first Web page brought up when someone visits the site. I've chosen "index.html" (as is standard), but it could be anything. Do be sure that this page actually exists, though, even if it's blank. Otherwise, you'll get an error when you restart Apache. Then there's the ServerName ( and ServerAlias lines. These may take a little explaining.

    Page 1 of 2

    1 2
    Next Page

    0 Comments (click to add your comment)
    Comment and Contribute


    (Maximum characters: 1200). You have characters left.