Note, however, that the plural was used when referring to authoritative name servers. The DNS standards require that data for each domain be replicated on separate computers with no common point of failure, meaning that the name servers with the duplicated data must not be attached to the same network or obtain electrical power from a common source. It seems unlikely that an attacker would be able to compromise all of the authoritative name servers for a given domain.

For this reason, it might seem that you could poll all authoritative name servers when making a query to look for a discrepancy. Unfortunately, one name server is typically designated as the primary authority and the others as secondary authority. The secondary name servers simply make a copy of the data in the primary on a periodic basis after the serial number on the data for a domain has changed. If the primary authoritative name server is compromised, all the secondary authoritative name servers will also contain invalid data after enough time has elapsed. Meanwhile, inconsistencies may simply indicate that the secondary has not copied legitimate changes to the data on the primary.

Efficiency Mechanisms: Downfall of DNS Security

The truly troubling part of the DNS security problem is that when a name server caches invalid data, the invalid data can remain in the cache for a very long time and can misdirect queries that are unrelated to the query that placed the data in the cache in the first place.

For example, suppose one query places the name of a domain and the name of its name server in the cache as well as the name of the name server and its address. All later queries for names in that domain will be referred to the earlier named name server at the earlier specified address. If either of these cached records is invalid, all subsequent queries for this domain will be directed to the wrong place. The responses to these misdirected queries will also be cached. A compromised name server may cause errors in the caches of uncompromised name servers that cause the uncompromised name server to provide invalid data to its clients.

Furthermore, a DNS name server can supply arbitrary information in the additional information section of a response to any query. Thus, it may provide a perfectly valid response to the original query, but arbitrary misinformation provided in the additional information section of the response will be cached by a name server that queries it.

Suppose, for example, that a server (not a name server) attempts to check on the name of a prospective client by making a query that forces the DNS system to do a reverse lookup on the address to find the DNS name of the prospective client. A compromised name server might provide an invalid response, which would seem to make the prospective client legitimate. When the server attempts to cross-check this information, the name server may respond with misinformation provided as additional information to the reverse query. If the server makes an iterative query instead, it will not cause immediate corruption of its name server’s cache when the compromised name server is not directly interacting with the local name server, but any client of the local name server may trigger a request that corrupts the cache of the local name server.

Case Study: A Passive Attack

Consider the case of Frank and Mary, who work at Widgets, Inc. Their company runs a name server to support their DNS domain, widget.com. Their workstations consult this name server when looking up the IP addresses of outside networks. One day, Mary is surfing the web and finds a reference to something that looks interesting at a site in the podunk.edu domain. Her web browser does a DNS query of the widget.com name server that forwards the query to the podunk.edu name server. The widget.com name server caches the reply from podunk.edu and supplies the requested IP address information to Mary’s web browser.

Unfortunately, the podunk.edu name server has been taken over by a malicious college student. When the reply goes back to the widget.com name server, additional information fields are attached. One of these contains the name “well.sf.ca.us,” the DNS name for the Well—an online service provider located in San Francisco. The additional information field says that this name is associated with yet another machine controlled by the malicious college student.

A little while later, Frank decides to Telnet to his account on well.sf.ca.us and is greeted with the usual login information and prompt. When he types in his user name and password, there is a brief pause, he is presented with his usual menus, and continues his work.

What has happened is that when Frank used Telnet, it made a DNS query of the widget.com name server. The widget.com name server found the entry for well.sf.ca.us in its cache and returned the IP address of the college student’s machine. Frank’s machine established a connection with the college student’s machine and it began the classic Trojan horse routine. The student’s machine provided the login prompt and stored up the user name and password. It then turned around and used a modified version of Telnet to connect to well.sf.ca.us and passed packets back and forth between it and Frank’s machine at Widgets, Inc. The Trojan horse created the illusion that Frank was directly connected to the Well and gave the college student the password for Frank’s account on the Well.