UNIX System Administration Handbook - Evi Nemeth [243]
Authoritative and caching-only servers
Master, slave, and caching-only servers are distinguished by two characteristics: where the data comes from and whether the server is authoritative for the domain. Each zone has one master name server. The master server keeps the official copy of the zone’s data on disk. The system administrator changes the zone’s data by editing the master server’s data files.
A slave server gets its data from the master server through a “zone transfer” operation. A zone can have several slave name servers and must have at least one. A stub server is a special kind of slave that loads only the NS (name server) records from the master. See page 456 for an explanation of why you might want this behavior. It’s fine for the same machine to be both a master server for your zones and a slave server for other zones. Such cooperation usually makes for good DNS neighbors.
See page 458 for more information about zone transfers.
A caching-only name server loads the addresses of the servers for the root domain from a startup file and accumulates the rest of its data by caching answers to the queries it resolves. A caching-only name server has no data of its own and is not authoritative for any zone. See A university department on page 431 for an example of a caching-only configuration.
An authoritative answer from a name server is “guaranteed” to be accurate; a nonauthoritative answer might be out of date. However, a very high percentage of nonauthoritative answers are perfectly correct. Master and slave servers are authoritative for their own zones, but not for information they have cached about other domains. Truth be told, even authoritative answers can be inaccurate if a sysadmin changes the master server’s data and forgets to update the serial number of its data or run ndc reload (or if the changes have not yet propagated to slave servers).
The master server should be located on a machine that is stable, does not have many users, is relatively secure, and perhaps is on an uninterruptible power supply. There should be at least two slaves, one of which is off-site. On-site slaves should live on different networks and different power circuits. When name service stops, all normal network access stops, too.
A domain’s zone data normally includes the identities of the name servers of all of its subdomains. This name server chaining enables DNS clients to walk down the domain tree to look up any host on the Internet. If a parent domain does not mention certain name servers of a subdomain, those servers become “internal” servers and are not accessible from the outside world.
Although they are not authoritative, caching-only servers can reduce the latency seen by your users and the amount of DNS traffic on your internal networks. Consider putting a caching-only server on each subnet. At most sites, desktop machines typically go through a caching server to resolve queries about hosts on the Internet.
In BIND 4 and BIND 8, it wasn’t a good idea to use a single name server as an authoritative server for some zones and as a caching server for others. Each named ran with a single in-memory database, and cross-contamination could occur if memory was tight and cached data mixed with authoritative data. BIND 9 has eliminated this problem, so mix away.
Recursive and nonrecursive servers
Name servers are either recursive or nonrecursive. If a nonrecursive server has the answer to a query cached from a previous transaction or is authoritative for the domain to which the query pertains, it provides an appropriate response. Otherwise, instead of returning a real answer, it returns a referral to the authoritative servers of another domain that are more likely to know the answer. A client of a nonrecursive server must be prepared to accept and act on referrals.
Although nonrecursive servers may seem lazy, they usually have good reason not to take on extra work. Root servers and top-level domain servers are all nonrecursive, but at 10,000 queries per second