Managing DNS

When implementing DNS on your network, you need to choose at least one server to be responsible for maintaining your domain. This is referred to as your primary name server, and it gets all the information about the zones it is responsible for from local files. Any changes you make to your domain are made on this server.

Many networks also have at least one more server as a backup, or secondary name server. If something happens to your primary server, this machine can continue to service requests. The secondary server gets its information from the primary server's zone file. When this exchange of information takes place, it is referred to as a zone transfer.

A third type of server is called a caching-only server. A cache is part of a computer's memory that keeps frequently requested data ready to be accessed. As a caching-only server, it responds to queries from clients on the local network for name resolution requests. It queries other DNS servers for information about domains and computers that offer services such as Web and FTP. When it receives information from other DNS servers, it stores that information in its cache in case a request for that information is made again.

Caching-only servers are used by client computers on the local network to resolve names. Other DNS servers on the Internet will not know about them and therefore will not query them. This is desirable if you want to distribute the load your servers are put under. A caching-only server is also simple to maintain, if for instance you have a remote site where client computers need name resolution services and nothing more.

The cache is preconfigured with the IP addresses of nine root-level DNS servers. If this computer has access to the Internet via a router, it is ready to work. Client computers could include the IP address of this DNS server in their search order list, and this DNS server would begin to service requests by contacting other DNS servers and automatically adding entries to its cache.

By the Way

DNS must be implemented as a service or daemon running on the DNS server machine. Windows servers have a DNS service, though some Microsoft admins prefer to use third-party DNS implementations. The Unix world has a number of DNS implementation options, but the most popular choice is Berkeley Internet Name Domain (BIND).

Configuring the DNS Server

A group of DNS hosts in a collective configuration with a common set of DNS servers is called a zone. On simple networks, a zone might represent a complete DNS domain. For instance, the domain punyisp.com might be treated as a single zone for purposes of DNS configuration. On more complex networks, the DNS configuration for a subdomain is sometimes delegated to another zone that serves the subdomain. Zone delegation lets administrators with more immediate knowledge of a subnetwork manage the DNS configuration for that subnetwork. For instance, the DNS administrators for the domain cocacola.com might delegate the DNS configuration of the subdomain dallas.cocacola.com to a zone controlled by the DNS administrators in the Dallas office, who have closer watch on hosts in dallas.cocacola.com.

You might ask, "What's the difference between a zone and a domain?" It is important to note that, aside from the subtle semantic difference (a domain is a subdivision of the namespace and a zone is a collection of hosts), the concepts of a zone and a domain are not exactly parallel. As you read this section, keep the following facts in mind:

• Membership in a subdomain implies membership in the parent domain. For instance, a host in dallas.cocacola.com is also part of cocacola.com. By contrast, if the zone for dallas.cocacola.com is delegated, a host in dallas.cocacola.com is not part of the cocacola.com zone.

• If a subdomain is not specifically delegated, it does not require a separate zone and is simply included with the zone file for the parent domain.

The details of how to delegate a DNS zone depend upon the DNS server application. For now, the important thing to remember is that a zone represents a collective configuration for a group of DNS servers and hosts, and DNS administrators can optionally delegate portions of the namespace to other zones for administrative efficiency.

Zone Files

As the previous section stated, a DNS zone is an administrative unit representing a collection of computers inhabiting a portion of the DNS namespace. The DNS configuration for a zone is stored in a zone file. DNS servers refer to the information in the zone file when responding to queries and initiating requests. A zone file is a text file with a standardized structure. The contents of the zone file consists of multiple resource records. A resource record is a one-line statement providing a chunk of useful information about the DNS configuration. Some common types of resource records include the following:

• SOA SOA stands for Start of Authority. The SOA record designates the authoritative name server for the zone.

• NS NS stands for Name Server. The NS record designates a name server for the zone. A zone may have several name servers (and, hence, several NS records) but only one SOA record for the authoritative name server.

• A An A record maps a DNS name to an IP address.

• PTR A PTR record maps an IP address to a DNS name.

• CNAME CNAME is short for canonical name. A CNAME record maps an alias to the actual hostname represented by an A record.

Thus, the zone file tells the DNS server:

• The authoritative DNS server for the zone

• The DNS servers (authoritative and non-authoritative) in the zone

• The DNS-name-to-IP-address mappings for hosts within the zone

• Aliases (alternative names) for hosts within the zone

Other resource record types provide information on topics such as mail servers (MX records), IP-to-DNS-name mappings (PTR records), and well-known services (WKS records). A sample zone file looks something like this:

 @ IN    SOA    boris.cocacola.com.   hostmaster.cocacola.com. (         201.9     ; serial number incremented with each                   ; file update                   ;         3600      ; refresh time (in seconds)         1800      ; retry time (in seconds)         4000000   ; expiration time (in weeks)         3600)     ; minimum TTL IN    NS    horace.cocacola.com. IN    NS    boris.cocacola.com. ; ; Host to IP address mappings ; localhost    IN    A    127.0.0.1 chuck        IN    A    181.21.23.4 amy          IN    A    181.21.23.5 darrah       IN    A    181.21.23.6 joe          IN    A    181.21.23.7 bill         IN    A    181.21.23.8 ; ; Aliases ; ap            IN CNAME    amy db            IN CNAME    darrah bu            IN CNAME    bill 

Note that the SOA record includes several parameters governing the process of updating the secondary DNS servers with the master copy of the zone data on the primary DNS server. In addition to a serial number representing the version number of the zone file itself, there are parameters that represent the following:

• Refresh time The time interval at which secondary DNS servers should query the primary server for an update of zone information.

• Retry time The time to wait before trying again if a zone update is unsuccessful.

• Expiration time The upper limit for how long the secondary name servers should retain a record without a refresh.

• Minimum Time-to-Live (TTL) The default time-to-live for exported zone records.

The rightmost term of the SOA record is actually the email address for the person with responsibility for the zone. Replace the first period with an @ sign to form the email address.

The preceding example is, of course, the simplest of zone files. Larger files might include hundreds of address records and other less common record types representing other aspects of the configuration. The name of the zone file, and in some cases the format, can vary depending upon the DNS server software. This example is based on the popular BIND (Berkeley Internet Name Domain), the most common name server on the Internet.

It is worth remembering, also, that the honored practice of configuring services by manipulating text files is fading from favor. Many DNS server applications provide a user interface that hides the details of the zone file from the reader.

Dynamic DNS (described later in this chapter) provides yet another layer of separation from the details of the configuration.

The Reverse Lookup Zone File

Another type of zone file necessary for DNS name resolution is the reverse lookup file. This file is used when a client provides an IP address and requests the corresponding hostname. In IP addresses, the leftmost portion is general, and the rightmost portion is specific. However, in domain names the opposite is true: The left portion is specific, and the right portion, such as com or edu, is general. To create a reverse lookup zone file you must reverse the order of the network address so the general and specific portions follow the same pattern used within domain names. For example, the zone for the 192.59.66.0 network would have the name 66.59.192.in-addr.arpa.

Every resource record in this file always has the host ID followed by .in-addr.arpa. The in-addr portion stands for inverse address, and the arpa portion is another top level domain and is a holdover from the original ARPAnet that preceded the Internet.

By the Way

Class A and B networks have shorter reverse lookup zone names due to the fact that they contain fewer network bits. For example, in the Class A network 43.0.0.0, the reverse lookup zone must have the name 43.in-addr.arpa. In the Class B network 172.58.0.0, the reverse lookup zone must have the name 58.172.in-addr.arpa.

DNS Utilities

You can use any network utility that supports name resolution to test whether your network is resolving names properly. A Web browser, an FTP client, a Telnet client, or the Ping utility can tell you whether your computer is succeeding with name resolution. If you can connect to a resource using its IP address but you cannot connect to the resource using a hostname or FQDN, there is a good chance the problem is a name resolution problem.

If your computer uses a hosts file and also uses DNS, keep in mind that you need to disable or rename the hosts file temporarily when you test DNS. Otherwise it will not be easy to determine whether the name was resolved through the hosts file or DNS. The following section describes how to use Ping to test DNS. A later section describes the NSLookup utility, which provides a number of DNS configuration and troubleshooting features.

Checking Name Resolution with Ping

The simple and useful Ping utility is a good candidate for testing your DNS configuration. Ping sends a signal to another computer and waits for a reply. If a reply arrives, you know that the two computers are connected. If you know the IP address of a remote computer, you can ping the computer by IP address:

 ping 198.1.14.2 

If this command succeeds, you know your computer can connect to the remote computer by IP address.

Now try to ping the remote computer by DNS name:

 ping williepc.remotenet.com 

If you can ping the remote computer by IP address but not by DNS name, you might have a name resolution problem. If you can ping by DNS name, name resolution is working properly.

You'll learn more about Ping in Hour 13, "Connectivity Utilities."

Checking Name Resolution with NSLookup

The NSLookup utility enables you to query DNS servers and view information such as their resource records, and it is useful when troubleshooting DNS problems. The NSLookup utility operates in two modes:

• Batch mode In Batch mode, you start NSLookup and provide input parameters. NSLookup performs the functions requested by the input parameters, displays the results, and then terminates.

• Interactive mode In Interactive mode, you start NSLookup without supplying input parameters. NSLookup then prompts you for parameters. When you enter the parameters, NSLookup performs the requested actions, displays the results, returns to a prompt, and waits for the next set of parameters. Most administrators use Interactive mode because it is more convenient when performing a series of actions.

NSLookup has an extensive list of options. A few basic options covered here give you a feel for how NSLookup works.

To run NSLookup in Interactive mode, enter the name nslookup from a command prompt.

As shown in Figure 11.7, each NSLookup response starts with the name and IP address of the DNS server that NSLookup is currently using, for example

 Default Server:    dnsserver.Lastingimpressions.com Address:    192.59.66.200 > 

Figure 11.7. NSLookup responses.

The chevron character (>) is NSLookup's prompt.

NSLookup has about 15 settings that you can change to affect how NSLookup operates. A few of the most commonly used settings are listed here:

• ?; and help These commands are used to view a list of all NSLookup commands.

• server This command specifies which DNS server to query.

• ls This command is used to list the names in a domain, as shown near the middle of Figure 11.7.

• ls -a This command lists canonical names and aliases in a domain, as shown in Figure 11.7.

• ls -d This command lists all resource records, as shown near the bottom of Figure 11.7.

• set all This command displays the current value of all settings.

NSLookup is not restricted to viewing information from your DNS server; you can view information from virtually any DNS server. If you have an Internet service provider (ISP), you should have IP addresses for at least two DNS servers.

NSLookup can use either IP addresses or domain names. You can switch NSLookup to another DNS server by entering the server command followed by either the IP address or the FQDN. For instance, to connect NSLookup to the E root server, you can enter server 192.203.230.10. Then you can enter virtually any domain name, such as samspublishing.com, and see the IP addresses registered for that domain name. Be aware that most commercial DNS servers and root servers will refuse ls commands because they can generate a tremendous amount of traffic and might pose a security leak.