14.7 Caching

14.7 Caching

To reduce the DNS traffic on the Internet, all name servers employ a cache. With the standard Unix implementation, the cache is maintained in the server, not the resolver. Since the resolver is part of each application, and applications come and go, putting the cache into the program that lives the entire time the system is up (the name server) makes sense. This makes the cache available to any applications that use the server. Any other hosts at the site that use this name server also share the server's cache.

In the scenario that we've used for our examples so far (Figure 14.9), we've run the clients on the host sun accessing the name server across the SLIP link on the host noao.edu. We'll change that now and run the name server on the host sun. In this way if we monitor the DNS traffic on the SLIP link using tcpdump, we'll only see queries that can't be handled by the server out of its cache.

By default, the resolver looks for a name server on the local host (UDP port 53 or TCP port 53). We delete the nameserver directive from our resolver file, leaving only the domain directive:

 sun %  cat /etc/resolv.conf  domain tuc.noao.edu 

The absence of a nameserver directive in this file causes the resolver to use the name server on the local host.

We then use the host command to execute the following query:

 sun %  host ftp.uu.net  ftp.uu.net               A       192.48.96.9 

Figure 14.14 shows the tcpdump output for this query.

Figure 14.14. tcpdump output for: host ftp.uu.net.

This time we've used a new option for tcpdump. We collected all the data to or from UDP or TCP ports 53 with the -w option. This saves the raw output in a file for later processing. This prevents tcpdump from trying to call the resolver itself, to print all the names corresponding to the IP addresses. After we ran our queries, we terminated tcpdump and reran it with the -r option. This causes it to read the raw output file and generate its normal printed output (which we show in Figure 14.14). This takes a few seconds, since tcpdump calls the resolver itself.

The first thing to notice in our tcpdump output is that the identifiers are small integers (2 and 3). This is because we terminated the name server, and then restarted it, to force the cache to be empty. When the name server starts up, it initializes the identifier to 1.

When we type our query, looking for the IP address of the host ftp.uu.net, the name server contacts one of the eight root servers, ns.nic.ddn.mil (line 1). This is the normal A type query that we've seen before, but notice that the recursion-desired flag is not specified. (A plus sign would have been printed after the identifier 2 if the flag was set.) In our earlier examples we always saw the resolver set the recursion-desired flag, but here we see that our name server doesn't set the flag when it's contacting one of the root servers. This is because the root servers shouldn't be asked to recursively answer queries ” they should be used only to find the addresses of other, authoritative servers.

Line 2 shows that the response comes back with no answer RRs, five authority RRs, and five additional information RRs. The minus sign following the identifier 2 means the recursion-available (RA) flag was not set ” this root server wouldn't answer a recursive query even if we asked it to.

Although tcpdump doesn't print the 10 RRs that are returned, we can execute the host command to see what's in the cache:

 sun  % host -v ftp.uu.net  Query about ftp.uu.net for record types A     Trying ftp.uu.net ...     Query done, 1 answer, status: no error     The following answer is not authoritative:     ftp.uu.net              19109   IN      A       192.48.96.9     Authoritative nameservers:     UU.NET                  170308  IN      NS      NS.UU.NET     UU.NET                  170308  IN      NS      UUNET.UU.NET     UU.NET                  170308  IN      NS      UUCP-GW-1.PA.DEC.COM     UU.NET                  170308  IN      NS      UUCP-GW-2.PA.DEC.COM     UU.NET                  170308  IN      NS      NS.EU.NET     Additional information:     NS.UU.NET               170347  IN      A       137.39.1.3     UUNET.UU.NET            170347  IN      A       192.48.96.2     UUCP-GW-1.PA.DEC.COM    170347  IN      A       16.1.0.18     UUCP-GW-2.PA.DEC.COM    170347  IN      A       16.1.0.19     NS.EU.NET               170347  IN      A       192.16.202.11 

This time we specified the -v option to see more than just the A record. This shows that there are five authoritative name servers for the domain uu.net. The five RRs with additional information that are returned by the root server contain the IP addresses of these five name servers. This saves us from having to contact the root server again, to look up the address of one of the servers. This is another implementation optimization in the DNS.

The host command states that the answer is not authoritative. This is because the answer was obtained from our name server's cache, not by contacting an authoritative server.

Returning to line 3 of Figure 14.14, our name server contacts the first of the authoritative servers (ns.uu.net) with the same question: What is the IP address of ftp.uu.net? This time our server sets the recursion-desired flag. The answer is returned on line 4 as a response with one answer RR.

We then execute the host command again, asking for the same name:

 sun  % host ftp.uu.net  ftp.uu.net               A          192.48.96.9 

This time there is no tcpdump output. This is what we expect, since the answer output by host is returned from the server's cache.

We execute the host command again, looking for the address of ftp.ee.lbl.gov:

 sun %  host ftp.ee.lbl.gov  ftp.ee.lbl.gov          CNAME      ee.lbl.gov     ee.lbl.gov              A          128.3.112.20 

Figure 14.15 shows the tcpdump output.

Figure 14.15. tcpdump output for: host ftp.ee.lbl.gov.

Line 1 shows that this time our server contacts another of the root servers (c.nyser.net). A name server normally cycles through the various servers for a zone until round-trip estimates are accumulated . The server with the smallest round-trip time is then used.

Since our server is contacting a root server, the recursion-desired flag is not set. This root server does not clear the recursion-available flag, as we saw in line 2 in Figure 14.14. (Even so, a name server still should not ask a root server for a recursive query.)

In line 2 the response comes back with no answers, but four authority RRs and four additional information RRs. As we can guess, the four authority RRs are the names of the name servers for ftp.ee.lbl.gov, and the four other RRs contain the IP addresses of these four servers.

Line 3 is the query of the name server ns1.lbl.gov (the first of the four name servers returned in line 2). The recursion-desired flag is set.

The response in line 4 is different from previous responses. Two answer RRs are returned and tcpdump says that the first one is a CNAME RR. The canonical name of ftp.ee.lbl.gov is ee.lbl.gov.

This is a common usage of CNAME records. The FTP site for LBL always has a name beginning with ftp, but it may move from one host to another over time. Users need only know the name ftp.ee.lbl.gov and the DNS will replace this with its canonical name when referenced.

Remember that when we ran host, it printed both the CNAME and the IP address of the canonical name. This is because the response (line 4 in Figure 14.15) contained two answer RRs. The first one is the CNAME and the second is the A record. If the A record had not been returned with the CNAME, our server would have issued another query, asking for the IP address of ee.lbl.gov. This is another implementation optimization ” both the CNAME and the A record of the canonical name are returned in one response.