●DNS servers can provide a lot of reconnaissance information about hosts in preparation for launching an attack of a targeted network.

●DNS is used to resolve host names and IP addresses; so if a hacker can dupe a DNS server or actually seize control of a DNS server, she can manipulate name or address translations for malicious purposes. Often, weak methods of authentication rely on a host having a particular host name or IP address. If normal translations can be subverted, authentications can be corrupted.

●DNS servers are accessible and information sharing entities. The port commonly associated with DNS traffic, UDP port 53, is often left open on packet-filtering devices so that internal name servers can function.

This chapter covers these topics along with DNS theory and practical applications. You learn how DNS queries are answered, how DNS servers interact with other DNS servers, how DNS can be used to discover information about a site, and ways that DNS can be used for exploit purposes. In short, this information will aid you in applying network security and analyzing the nature of DNS traffic seen on the network.

Back to Basics: DNS Theory

Again, TCPdump is enlisted to help explain and visualize what occurs with different types of DNS transactions. Specifically, this section examines how a DNS query is issued and answered. DNS differs from a normal client/server application, such as telnet, where the client requests a connection to a desired server and the interaction is between those two hosts. For DNS, however, when a client issues a DNS query, a DNS server accepts the query, perhaps interacts with one or more additional DNS servers, and then returns the response to the client.

This section looks at the structure of DNS as a distributed system, and it examines host name to IP address resolution. It also discusses the role of master (formerly known as primary) and slave (formerly known as secondary) name servers and discusses the interaction between them. You learn that unlike other services, DNS can switch between UDP and TCP protocols,

depending on the kind of DNS activity.

The Structure of DNS

DNS is a globally distributed system that depends on the cooperative interaction of many DNS servers to store records about "domains" and to communicate with each other. A domain is a subset of DNS records associated with a logical grouping. For instance, sans.org is a collection of records containing IP addresses, host names, name servers, and more associated with the sans.org domain. Figure 6.1 depicts the hierarchical nature of DNS.

Figure 6.1. DNS, the pyramid scheme.

Logically, the top node of the DNS tree is known as root—designated by the period (.). Functionally, this is represented by root servers that can act as the starting point for DNS resolutions. These servers just point to other DNS servers that might have dominion over the DNS records being sought. You are probably familiar with the top-level domains, those falling directly under the root servers (the long-established .edu, .org, .com, .net, .mil, and .gov; and the recently established .aero, .biz, .coop, .info, .museum, .name, and .pro, to name the domestic domains). There are additional top-level domains for foreign countries, such as .jp

for Japan.

Steppin' Out on the Internet

Suppose that you want to visit www.sans.org, which is the home page for the System Administration, Networking, and Security (SANS) Institute. You enter www.sans.org in your browser, and seconds later you see the www.sans.org page.

Now, remember that IP datagrams use IP addresses for all source and destination addresses. IP knows nothing about host names. The human mind is more likely to remember that the capital of Florida is Tallahassee, than it is to remember the value of pi to 10 fractional digits is 3.1415926536, even though both take 11 characters (excluding the decimal) to represent. Names have more order and less randomness than numbers, so you tend to remember them better. This is why you speak in host names rather than IP addresses. It is apparent that some kind of translation mechanism is required between the way you reference hosts (via host

names) and the way TCP/IP must reference hosts (via IP addresses).

So, how did this translation from www.sans.org to an IP address mysteriously occur behind the scenes? Before you could even send out a request to www.sans.org, your host had to

know an IP address. Your host needs this IP address to insert into the datagram when it sends the connection request to www.sans.org out on the network. The following section unveils

this somewhat transparent process.

Recursive Versus Iterative Queries

DNS queries come in two different varieties: recursive and iterative. A recursive query requires a name server to find the answer to the query itself. In other words, it might query name servers, such as root name servers that do not know the answer to the query but know references of name servers that possibly have the answer to the query. The name server must follow all the references until it finds a name server that has the answer. The bottom line is that a recursive query asks the queried DNS server to be the workhorse and finds an answer while the querying DNS server waits for the answer or performs unrelated queries.

An iterative query asks a name server to fetch the answer to a query. If the name server doesn't have the answer, it returns to the querying name server a reference of another name server that possibly has the answer to the query. The queried name server does not pursue finding the answer; the querying name server must pursue finding the answer to the query itself.

DNS Resolution Process

Figure 6.2 shows the beginning of the process of resolution from host name www.sans.org to IP

address.

Figure 6.2. Client resolver, the handoff.

You see your browser is on host.my.com and it attempts resolution of www.sans.org.

Assuming that your host is not a name server, it is mostly passive throughout the resolution

process. It just fires off the request for the translation and resumes the process of connecting to the www.sans.org page after it receives a resolution of the IP address. The workhorse

behind the resolution process is the DNS server that is queried (in this case, dns.my.com). Generally, a default name server is chosen at the time the operating system is installed on a given client machine. On UNIX machines, the information is stored in the file /etc/resolv.conf. The DNS server is set as a TCP/IP property in the Network portion of the Control Panel for Windows hosts. This default DNS server typically is managed locally and is located somewhere on your organization's intranet. dns.my.com is this site's DNS server.

On the client host, the TCP/IP applications, such as telnet, FTP, Netscape, or Internet Explorer, call "resolver" library routines to obtain DNS resolution. When you requested www.sans.org,

application software issued a call to resolve the host name to an IP address. In this case, a

gethostbyname call is sent from host.my.com to the DNS server. This requests host name translation of www.sans.org to an IP address. The DNS server receives this request,

processes it, and returns it to host.my.com.

Figure 6.3 shows the second part of the resolution journey after leaving host.my.com. You see dns.my.com assumes the actual task of finding the answer of the IP of www.sans.org. For

simplicity of theory (although this might be perceived as adding complexity to the actual resolution process), assume that dns.my.com knows nothing about www.sans.org or any

other host in the .org domain. dns.my.com begins its search with a DNS root server to find the resolution.

Figure 6.3. DNS server resolution, the cry for help.

If a DNS server has to resolve an unknown external host name and it has no knowledge of the host's associated domains, it must contact a root name server. Root name servers are more than just a starting point—they maintain a mapping between domain names (sans.org) and the authoritative name servers—DNS servers that maintain DNS records for those domains.

When the local name server, dns.my.com, asks a root name server for the IP address of www.sans.org, it gets back a referral to the name servers for sans.org. You might ask how

dns.my.com knows the names and IP addresses of the root servers to contact. Obviously, the local name server must be preconfigured with a list of known root name servers. This information is maintained by the InterNIC and may be downloaded from

ftp://ftp.rs.internic.net/domain/named.ca.

Continuing the resolution adventure, the root server lets dns.my.com know where to continue

its search. The root server has returned a referral to the name server server1.sans.org as an authoritative name server for www.sans.org. Figure 6.4 depicts dns.my.com querying

server1.sans.org and receiving an authoritative answer, the IP address of 12.33.247.6.

Figure 6.4. DNS server resolution, from the horse's mouth