Reliability Designs for DNS

DNS is a mission-critical service. Networked applications depend on it and NNM is no exception. The architecture of DNS provides several mechanisms to ensure reliability of the service:

• client access to multiple name servers

• caching at the name server

• primary and secondary name servers

To understand how these architectural elements provide reliability, consider the client-server DNS model first. An application (such as telnet, ftp, NNM, Navigator, and sendmail) that needs to connect to another system by name is a DNS client. This client code is known as the resolver and it is guided by an editable configuration file called resolv.conf (that’s resolve without the last letter) in UNIX. resolv.conf defines the following parameters:

• the default domain of the client system

• an optional search list of additional domains

• up to three name server IP addresses

Windows client systems provide a GUI for configuring the DNS resolver (as shown in Figure 2-3 on page 37).

The purpose of listing three name servers is to increase the statistical probability that at least one name server can be reached. On real networks, a name server may crash or the network path to it may go down. For example, suppose that each of our three name servers has a reliability of 99% and that they are independent of each other (different AC power, different subnet, different building, different router, different administrator, different software). The statistical reliability of our example name service is therefore 1-(1-0.99)³ = 0.999999 = 99.9999%, which is remarkable given the 99% reliability given for each name server.

NNM makes such heavy use of DNS that it seems logical to install a name server on the same system. This reduces DNS-related network traffic. This also reduces the latency of the DNS service by eliminating network latency between the NNM system and the name server system. Therefore, the first name server listed in the file resolv.conf is 127.0.0.1, the standard IP address for localhost, which is the standard local IP loopback address.

How should this local name server be configured? It’s perfectly acceptable to install DNS configuration files on the NNM system. This may not be consistent with the existing architecture and implementation of the corporate name servers. Therefore, it is common practice to configure DNS as a caching-only name server on the NNM system. Every time NNM makes a DNS query, the result is cached in local memory until the time-to-live for the entry expires.

This means that updates to the name servers are automatically propagated to the NNM system name server within the time-to-live interval. The caching feature improves the performance of forward and reverse lookups. If the authoritative name servers should go down during the time-to-live interval, this event is hidden since the local cache still holds the necessary information.

Another reliability element in the DNS architecture is the secondary name server. The primary name server is authoritative because its configuration files are local. These database files are configured by the local hostmaster. Other name servers may be configured as secondary name servers by referring to the primary name server. The secondary name server copies (using a zone transfer) the primary name server database to its local disk. The zone transfer is repeated when the time-to-live expires.

Note that the major difference between a caching-only name server and a secondary name server is that the caching-only server caches entries one at a time as they are looked up, while the secondary name server transfers the entire DNS zone at startup time.