Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Important DNS Facts and Concepts

There are several vital DNS facts and concepts. Knowledge of these facts and concepts are essential for fast and effortless configuration of DNS, as well as for effective DNS troubleshooting. The most important are discussed in this section.

The DNS Client and Server Are Distinct

Every network-enabled Linux computer has DNS client software, commonly called the resolver. The DNS client software simply queries its assigned DNS servers in the order they appear in the /etc/resolv.conf file. A computer's DNS client can be assigned a server on the same computer, on another computer, or sometimes on one of each.

DNS servers are machines configured to return query data. The DNS server software relies on the /etc/named.conf file and the files pointed to by the zone references in that file. Clients ask, and servers answer (sometimes after asking other servers).

Confusion can arise, however, when a single computer has both a DNS client and server, with the client pointing to the server. The client and server can appear as one entity, with the resulting confusion. So always remember that /etc/resolv.conf pertains to the DNS client or resolver. All the other files, like /etc/named.conf and the files it references, pertain to the DNS server.

DNS Terminology

Table 14.1 is a limited glossary of DNS terminology.

Table 14.1. Glossary of Essential DNS Terminology

Term Definition
DNS client The software component on all networked computers that finds the IP address for a name (or vice versa) by asking its assigned DNS server(s). On Red Hat Linux machines, the client gets its configuration information from /etc/resolv.conf. Sometimes the term DNS client is used to refer to the computer itself.
Resolver For practical purposes, a synonym for DNS client.
DNS server The software component that returns the name-to-IP translation (or vice versa) to the inquiring client. The DNS server may ask other DNS servers for help in doing this. On Red Hat Linux 7 machines, the server gets its configuration from /etc/named.conf and the files' named.conf references. On Red Hat Linux machines used as DNS servers, DNS services are provided by a daemon called named.
Resolve To convert a name to an IP address, or vice versa. Resolving is done by DNS and sometimes by other software.
Zone A subdomain or subnet over which a DNS server has authority.
Master A nameserver with authority over a zone that derives its data from local zone data files. Note that a nameserver can be master for some zones and slave for others.
Primary A synonym for master.
Slave A nameserver with authority for a zone that derives its data from another nameserver in a zone transfer. The other nameserver can be a master or another slave. Once the information is derived, it is stored locally so it can function even if its source goes down. Note that a nameserver can be master for some zones and slave for others.
Secondary A synonym for slave.
Zone transfer A transfer of zone data from a master or slave DNS server to a slave DNS server. The receiving slave initiates the zone transfer after exceeding the refresh time or upon notification from the sending server that the data has changed.

DNS Maps Names to IP Numbers and Vice Versa

DNS maps names to IP numbers and vice versa. That's all it does. This is a vital concept to understand.

Almost everything you can do with a fully qualified domain name, URL, or any other name resolvable to an IP address, you can do with that IP address. And if you use IP addresses, you needn't use DNS (except for a few reverse DNS situations). For the most part, if a command doesn't work with the IP address, the fault is not with DNS but with a lower-level network function. Trying commands with IP addresses instead of domain names and URLs is a great troubleshooting test.

The Forward and Reverse Zones Must Be Kept in Sync

The forward and reverse zones must be kept in sync. If a host changes IP addresses, that fact must be recorded in both the forward and the reverse zone data files and the serial number for each incremented. Failure to keep forward and reverse zones in sync can cause a variety of hard to solve problems, possibly worldwide.

The HUP Signal Versus Restart

According to most literature, including the named man page, named can be forced to reload its zone data files by the following command:


   # kill -HUP `cat /var/run/named.pid`

Unfortunately, this doesn't always work. A test that doesn't do what the troubleshooter thinks it does can waste hours. Therefore, the recommended way to get the zone data files to reload is with a restart:


   # /etc/rc.d/init.d/named restart

Restarting loses accumulated cache and eliminates DNS service during the restart process (20 seconds to 4 minutes). If that is unacceptable, you can try the HUP signal, but be very careful to verify that it does what you think it will. You can view the current named database and cache by sending named an INT signal. This is explained in the section "Troubleshooting DNS," later in this chapter.

The in-addr.arpa Domain

All reverse mappings exist in the in-addr.arpa domain, thereby eliminating any possible confusion regarding the number's purpose. The network and subnetwork parts of the IP address are placed in reverse order to follow the standard way domain names are written. Domain names describe the hostname, the subnetwork, and then the network, whereas IP addresses describe the network, the subnetwork, and finally the hostname. Placing the IP address in reverse order follows the convention established by the actual host and network names.

Host Naming Schemes

It is common for sites to pick a naming scheme for all of their hosts. This tends to make it easier to remember names, especially as the site grows in size. For example, the east wing of the office might use famous music bands to name their machines, and the west wing might use the names of Star Trek characters. This also makes it easier to locate a machine by its name.

Configuring the DNS Client: /etc/resolv.conf

Every machine in your network is a DNS client. Each DNS client runs resolver code to query DNS servers. The resolver gets its configuration from file /etc/resolv.conf. To find out which DNS server to use, you need to configure the file /etc/resolv.conf. This file should look something like this:

search domain.cxm
nameserver 192.168.100.1

Here domain.cxm is the domain name of the site, and the IP address listed after nameserver is the address of the DNS server that should be contacted. You can have up to three nameserver entries, each of which will be tried sequentially until one of them returns an answer. In PPP-connected machines, one or more of the nameservers can be at the ISP, relieving the local DNS server of work and decreasing traffic on the phone line.

NOTE

You must supply the nameserver's IP address, not its hostname. After all, how is the resolver going to know what the nameserver's IP address is until it finds the nameserver?

If you were to delete the search domain.cxm line, the result would be an inability to look up a host without its complete domain name. For instance, the following would fail if the search line were deleted:


   $ nslookup mainserv

However, the following would still succeed:


   $ nslookup mainserv.domain.cxm

The /etc/host.conf Order Statement

A client computer can choose its method of name resolution or specify a hierarchy of methods to use. This is done with the order statement in /etc/host.conf. One very efficient and reliable hierarchy is to try the /etc/hosts file first and then try DNS. This has two advantages:

To accomplish this, make sure the following line is in /etc/host.conf:

order hosts,bind

The Software of DNS

To configure a DNS for your site, you need to be familiar with the following tools:

named

The named daemon needs to run on DNS servers to handle queries. If named cannot answer a query, it forwards the request to a server that can. Along with queries, named is responsible for performing zone transfers. Zone transferring is the method by which changed DNS information is propagated across the Internet. If you didn't install the named daemon with the Red Hat 7 operating system, you need to install it from the BIND distribution, available from http://www.redhat.com. It is also on one of the CD-ROMs that comes with this book. The filename is

bind-8.2.2_P5-24.i386.rpm

The named daemon is normally started at bootup. Here are the commands to manually start, stop, and restart named, respectively:

/etc/rc.d/init.d/named start
/etc/rc.d/init.d/named stop
/etc/rc.d/init.d/named restart

After you make any change to /etc/named.conf or any of the files referenced by named.conf, you must restart named before the changes will take effect.

NOTE

nslookup delivers many powerful features when used interactively. It can also lead to frustrating hangs. For enhanced troubleshooting, learn about nslookup from its man page.

The Resolver Library

The resolver library enables client programs to perform DNS queries. This library is built into the standard library under Linux. The resolver library takes its configuration information from /etc/resolv.conf.

nslookup

The nslookup command is a utility invoked from the command line to ensure that both the resolver and the DNS server being queried are configured correctly. It does this by resolving either a hostname into an IP address or an IP address into a domain name. To use nslookup, simply provide the address you want to resolve as a command-line argument. For example, here is the one-argument version:


   # nslookup mydesk.domain.cxm

On a properly configured DNS, the result should look something like this:


   # nslookup mydesk.domain.cxm
Server:  mainserv.domain.cxm
Address:  192.168.100.1

Name:    mydesk.domain.cxm
Address:  192.168.100.2

The two-argument version specifies the IP address of the DNS server as the second argument. In the absence of the second argument, the first server line in /etc/resolv.conf is used. Here's a two-argument example:


   # nslookup mydesk.domain.cxm 192.168.100.1

The two-argument command returns the exact same output as the one-argument version. The two-argument version is used when reverse DNS isn't functioning correctly or if /etc/resolv.conf has been temporarily renamed or deleted.

traceroute

The traceroute utility enables you to determine the path a packet is taking across your network and into other networks. This is very useful for debugging network connection problems, especially when you suspect the trouble is located in someone else's network.

Using the ICMP protocol (Internet Control Message Protocol, the same protocol as used by ping), traceroute looks up each machine along the path to a destination host and displays the corresponding name and IP address for that site. Along with each name is the number of milliseconds that each of the three tiers took to get to the destination.

Preceding each name is a number that indicates the distance to that host in terms of hops. The number of hops to a host indicates the number of intermediate machines that had to process the packet. As you can guess, a machine that is one or two hops away is usually much closer than a machine that is 30 hops away.

To use traceroute, give the destination hostname or IP address as a command-line argument. For example:

# traceroute www.hyperreal.org

This should return something similar to the following:

traceroute to hyperreal.org (204.62.130.147), 30 hops max, 40 byte packets
 1  fe0-0.cr1.NUQ.globalcenter.net (205.216.146.77)  0.829 ms  0.764 ms  0.519 ms
 2  pos6-0.cr2.SNV.globalcenter.net (206.251.0.30)  1.930 ms  1.839 ms 1.887 ms
 3  fe1-0.br2.SNV.globalcenter.net (206.251.5.2)  2.760 ms  2.779 ms 2.517 ms
 4  sl-stk-17-H10/0-T3.sprintlink.net (144.228.147.9)  5.117 ms  6.160 ms  6.109 ms
 5  sl-stk-14-F0/0.sprintlink.net (144.228.40.14)  5.453 ms  5.985 ms 6.157 ms
 6  sl-wired-2-S0-T1.sprintlink.net (144.228.144.138)  10.987 ms 25.130 ms  11.831 ms
 7  sf2-s0.wired.net (205.227.206.22)  30.453 ms  15.800 ms  21.220 ms
 8  taz.hyperreal.org (204.62.130.147)  16.745 ms  14.914 ms  13.018 ms

NOTE

Using a hostname for traceroute or ping might appear to hang if the name can't be resolved. It's best to learn a few strategic IP addresses (like your ISP's DNS, WWW, default gateway, and so on) and check those if hostnames appear to fail.

If you see any star characters (such as *) instead of a hostname, that machine is probably unavailable. This could be due to a variety of reasons, with network failure and firewall protection being the most common. Also, be sure to note the time it takes to get from one site to another. If you feel that your connection is excessively slow, it might be just one connection in the middle that is slowing you down and not the site itself.

By using traceroute, you can also get a good measure of the connectivity of a site. If you are in the process of evaluating an ISP, try doing a traceroute from its site to a number of other sites, especially to large communications companies such as Sprint and MCI. Count how many hops, and how much time per hop, it takes to reach its network.

Share ThisShare This

Informit Network