UNIX System Administration Handbook - Evi Nemeth [244]
A recursive server returns only real answers or error messages. It follows referrals itself, relieving the client of this responsibility. The basic procedure for resolving a query is essentially the same; the only difference is that the name server takes care of handling referrals rather than passing them back to the client.
The resolver libraries that come with most versions of UNIX do not understand referrals; they expect the local name server to be recursive.
One side effect of having a name server follow referrals is that its cache acquires information about intermediate domains. On a local network this caching is often the behavior you want, since it allows subsequent lookups from any host on the network to benefit from the name server’s previous work. On the other hand, the server for a high-level domain such as com or edu should not save up information requested by a host several domains below it.
Early versions of BIND required source code changes and recompilation to modify a server’s recursiveness. This option then moved to a command-line flag (-r), and it is now a parameter in the configuration file. A server can even be configured to be recursive for its own clients and nonrecursive for outsiders.
Name servers generate referrals hierarchically. For example, if a server can’t supply an address for the host lair.cs.colorado.edu, it refers to the servers for cs.colorado.edu, colorado.edu, edu, or the root domain. A referral must include addresses for the servers of the referred-to domain, so the choice is not arbitrary; the server must refer to a domain for which it already knows the servers.
The longest known domain is generally returned. If the address of lair was not known but the name servers for cs.colorado.edu were known, then those servers’ address would be returned. If cs.colorado.edu was unknown but colorado.edu was known, then the addresses of name servers for colorado.edu would be returned, and so on.
Name servers preload their caches from a “hints” file that lists the servers for the root domain. Some referral can always be made, even if it’s just “Go ask a root server.”
The resolver library
Clients look up hostname mappings by calling the gethostbyname family of library routines. The original implementation of gethostbyname looked up names in the /etc/hosts file. For host mappings to be provided by DNS, these routines must use the resolver library, which knows how to locate and communicate with name servers. All modern versions of UNIX have integrated the resolver into the standard libraries.
Most systems’ implementations of gethostbyname can draw upon information from several different sources: flat files (such as /etc/hosts), DNS, and perhaps a local administrative database system such as NIS or NIS+. Some systems allow for detailed administrative control over which sources are searched and in what order. See Prioritizing sources of administrative information on page 523 for specifics. The vendor-specific sections of this chapter present bite-sized treatments of this topic as it pertains to host lookups; they start on page 481.
Shell interfaces to DNS
The BIND software distribution includes the dig and nslookup commands, both of which provide a command-line interface for executing DNS queries. They are useful as debugging aids and as tools for extracting information from DNS. Although the commands are similar in function, they are somewhat different in design. See page 475 for more information.
16.7 How DNS WORKS
Each host that uses DNS is either a client of the system or simultaneously a client and a server. If you do not plan to run any DNS servers, it’s not essential that you read the next few sections (skip ahead to Resolver configuration7
on page 411). However, they will help you develop a more solid understanding of the architecture of DNS.
Delegation
All name servers know about the root servers. The root servers in turn know about com, org, edu, fi, de, and other top-level domains. Farther down the chain,