Have you ever registered a new Web domain, been eager to set up a new Web server, and found that you're stuck until the new domain name registers with all the DNS servers? Ever wished you could give a machine on your network a name besides its IP address without having to maintain your own local DNS server? You might want to consider the hosts file.
When we need to contact another computer on the Internet, we usually rely on a DNS server to look up the host's IP address. DNS has worked pretty well for decades, but the system has a few issues, as I noted above, that make it occasionally frustrating. Those delays and lags can have some unfortunate side effects.
Consider, for instance, managing systems you don't have physical access to. If you bring up a new domain but your own ISP's name servers don't know about it yet, you're effectively locked out of your new server until your ISP's DNS servers do figure it out and start answering DNS requests correctly. That's no good if you're hoping to have something more than a "this site coming soon" splash page greeting your first visitors, or if you need to move files onto the new server.
Here's another scenario:
If you've ever moved a network service from one host to another you've had to deal with a lag though not as long as registering a new domain as name servers register the change. That can result in two different hosts responding to requests, depending on whether the requester's DNS server has caught wind of the change yet.
Those are both instances where the hosts file can help you out by making sure your computer is pointed to the correct host in the interim between making a change to your domain or registering a new one.
In a nutshell, even though computers generally depend on DNS servers for address lookups, operating systems offer an override in the form of the hosts file. You can specify the IP address for a given host name in your computer's hosts file, and that address overrides any information coming back (or failing to come back) from a DNS server.
The hosts file is located in a few different places depending on your operating system. On most Unix and Linux systems -- including Mac OS X you'll find it in the /etc directory. On Windows systems, it varies:
|NT/2000/XP Pro/Server 2003/Vista||c:winntsystem32driversetchosts|
|Windows XP Home||c:windowssystem32driversetchosts|
In each case, the format of the file is the same. Here's a sample:
# My Sample Hosts File 192.168.1.3 ghola # local Samba server 188.8.131.52 practicallynetworked.com www.practicallynetworked.com pracnet.com
The first line, which leads with a hash -- # -- character, is a comment. A hash character causes the computer to stop reading a given line.
The second line shows a way to name a machine on a local subnet. In this case, if you try to use any network service with "ghola," your computer will know that you're talking about the machine at the IP address 192.168.1.3. You also see another way to use the comment character: To insert a note at the end of a line. In this case, we're just reminding our selves that ghola is our Samba server.
The third line shows one more way to make an entry, by providing an IP address, a hostname, and an alternate hostname. Note that if you're dealing with a domain that has a number of subdomains you'll need to include subdomains like "www," "ftp" or "dev," for instance. The hosts file is pretty literal in that regard, because "www.somedomain.com" could easily be on a different IP address from "dev.somedomain.com" or plain old "somedomain.com."
Earlier, I outlined two ways you could use a modified hosts file when you bring up a new host or when you move services between hosts at different IP addresses. There are at least two other scenarios where a modified hosts file might come in handy:
- Naming machines on your local network for easier access in the absence of a local nameserver.
- Testing on a development server before moving your changes to a production server.
In each case, all you need to do is identify the IP address you want requests to go to and add it to your hosts file using the formats in the example above. Windows and most Unix/Linux systems will recognize the change immediately. Depending on the version of OS X you're running, you may find that you need to flush your system's lookup cache from the command line:
sudo lookupd -flushcache
That makes sure lookupd, the OS X DNS daemon, doesn't try to use the last IP address it retrieved from a nameserver instead of your new one.Caveats
With power comes responsibility. The hosts file can make your life easier by providing a temporary correction while you're waiting around for host names to propagate, but it's not the sort of thing you want to lean on too much. I generally make changes to my host file temporary, removing them once I no longer need them. That wasn't always my practice. It took a few instances of scratching my head because I couldn't figure why none of my changes were turning up on a Web server to convince me of the value of keeping hosts pruned: My hosting provider had changed the IP address of the server on me, but I still had entries from my hosts file from when I first registered the hostname.
Also, even though the hosts file is great for letting you name machines on your local network, it's not something you want to rely on if your network involves more than a few clients. Having host entries for a single-client network with a few servers is fine. When you start adding clients you start adding potential headaches by forcing you to keep your hosts files in sync whenever you make a change.
Finally, the hosts file doesn't work for networks where the machines get their addresses from a DHCP server. Assigning a static IP to the host "kitty," for instance, could end up causing you to visit "fido" if those hosts renew their leases and get a new IP address in the process.
If you're considering growing your network beyond a client or two and a collection of servers, or adding a DHCP server, you'll need to move on up to a more sophisticated solution. For Linux users, a great choice is dnsmasq, a small DNS server that understands how to handle DHCP, caches DNS lookups locally to speed up the name resolution phase of a network transaction, and even knows to use the (carefully pruned) hosts file on its home server to assign names for local lookups. I could promise a dnsmasq tutorial for sometime in the near future, but there's no point: Enterprise Networking Planet has a great dnsmasq tutorial that'll get you on your way.
|Do you have a comment or question about this article or other small business topics in general? Speak out in the SmallBusinessComputing.com Forums. Join the discussion today!|