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:
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.
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:
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 220.127.116.11 amy IN A 18.104.22.168 darrah IN A 22.214.171.124 joe IN A 126.96.36.199 bill IN A 188.8.131.52 ; ; 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:
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 184.108.40.206 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 220.127.116.11, the reverse lookup zone must have the name 43.in-addr.arpa. In the Class B network 18.104.22.168, the reverse lookup zone must have the name 58.172.in-addr.arpa.
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:
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:
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:
NSLookup has an extensive list of options. A few basic options covered here give you a feel for how NSLookup works.
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: 22.214.171.124 >
The chevron character (>) is NSLookup's prompt.
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 126.96.36.199. 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.