Defenses against DNS Spoofing

The ultimate defense against DNS spoofing is not to use the DNS.

However, DNS style naming is such a part of the way users and system administrators work that it is unthinkable to do without it. On the other hand, many name-to-IP address mappings will not change and, in some cases, it may make as much sense for a system administrator to configure clients to use an IP address as it would to use a DNS name. Every place an IP address is used in place of a DNS name is one less place the system is vulnerable to DNS spoofing.

Many operating systems simplify the process of reducing use of the DNS by having an API for name-to-address and address-to-name mappings. The API is the same whether DNS is being used to implement these mappings or some other standard. Some implementations of the API will consult local data that is believed to be faster or more secure than DNS. The DNS is consulted by these implementations of the API only if the local sources fail to give conclusive results.

One way to limit the spread of invalid cached entries is to use name server software running on many hosts in your network. If a client on one machine triggers the corruption of the cache on one name server, the use of multiple name servers reduces the likelihood of widespread damage. Placing a name server on every timeshared Unix host, for example, will not only provide quick responses to local clients from the cached entries on the name server, but will also reduce the set of hosts affected by a compromised name server consulted by a set of users

on a single timeshared host.

Other hosts can use a different name server that will not have its cache corrupted as long as the name server on the timeshared host does not forward recursive requests to the other name server. An active attacker targeting a particular system may make direct queries of any name server to trigger the corruption of its cache. The technique outlined here limits damage from a passive attacker waiting for victims to come along. You can also add checks to some name servers so that they will respond only to select clients rather than an arbitrary client. Placing such a limitation on a name server does not make it useful for serving requests to the outside world but makes it more secure for internal use.

In the case study of Frank’s and Mary’s Widget company you read about earlier, the college student would not have been so successful in his attack if Frank and Mary had been running name servers on their own workstations. In the first case study, Mary’s cache would have been corrupted but it would not have caused problems for Frank. In the second case, the cache for the name server used by the mail server would have been corrupted, but, again, Frank would not have used the corrupted cache unless his name server consulted with the same one as the mail server.

The use of local name servers on workstations also may reduce total network traffic and aids in fault tolerance. If a network-wide name server goes down, it will not create any delays for information stored in the local name servers.

The use of local name servers will limit, not eliminate, risks. Local name servers are also subject to cache corruption. The reduced risk comes from fewer interactions with any single cache. You should be sure local name servers only process queries from the local machine to prevent an active attacker from directly contaminating their cache. Hiding the workstations behind a firewall will also help.

The simplest thing a name server administrator can do to prevent a DNS spoof from corrupting the name server cache is to have the most recent version of the operating system’s DNS name server software. The most common implementation of a DNS name server is BIND (Berkeley Internet Name Daemon) on Unix. Newer versions of BIND incorporate modifications made with a more security conscious attitude than older versions. For the most current version, consult the Web at http://www.dns.net.dnsrd/servers.html.