Delivering Names with DNS

A second key network management tool is DNS. DNS servers fill two roles: enabling your local clients to convert names to IP addresses for local and remote computers, and enabling remote systems to find local computers that you choose (such as web or mail servers). One important question is whether you should even run a local DNS server; for many purposes, relying on outside servers makes a lot of sense. Sometimes, though, running a DNS server locally is very helpful. If you decide you want to run your own DNS server, you must be able to configure it. The basic DNS server configuration varies with the server software you select. BIND is the most popular Linux DNS server, and so it’s described in this chapter. Once the basic configuration is set, you must create files that describe the computers on your network—their hostnames, IP addresses, and related characteristics. Finally, you must be able to tell clients to use the DNS servers you’ve configured.

Principles of DNS

DNS is, essentially, a global database of computer names. The huge size of the DNS database presents many challenges, including maintenance of the database and providing storage space for it. Both challenges are overcome by the fact that DNS is a distributed database; no one computer holds all the data in the DNS database. Instead, the DNS namespace is arranged hierarchically. At the top of the hierarchy are the top-level domains (TLDs), which appear at the end of a DNS hostname. Common examples include .com, .edu, and .net. These three TLDs are all examples of generic TLDs (gTLDs), which are (theoretically) not tied to specific nations. Another type of TLD is the country code TLD (ccTLD), which uses a two-digit country code as the TLD, such as .us for the United States or .ru for Russia.

Below the TLDs are the domain names that are so common, such as http://oreilly.com for O’Reilly Media or http://upenn.edu for the University of Pennsylvania. These domains can be further subdivided, such as http://cis.upenn.edu for the Computer and Information Science department at the University of Pennsylvania. At some point, individual computers can be specified, as in http://www.oreilly.com for the O’Reilly web server.

The beauty of DNS’s distributed nature is that it ties into this hierarchy. At each level of the hierarchy, a single DNS server can reasonably hold data on all the domains or subdomains at that level. At the very top of this hierarchy, a set of computers known as the root servers maintain information on the TLDs. Each root server can field queries concerning TLDs; most importantly, the root servers can tell a client where to find DNS servers for the .com, .ru, and other TLDs. The client can then contact a TLD’s DNS server for information on a specific domain, such as http://oreilly.com; the result is the address of the http://oreilly.com DNS servers. With this information in hand, the client can ask about a specific computer, such as http://www.oreilly.com.

The distributed DNS system therefore enables lookups in a huge address space relatively quickly. Although multiple queries may be needed, each one finishes rather rapidly. DNS also includes certain time-saving features. For instance, rather than have users’ workstations perform the full recursive lookup , in which a name is queried starting with the root servers, a network can host a DNS server that does this job and caches the results. Thus, if two users on a network look up http://www.oreilly.com in quick succession, the local DNS server needn’t perform a full recursive lookup for the second query; it simply retrieves the result of the original lookup from its cache and delivers that result. This characteristic is also a key to understanding the two main roles that a DNS server can play on your network:

The DNS server can perform full recursive lookups for the benefit of your local computers, and also deliver information on local computers to other local computers. Running a DNS server this way doesn’t require modifying your domain’s registration with the outside world.
The DNS server can hold information on your local network and deliver that information when queried by remote systems. This capability is extremely important for delivering the IP address of your externally accessible servers, such as your mail server. Although this chapter can help get you started running your own DNS server, you must consult your domain registrar to link your server to the global DNS system.

This chapter focuses on the first type of DNS configuration—that which is most useful to local computers. The principles described here also form the foundation for making changes that are accessible to the outside world, though.

Tip

You can assign one DNS server to be used by local computers and another for use by outside systems. In fact, you don’t need to run both servers yourself. For instance, you might run your own local DNS server to help your computers perform DNS lookups, but rely on a domain registrar or a domain hosting provider to run DNS servers that hold information on your domain for the outside world.

Running a DNS server for the benefit of your local computers is most useful if your ISP doesn’t provide one or if you want to deliver information that’s unique to your private network. For instance, you might have a subnet behind a firewall that holds file servers, print servers, and pull mail servers to be used by other computers behind the firewall. Entering information on these systems in a globally accessible DNS server is unnecessary and can even give potential attackers information about your network, so running a DNS server behind the firewall can be a good way to provide local name resolution. This server can also handle full recursive lookups for the benefit of other local computers.

Tip

An alternative to DNS for local name resolution is to configure an NBNS system. Windows clients often use an NBNS system automatically if the DHCP server is configured to deliver the NBNS address, as described earlier in Section 15.1.4.1. You can also configure Linux systems to use NBNS, as described in Chapter 6. NBNS has certain advantages, such as simpler adaptation to dynamic IP addresses, but it’s also got limitations, such as a lack of support for DNS domain information.

Basic Name Server Configuration

Running a name server involves two basic configuration tasks: setting up the name server itself (that is, the options it uses to control where it stores additional configuration files, how it should respond, and so on) and setting up the domains it handles. This section describes the first of these tasks, using the BIND software as an example. (If you use another server, such as djbdns, you need to read its documentation.) The second task is described in the next section.

The Berkeley Internet Name Domain (BIND) is distributed by the ISC (http://www.isc.org), which also distributes the most common Linux DHCP server. As with ISC’s DHCP server, BIND is available with all major distributions, except for some very desktop-oriented ones; thus, you shouldn’t need to download it from the ISC web site unless you have a specific reason to avoid your distribution’s BIND package. Typically, the package name is bind.

Although the official name for this server package is BIND, the executable filename is named , and BIND configuration files are named after this—namely, the main configuration file is /etc/named.conf . For a simple configuration, this file contains two broad classes of entries:

Global options appear in a section called options. These include features such as a directory in which domain definitions exist, on what network interfaces the server should listen, and so on.
Each domain or subdomain (that is, a zone) is briefly described in a zone section. This section sets only the broad outlines for a zone; the description of the zone’s computers appears in zone configuration files, as described in the next section.

Example 15-2 shows a simple but usable /etc/named.conf file. This file defines the basic settings for a BIND server handling the http://example.com domain. It includes an options section and four zone sections, which are described in more detail shortly. A DNS server for a network with multiple subnets or domains is likely to have additional zone sections.

Example 15-2. Sample /etc/named.conf file

options {
   directory "/var/named";
   listen-on{
      192.168.1.1;
      172.24.21.1;
   };
   forwarders {
      10.29.102.7;
      10.65.201.7;
   };
   forward first;
};
zone "." {
   type hint;
   file "named.ca";
};
zone "example.com" {
   type master;
   file "named.example.com";
};
zone "1.168.192.in-addr.arpa"{
   type master;
   file "named.192.168.1";
};
zone "0.0.127.in-addr.arpa"{
   type master;
   file "named.local";
};

The general format of the /etc/named.conf file is similar to that of the ISC DHCP server. Most lines set individual options and end in semicolons (;). Other lines, though, begin or end blocks of options. The line that begins such a block ends in an open curly brace ({), and the line ending such a block ends in a close curly brace and a semicolon (};).

The options section in Example 15-2 sets several important global features of the server:

directory: This may be the most important line in the options section; it sets the name of the directory in which BIND looks for zone definition files—that is, the files that define the mappings of hostnames to IP addresses and related domain features.
listen-on: This optional subsection specifies one or more IP addresses on which BIND listens for queries. This feature can be handy if you run the server on a computer with multiple network interfaces but want to make the server available on only some of them.
forwarders: This subsection is optional. If you use it, you can specify the IP addresses of one or more DNS servers that you want to handle DNS queries other than those for which your own server is the ultimate authority. Typically, you use this feature if your ISP offers DNS servers of its own. You can point BIND to your ISP’s servers using this directive and, rather than perform a full recursive lookup itself, your server queries your ISP’s servers and lets them perform the full recursive lookup. This can result in faster responses if your ISP’s servers are working correctly, because they probably have better Internet connections than your own server. This option has no effect on lookups within your own domains (such as http://example.com in this example).
forward: The forward option tells BIND when to use the DNS servers specified with the forwarders directive. The forward option takes either of two values: only or first. The forward only directive tells BIND to use the servers listed in the forwarders section and its own zone files exclusively; BIND doesn’t perform its own recursive lookup. The forward first directive, by contrast, tells BIND to attempt to use the servers specified by forwarders but to perform a full recursive lookup if those servers are unavailable. This option can improve reliability, but it can also slow the return of a failure code.

Many other directives can be placed within the options section, but the ones described here should be enough for many small configurations. Consult the documentation that came with BIND, or a book on the server, such as O’Reilly’s DNS and BIND, for more information on these options.

If you want BIND to deliver information on your local network, the zone definitions are just as important as the options section. Each zone definition begins with the zone keyword followed by the name of the zone. Chances are your named.conf file will have three broad classes of zone definitions:

The root zone: The zone "." entry in Example 15-2 defines the root zone, which ultimately points BIND to the root DNS servers. This definition uses a type hint line, which is unique to the root zone definition.
Forward lookup zones: The only forward lookup zone in Example 15-2 is for the http://example.com domain. This type of entry specifies the domain or subdomain name as the zone name, and enables clients to pass a hostname to get an IP address. On the domain’s primary DNS server, this zone will have a type master line in the zone definition. (Slave DNS servers can copy zone files from another DNS server and use a type slave definition; however, slave DNS server configuration is beyond the scope of this book.)
Reverse lookup zones: Frequently, DNS servers include zone definitions for reverse lookups, in which a client enters an IP address and receives back a hostname. Reverse lookups work much like forward lookups, but they require an unusual notation for the zone type. Specifically, reverse lookups use hostnames of the form backwards-IP-address.in-addr.arpa, where backwards-IP-address is an IP address fragment in reverse. For instance, Example 15-2 has two reverse lookup zones, named 1.168.192.in-addr.arpa and 0.0.127.in-addr.arpa. These correspond to the 192.168.1.0/24 and 127.0.0.0/24 network blocks, respectively—note that the order of the four bytes of the IP addresses are reversed. In both cases, the first byte of the reversed address (the final byte of the original) is omitted, which denotes the fact that these zones apply to networks with 255.255.255.0 netmasks. The reverse ordering of these names is confusing at first, but the reason is that the most- and least-significant portions of IP addresses and hostnames are reversed. A reverse lookup converts an IP address to a hostname in the special in-addr.arpa domain. However, to define the individual hosts in this domain, the machine identifier portion (that is, the final byte of the address in a /24 netblock) must be the first part of the name in the in-addr.arpa domain, so the order of the IP address elements must be reversed. Example 15-2 defines two reverse lookup zones, one for the loopback address (127.0.0.0/24) and the other for the local network address (192.168.1.0/24).

Tip

It’s possible to omit a reverse lookup zone. In fact, if your DNS server will be serving names for IP addresses on the Internet as a whole and you don’t control the entire netblock, you should omit the reverse lookup zone. You’re responsible for handling forward lookups on your domain, but whoever controls the netblock (usually an ISP for small networks) is responsible for the reverse lookup. If you’re configuring a DNS server for a small private network, though, you might want to include both forward and reverse lookups.

Once you’ve configured the basics in /etc/named.conf, you might be tempted to restart the named server. You can do so in the usual way, such as by using a SysV startup script, however, you should probably wait until you’ve created appropriate domain configuration files, as described next.

Setting Up a Domain

Configuring the basics of the server’s options is just the start of the process. In day-to-day operation, you’re more likely to need to modify your zone definitions, which are stored in files in the directory specified with the directory keyword in the options section of the /etc/named.conf file. Each zone has its own configuration file, which defines features of the zone as a whole and creates mappings of hostnames to IP addresses for each member of the zone.

Each type of zone definition in named.conf has its own variant style of zone definition file. The most fundamental of these is the root zone definition. Chances are your BIND configuration includes a default configuration that will work. Typically, the filename is named.ca or db.cache. If this file isn’t present, or if it’s very old, you should try to obtain a more up-to-date version. You can find the latest copy from ftp://ftp.rs.internic.net/domain/db.cache. Copy this file to the directory specified in your named.conf file, and name it as specified by the file option in that file’s root zone definition (zone ".“). Additional zone files are the forward and reverse zone files.

Configuring forward zone files

The second type of zone definition is for forward lookups—those that use an ordinary domain name in the zone line of named.conf. Use whatever filename you specify in named.conf for the file. Typically, this name is related to your domain’s name, such as named.example.com for the http://example.com domain. Example 15-3 shows a sample forward lookup zone configuration file.

Example 15-3. A sample forward zone definition file

$ORIGIN .
$TTL 604800        ; 1 week
example.com    IN SOA  maize.example.com. linnaeus.example.com. (
                       2004102609 ; serial
                       28800      ; refresh (8 hours)
                       14400      ; retry (4 hours)
                       3600000    ; expire (5 weeks 6 days 16 hours)
                       86400      ; minimum TTL (1 day)
                       )
$ORIGIN example.com.
maize          IN A      192.168.1.1
gingko         IN A      192.168.1.2
mandragora     IN A      192.168.1.3
mandrake       IN CNAME  mandragora

mail           IN A      10.23.186.78
www            IN A      172.24.217.102

@              IN NS     maize.example.com.
@              IN MX     10 mail.example.com.

The zone file begins with two lines that set some global parameters. The $ORIGIN . line should be present in your zone files unchanged. The $TTL 604800 line sets a default time-to-live (TTL) value, which tells other servers how long, in seconds, they may cache entries obtained from your server. You may increase or decrease this value as you see fit.

The lines beginning with example.com and ending with a single close parenthesis ")" define the start of authority (SOA) record for this zone. This entry sets several important overall features for the zone:

Zone name: The zone name (example.com in this example) begins the SOA line. You should change it to match your own domain or subdomain name.
Entry class: The IN code defines the class of the entry. IN stands for Internet, and it’s the most common SOA entry class and the only one described in this chapter.
Record type: The SOA code identifies this entry as creating an SOA record.
Master name server: The maize.example.com. entry in the SOA record identifies the zone’s primary name server. Note that this hostname ends in a dot (.). Technically, all DNS hostnames end in a dot. Most user programs enable you to omit this dot, but you must include it when specifying a full hostname in the DNS configuration files.
Administrative email account: The linnaeus.example.com. entry, although it doesn’t look like one, represents an email address for the person responsible for administering the domain. Replace the first dot with an at sign (@; to create linnaeus@example.com.) to generate an email address. As with other addresses, this one must end in a dot.
Timing information: The remaining information, beginning with the open parenthesis on the main SOA line and ending with the close parenthesis line, represents timing information for the data retrieved from this zone. This information is used mainly by other DNS servers. Values are a serial number (often set to the date followed by a code for the change number on the day), the interval for slaves to use between checks for updated information, the interval at which slaves should attempt transfers if the first one failed, the time after which a slave should expire and discard an entire zone if it’s not been updated, and a minimum TTL value for remote DNS servers to cache information. The values shown in Example 15-3 are reasonable starting points. Note that most of these values are important only if you run multiple DNS servers, with one configured as a master and the rest as slaves.

Following the SOA record is a line that explicitly sets the $ORIGIN to your domain, including its trailing dot—example.com. in this case. Subsequent lines are similar in form to the SOA line, but they’re simpler; most take the following form:

                     hostname IN code address

The hostname is the hostname in question, without a domain component. Some entries enable you to specify an at sign (@) as the hostname. This symbol stands in for the domain name and is used by certain code types, as described shortly. The IN component is invariant in these entries, at least as far as described in this chapter. The code is a code that stands for the entry type and is described in more detail shortly. Finally, the address is the address to associate with the hostname. In many cases, this is an IP address; but for some code types, it can be a hostname—either a hostname without a domain, which is interpreted as a hostname in the current domain or a hostname with domain component and trailing dot. The MX code is unique in that it includes a number before the address, as described shortly.

In defining a domain, you’re likely to include several different types of code:

A: An A record defines an individual host in the domain. Use this to associate an IP address with a hostname.
CNAME: A CNAME record sets up an alias—a linkage of one name with another. CNAME records are often used when a single computer goes by multiple names, such as a single system that functions as both a web server and an FTP server, and that you want to be accessible by the names www and ftp for this reason. Alternatively, you can create multiple A records, but doing so requires you to change all the A records if you ever change the server’s IP address; using CNAMEs for most records makes subsequent changes easier and less prone to error.
NS: A name server record identifies a DNS server for the domain. Normally, one NS record points to the computer you’re configuring. Others may point to other DNS servers, such as slaves of a master server. The hostname on this line is either the domain name alone or an @ sign, and the address is the name of an A record—with or without the domain component.
MX: A mail exchanger record points to a domain’s mail server. This record requires a priority number for each server listed; sending mail servers attempt to contact your mail servers in sequence, starting with the one with the lowest number and moving up from there. As with NS records, the hostname is either the domain name alone or an @ sign, and the address is the name of an A record.
PTR: Example 15-3 shows no pointer (PTR) records because they’re unique to reverse lookup zone files. They use a pseudo-hostname based on an IP address as a hostname, and they list a regular hostname as the address. PTRs are described in more detail shortly.

Configuring reverse zone files

In some cases, you need to configure only forward lookups. For instance, your ISP might own your network block and so handle the reverse lookups, or you might simply not care about reverse lookups. (Some programs, though, perform reverse lookups and compare them to the forward lookups. If the two don’t match, the programs terminate the connection or otherwise cause headaches. Thus, working reverse lookups can be more than just a convenience.) If you’re in control of your network block, including if you’re running in a private reserved address space, you can configure a reverse lookup zone. To do so, you must first specify a reverse lookup zone in the /etc/named.conf file, as described earlier, in Section 15.2.2. You can then create a reverse lookup file in your zone file directory. This file is likely to be named after the zone, e.g., named.192.168.1. Example 15-4 shows an example of such a file.

Example 15-4. A sample reverse zone definition file

$TTL 1W
1.168.192.in-addr.arpa.    IN  SOA  maize.example.com.  linnaeus.example.com. (
                                    2004102609 ; serial
                                    28800      ; refresh
                                    14400      ; retry
                                    3600000    ; expire
                                    86400      ; default_ttl
                                    )
1                          IN  PTR  maize.example.com.
2.1.168.192.in-addr.arpa.  IN  PTR  gingko.example.com.
3.1.168.192.in-addr.arpa.  IN  PTR  mandragora.example.com.

1.168.192.in-addr.arpa.    IN  NS   maize.example.com.

The reverse lookup file is very similar to the forward lookup file. Like the forward lookup file, it includes a $TTL directive. (Example 15-4 shows an alternative way of specifying the time, though, by including a one-letter abbreviation for the time unit—1W meaning one week.) This file also contains an SOA record, which takes the same form as the equivalent record in the forward zone definition file; the main difference is in the name of the domain. (You can use different specifics, such as refresh times or network administrator email address if you like, though.)

The bulk of the post-SOA entries in a reverse lookup file are PTR records, which tie an IP address (in the form of its reversed in-addr.arpa pseudo-hostname) to conventional hostnames. As with forward lookup files, you can abbreviate hostnames by omitting the domain portion of the name. In the case of reverse lookup files, though, the domain portion of the name is the reversed network portion of the address and in-addr.arpa. Thus, the reverse lookup for the 192.168.1.1 address in Example 15-4 is 1, referring to the final byte of the IP address. Example 15-4 doesn’t use this convention for the remaining addresses. The looked-up names (maize.example.com., gingko.example.com., and so on in Example 15-4) may not be abbreviated by omitting their domain portions. You must also include the trailing dot after each of these names.

In addition to SOA and PTR records, reverse lookup zone files typically include one or more NS records, which point to the DNS servers that handle the network block. These might or might not be the same servers that handle forward lookups for the computers in that network block. Other record types, such as A, CNAME, and MX, are uncommon in reverse lookup files.

Running the server

Once you’ve set up your domain, you can start the server. Typically, this is done via a SysV startup script; typing /etc/init.d/named start or something similar usually does the job. To run the server permanently, you can use chkconfig or a similar tool to add the server to your default runlevel, or do the job manually by creating appropriate symbolic links yourself. Consult distribution-specific documentation if you need help with this job. Once the server has started, you may want to check the last few lines of your log files to see if the server has reported any problems. Typing tail /var/log/messages can do this.

Warning

If you restart the server, you may get an error message in your logs about the journal forward failed, and you might not be able to resolve names in a domain. This often happens if you change your BIND configuration while the server is running; it doesn’t like that. The solution is to shut down named, delete the file whose name starts with the name of the zone configuration file but ends in .jnl in the directory that holds your zone configuration files, and restart named. A better practice is to make changes to your zone files only when named isn’t running.

You can test your server’s operation using the host command on the server or any other computer that has this tool. Type host name server to look up name using the specified server. If the computer pauses for several seconds and responds connection timed out, chances are the server has crashed on startup or you’ve specified the wrong server. (You may need to specify server as an IP address if the computer isn’t configured to use that system for name resolution by default.) Other error messages typically denote problems with your DNS configuration; check your logfiles for clues. Be sure to test both forward and reverse DNS lookups.

Pointing Clients at the Name Server

Client configuration is, of course, critically important to DNS operation. If you want local workstations and servers to use your DNS server for name resolution, you must tell them to do so. If you use DHCP to assign IP addresses to these computers, the simplest way to configure them to use your DNS server is to adjust your DHCP configuration using the option domain-name-servers line in your DHCP configuration file, as described earlier, in the section Section 15.1.4.1. Once configured in this way, a DHCP server can deliver DNS server information to Windows, Linux, Mac OS, and other clients that use DHCP.

If you want to configure some or all of your computers using static IP addresses without using DHCP, you must configure these computers to use your DNS servers manually. Precisely how you do so varies from one OS to another, but most provide GUI tools that enable you to enter the DNS server addresses manually. Earlier, the Section 15.1.5 described how to configure Windows XP to use DHCP. Part of this process provided an opportunity to tell Windows to use the DNS servers provided by the DHCP server or to use servers you specify. In particular, Figure 15-1 shows the relevant dialog box. Click “Use the following DNS server addresses,” and enter up to two DNS server addresses to have Windows use them instead of those provided via DHCP or if you don’t use DHCP at all. Similar tools exist in other versions of Windows and in other OSs.

Although you can enter DNS server addresses using GUI tools in most Linux distributions, Linux supports another method: the /etc/resolv.conf file specifies DNS servers and the domains that Linux should attempt to search. This file is likely to be quite short:

domain example.com
search example.com,pangaea.edu
nameserver 192.168.1.1
nameserver 10.29.102.7

Each line has a specific purpose:

domain: This line tells the computer the domain to which it belongs. The main practical upshot is that names are searched for in this domain before they’re searched in other domains or without the domain name.
search: This line enables you to tell the system to search domains instead of the one specified by domain. You can list up to six domains, separated by commas or spaces.
nameserver: You list DNS servers, one per line, using nameserver keywords. Linux supports up to three DNS servers; it tries each one in sequence until a lookup returns a definitive success code (a certain success or failure, as opposed to a failure of the server).

Whether the DNS client runs Linux, Windows, or some other OS, a DNS lookup normally uses a domain search list, even if the user specified a hostname with a domain. For instance, if you do a lookup on http://mandragora.example.com from within the http://example.com domain, the computer first tries a lookup on mandragora.example.com.example.com. If additional domains are in the search paths, similar lookups are performed on them, as in mandragora.example.com.pangaea.edu. When these lookups fail, the name resolver tries the lookup without appending any item from the search path. The assumption is that the user has entered a relative hostname without a domain component. You can block this initial, and probably erroneous, lookup by appending a dot, e.g., typing mandragora.example.com. rather than mandragora.example.com when entering the hostname. This trick works with most programs and protocols, but it might confuse some. In most cases, it’s unnecessary; the extra lookup that fails is unlikely to take very long at all, so it does no real harm.

Previous Chapter

15. Managing a Network with Linux

Next Chapter

Keeping Clocks Synchronized with NTP