When to Run a DNS Server

Administering a DNS server isn't a trivial undertaking, so it's important to understand thoroughly what you'll get out of doing so. One set of benefits accrues if you run servers on your local network that should be accessible by name to people outside of your local network. Another reason relates to purely local network access. In both cases, there are alternatives you might want to consider.

Running an Externally Accessible DNS Server

The Internet as a whole relies upon an interlinked set of DNS servers. Understanding how this system works is critical to understanding why you might want to run DNS to allow outsiders to reach your systems. Consider as an example a DNS lookup performed in response to a user's Web browsing. The user enters a uniform resource locator (URL), such as http://www.whitehouse.gov. This entry results in various activities on the local computer, which ultimately result in the system contacting the local DNS server to resolve the www.whitehouse.gov hostname ”that is, to convert it into a numeric IP address. The local DNS server begins this process by contacting a root server. This is one of a handful of systems whose addresses are unlikely to change, so the DNS server encodes root server IP addresses in a configuration file. The local DNS server asks the root server for help in resolving the www.whitehouse.gov hostname. The root server is unlikely to know the IP address, but the root server does know the IP addresses of servers that have more information on the top-level domains (TLDs), such as .com , .gov , and .uk . The root server therefore passes the local DNS server the addresses for the .gov servers, and the local DNS server redirects the request to one of these. The .gov DNS server is unlikely to be able to resolve the entire hostname, but it should know the IP addresses of servers responsible for the whitehouse.gov domain, and so passes those addresses back. The local DNS server then asks one of the whitehouse.gov DNS servers for the www.whitehouse.gov address, and the whitehouse.gov server will know this address, and so will return it. The local DNS server can then return this final address to the Web browser, which uses it to request the Web page. This entire process is illustrated in Figure 18.1. Most of these details are hidden from the end user; to a program or person using this system, it appears as if the local DNS server knows the addresses associated with all the systems on the Internet.

Figure 18.1. A single DNS lookup may involve requests being sent to multiple DNS servers in quick succession.

Although this sounds like a roundabout and complicated method of resolving a hostname, the entire process typically only takes a few seconds.

There are also shortcuts that can help make the system even more efficient. For instance, local DNS servers may cache lookup results. Thus, if two users request the same addresses in quick succession, the DNS server won't need to go through the entire process a second time; it can simply return the original value. Also, the cache includes lookups on common domains. For instance, a local name server is almost certain to have the addresses of the .com TLD servers available, so the initial call to the root name server can be skipped . These caches aren't kept around indefinitely, though; they're occasionally flushed, which allows domain administrators to change their systems' IP addresses without causing undue problems.

If you run servers that you want to be accessible to others, it's a practical necessity to tie yourself into this DNS network. Specifically, you must run a DNS server that fills the role of the whitehouse.gov name server in Figure 18.1, but for your own domain. Some practical aspects of doing this are discussed in the upcoming section, "Obtaining a Domain Name." Once your DNS server is configured and running, and once the DNS server for the next -higher-level domain knows about yours, anybody on the Internet will be able to reach your computers by name.

NOTE

The authorities who administer DNS require that every domain have at least two DNS servers. This isn't done because the protocols require it, but for redundancy ”if one DNS server crashes, the other can still resolve hostnames. This requirement can be a problem if your network is particularly small, but you might be able to run your own primary DNS server and use an outside source for the secondary DNS server.

One alternative to running your own DNS servers is to let somebody else do it for you. Many domain registrars (discussed shortly, in the section "Obtaining a Domain Name") and Internet service providers (ISPs) offer DNS hosting services. Sometimes these are free with some other service, such as domain registration. Other times you must pay a small fee (usually a few dollars annually). At least one organization, Granite Canyon (http://www.granitecanyon.com) offers free DNS services ”but remember the adage, "You get what you pay for." In any event, a third party can handle your DNS requirements for the outside world ”either both servers or just one, if you want to host one yourself.

There's a specific type of DNS service that's marketed primarily to home users with digital subscriber line (DSL) or cable modem connections: dynamic DNS. Organizations that offer dynamic DNS services operate a DNS server much like any other, but they allow you to quickly and easily update the DNS records to reflect a changing IP address. Most businesses are better off using an Internet connection that allows for static IP addresses, but dynamic DNS services may be useful for hobbyists who want to run their own servers. A few dynamic DNS providers also offer conventional static DNS services. There are too many dynamic DNS providers to list them all here, but a couple of sites that host lists of dynamic DNS providers are http://www.technopagan.org/dynamic/ and http://www.oth.net/dyndns.html.

Relying on an outside source for your DNS server can make a great deal of sense if you don't want to deal with maintaining one yourself. Because DNS is so important to so many other services, it's a good idea to rely on an experienced outside source of DNS services if you're inexperienced in DNS administration or if your network connection is flaky.

Even if you rely on an outside DNS server, you may want to learn something about DNS configuration. This is because the Web-based configuration forms that are common with DNS providers typically require you to fill out much of the same information you'd enter into local DNS configuration files. Knowing what this information is will help you to configure your domain appropriately even when you don't run the DNS server yourself. The upcoming section, "Domain Administration Options," should be particularly relevant to helping you configure a domain whose name servers are being provided by a DNS hosting service.

Running a Local DNS Server

In addition to providing services to outside systems, a DNS server you run can function as your domain's DNS server ”that is, the computer whose address you enter into /etc/resolv.conf or whose address you specify in a DHCP configuration file as the name server. This has two major advantages over relying upon an outside DNS server:

• You can configure your local systems to rely on your local DNS server for external lookups, thus potentially improving performance, particularly if your ISP's DNS server becomes unreliable or slow. Your local DNS server can maintain its own local cache, which might result in improved performance in some circumstances.

• Your local DNS server can maintain information on your local network, even for local systems that you do not want to make accessible to the outside world. For instance, you might run a local DNS server behind a firewall to allow for easy name resolution within your local network. These systems might not be visible from the outside world, and so would have no external DNS entries.

The second reason is generally more important, although on some networks the first reason may be important, as well. As a general rule, if you run a DNS server to grant outsiders access to your own network, you might as well use that server for internal access, as well. Purely local DNS servers are helpful when you run a network of more than a few computers behind a firewall.

An alternative to running a DNS server for purely local use is to configure the clients to use a name resolution method other than DNS. One common approach is to use the /etc/ hosts file in Linux or other UNIX-like systems. (Non-UNIX systems also often support this mechanism, although the file may be stored in some other location, such as C:\WINDOWS\HOSTS in Windows 9 x /Me.) An /etc/hosts entry consists of an IP address followed by a full hostname and a shorter "nickname." For instance, an entry might look something like this:

 192.168.78.109  gingko.threeroomco.com  gingko 

A typical Linux system includes at least one /etc/hosts entry to define localhost as 127.0.0.1. On a small network, it's usually not too difficult to expand this file to include definitions for all the other local computers. The effort involved on a small network is usually much less than is required to administer a full DNS package. As the number of computers grows, the effort involved in updating all the computers' /etc/hosts files grows much faster than does the effort in administering a centralized DNS server. The /etc/hosts approach is also impractical if your network uses DHCP and dynamic IP addresses (a configuration that's tricky, but not impossible , for a conventional DNS server to handle).