Understanding DNS Name Servers

The DNS system is complex. To help you understand its structure, think of the DNS system as a distributed database consisting of records with three fields: name, address, and record type. The database is distributed; not all of the records are kept in a centralized location, and no record is kept in only one location. The database is not centralized because it would be impractical to do so—from a technical standpoint and from an administrative standpoint. Technically, such a centralized setup would place an incredible load on one machine, which would have to handle all the name-to-address queries for the entire Internet and create huge amounts of long-distance network traffic. Administratively, this centralized database setup would be horribly awkward to change because thousands of network administrators would need to be checked for authenticity and privileges each time one of them makes a change.

---

Note:  The four record types of interest in DNS names are as follows:

•  Canonical hostname to address mapping

•  Alias hostname to canonical hostname mapping

•  Domain name to name server name mapping

•  Address to hostname mapping other record types that also exist

---

The primary purpose of DNS is to break down the authority for a set of names into domains. Each domain is administered independently of each other domain. Each domain can create subdomains that are only loosely related to the domain and administered independently of each other. Each subdomain is responsible for a subset of the names of the whole domain. In turn, subdomains can create subsubdomains and so on. The term “subdomain” is a relative term between a domain and a domain that has control over a piece of the domain.

When a name server receives a query to resolve a name, it may make an authoritative reply based on data it keeps in its own portion of the database, or it may make a non-authoritative reply. Two types of non-local replies are possible: iterative or recursive. If the client asks for recursive resolution (the more common choice), the name server forwards the request to a name server it thinks is more likely to be authoritative than it is and then relays the reply back to the client along with information indicating where the authoritative answer was found. If the client asks for iterative resolution, the name server simply returns the address of the name server it would have forwarded the request to and lets the client query that name server directly.

Efficiency: Caching and Additional Information

Because name resolution is so frequent, efficiency is important. When a name server makes an authoritative response, either to an ordinary client host or another name server, the authoritative response includes a “time to live,” which amounts to a claim that the response will continue to be valid for a certain amount of time. When a name server receives a reply from another name server, it caches the reply for the amount of time specified by the “time to live.”

Some kinds of DNS replies will clearly lead to a follow-up query. For example, if a reply includes a record specifying the name of a name server for a domain, the client probably will soon make a query to find the address of that name server. Hence, a DNS reply not only has sections for specifying the question, answer, and authority of the answer, but also has a section for additional information. The name server caches additional information records along with the answer records so that it can handle the follow-up queries efficiently without further name server to name server queries.

How DNS Spoofing Can Happen

Suppose a name server somewhere on the Internet has been compromised by a security attack or is being controlled by an intruder. This name server will provide authoritative responses for some domain and all hosts on the Internet will trust those responses. The authoritative responses can direct clients looking up the names of servers to connect to servers under the control of the attacker rather than the legitimate servers. A falsified reverse address lookup can fool servers attempting to determine if the IP address of a prospective client corresponds to the name of an authorized client. Within the DNS system, absolutely nothing can be done about such a direct attack.

A standard attempt at a defense to a DNS spoofing attack is to cross-check all responses to reverse lookup queries by making a forward lookup query. That is, a server queries the DNS system with the IP address of a prospective client via a reverse lookup and receives the DNS name(s) of the prospective client. Then it takes the names and queries the DNS system for the address(es) that corresponds to the name. Cross-checking has become a standard technique with TCP wrapper systems.

Cross-checking may help if the attacker is clumsy and alters the name server files corresponding to reverse lookups, but not those corresponding to forward lookups. Because these tables are kept in separate files, they may also be kept on separate name servers. If the attacker has compromised only one of the two name servers, the cross-checking may discover the inconsistency. Because of potential abuses of the efficiency mechanisms in DNS, the name server may not discover the inconsistency.

Another attempt to stifle DNS spoofing is to make iterative rather than recursive resolution requests so that checks on consistency and authoritativeness can be made more carefully than the name servers themselves do. In particular, when a name server makes a non-authoritative response to an iterative query, it responds with the name of a name server more likely to be authoritative than itself. If the name server has been compromised, it may direct the iterative query to another compromised name server or it may claim authoritativeness when it does not have authoritativeness for the domain being queried. In such cases, a check on authoritativeness should, in principle, detect the attack.

A check on authoritativeness requires querying a root-level name server for the address of the name servers that are authoritative for the base domain of the DNS name. One must then ask the name server at that address for the address of the name server that is authoritative for the next component of the DNS name and so on. Such a procedure is clearly quite time-consuming and places considerable load on root-level name servers. Also, it does not help if an authoritative name server has become compromised; it only detects invalid claims to authority.