The number of queries that could potentially hit an active and popular domain on the Internet could easily overwhelm a name server. Caching helps reduce that load and reduce network traffic. Each server caches successful and unsuccessful resolution queries for a period of time defined by the server's administrator. Whenever a resolver queries the server for an address, the server checks its cache first for the data, and, if the data exists in the cache, submits the cached data to the client, rather than look up the data again.
Note Caching unsuccessful queries is called negative caching. Negative caching speeds response time, reduces server load, and reduces network traffic by eliminating repeated queries for names that can't be resolved (such as non-existent domains or hosts). As with positive caching, however, negative-cache results age and expire, enabling lookups to succeed when the domain or host record does become available.
Name servers can function as caching-only servers, which don't maintain any zone files and are not authoritative for any domain. A caching-only server receives queries from resolvers, performs the queries against other name servers, caches the results, and returns the results to the resolvers. Therefore, a caching-only server essentially acts as a lookup agent between the client and other name servers. At first glance, caching-only servers may seem to make little sense. They reduce network traffic, however, in two ways: Caching-only servers reduce zone transfers because the caching-only name server hosts no zones and, therefore, requires no zone transfers. Caching-only servers also reduce query traffic past the caching-only server as long as query results for a given query reside in the server's cache. Because the cache is cleared after the server restarts, the most effective caching-only server is one that remains up for extended periods.
A name server typically attempts to resolve queries against its own cache and zone files and, failing that, queries one or more other name servers for the information. In certain situations, you may not want all name servers for an organization to be communicating with the outside world — for network security, bandwidth, or cost reasons. Instead, you'd forward all traffic through a given name server that would act as a sort of agent for the other name servers in the organization. Assume, for example, that you have a few relatively slow or expensive Internet connections to your site and one with higher bandwidth or that is less costly. Servers A, B, and C connect through the former, and server D connects through the latter. Rather than have all servers generating traffic through their respective links, you might want to funnel all traffic through server D. In this case, server D would act as a forwarder, which forwards offsite name queries for other name servers on the network. Servers A, B, and C would handle queries against their local caches and zone files, and, failing those queries, would pass the query on to server D.
Name servers can interact with forwarders either exclusively or nonexclusively. If interacting nonexclusively, the server attempts to resolve queries against its cache and own zone files first. Failing that, the server forwards the request to the designated forwarder. If the forwarder fails the query, the server attempts to resolve the query on its own through other name servers. To prevent a server from doing this, you need to configure it as a slave, which makes it function in exclusive mode with the forwarder. When functioning as a slave, a name server first attempts to resolve a query against its cache and local zone files. Failing that, it forwards the query to the designated forwarder. If that fails, the forwarder responds with an unsuccessful query, and the local server fails the request to the client resolver without attempting any further resolution.
You also can configure a slave name server as a caching-only slave. In this configuration, the server hosts no zone files. It attempts to resolve queries against its local cache only, and, failing that, forwards the query to the designated forwarder and takes no further action to resolve the query. It does not itself fail the request to the resolver.
Was this article helpful?