UNIX System Administration Handbook - Evi Nemeth [245]
Let’s inspect a real example. Suppose we want to look up the address for the machine vangogh.cs.berkeley.edu from the machine lair.cs.colorado.edu. The host lair asks its local name server, ns.cs.colorado.edu, to figure out the answer. Exhibit A illustrates the subsequent events. We used relative names to reduce clutter and to make the labels more readable. The numbers on the arrows between servers show the order of events, and a letter indicates the type of transaction (query, referral, or answer). We assume that none of the required information was cached before the query, except for the names and IP addresses of the servers of the root domain.
Exhibit A DNS query process
The local name server doesn’t know the address; furthermore, it doesn’t know anything about cs.berkeley.edu or berkeley.edu or even edu. It does know some servers for the root domain, however, and since it is a recursive server, it queries a root server about vangogh.cs.berkeley.edu.
Root servers used to contain data for both the root zones and for the gTLDs, but these days the gTLDs have their own servers. In answer to our root-server query about vangogh.cs.berkeley.edu, we receive a referral to the servers for the edu domain.
The local name server then sends its query to an edu server (asking, as always, about vangogh.cs.berkeley.edu) and gets back a referral to the servers for berkeley.edu. It then repeats the query in the berkeley.edu domain. If the Berkeley server is not recursive and doesn’t have the answer cached, it returns a referral to cs.berkeley.edu. The cs.berkeley.edu server is authoritative for the requested information and returns vangogh’s address.
When the dust settles, ns.cs.colorado.edu has cached vangogh’s address. It has also cached lists of servers for edu, berkeley.edu, and cs.berkeley.edu.
named queries use the UDP protocol and port 53. Responses come back via UDP unless they are longer than 512 bytes, in which case they use TCP. Zone transfers between servers always use TCP.
Caching and efficiency
Caching increases the efficiency of lookups: a cached answer is almost free and is usually correct, because mappings change infrequently. Most queries are for local hosts and can be resolved quickly. Users also inadvertently help with efficiency because they repeat many queries.
For a long time, caching was only applied to positive answers. If a host’s name or address could not be found, that fact was not saved. A scheme for negative DNS caching was described in RFC1034, but it was incomplete and was not implemented in most versions of BIND. In 1998, RFC2308 defined an updated scheme for negative caching. This scheme was implemented in BIND 8.2 as an optional feature; it is mandatory in BIND 9.
One measurement at the RIPE root server in Europe showed that 60% of DNS queries were for nonexistent data (many queries were for 127.in-addr.arpa or for Microsoft services as hostnames). Caching this information further down the DNS tree should dramatically reduce the load on the root servers.
Negative caching saves answers of the following types:
• No host or domain matches the name queried.
• The type of data requested does not exist for this host.
• The server to ask is not responding.
• The server is unreachable because of network problems.
The first two types of negative data are cached for 1–3 hours, and the other types are cached for 5 minutes. Nonauthoritative answers may be cached; authoritative negative answers must be cached.
named often receives multiple DNS records in response to a query. For example, a query for the name servers of the root domain would receive a response that listed all 13 root servers. Which one should your server query?
When named must choose among several remote servers, all of which are authoritative for a domain, it first determines the network round trip time (RTT) to each server. It then sorts the servers into “buckets” according