TCPdump Output of Resolution

You can examine the traffic that this DNS request generated by observing the TCPdump output

that follows:

host.my.com.1716 > dns.my.com.53: 1+ (35) dns.my.com.53 > h.root-servers.net.53: 12420 (30) (DF)

h.root-servers.net.53 > dns.my.com.53: 12420- 0/3/3 (153) (DF) dns.my.com.53 > server1.sans.org.53: 12421+ (30) (DF)

server1.sans.org.53 > dns.my.com.53: 12421* 1/3/3 (172) dns.my.com.53 > host.my.com.1716: 1* 1/3/3

(197) (DF)

First, host.my.com (the client exchanges from host.my.com are in bold) issues the request to resolve www.sans.org to dns.my.com. TCPdump analyzes DNS at the application level, which

is why you don't see the word udp embedded in the output even though this is UDP. UDP is

the protocol selected for the transmission of the majority of DNS traffic because the queries and responses are often short and the application itself can tolerate lost data. When anticipated data is not received, the DNS query is reissued.

Next, dns.my.com attempts a connection to h.root-servers.net on port 53. Notice that both source and destination ports are 53. h.root-servers.net responds back to dns.my.com using source and destination ports 53 as well. A discussion of the numbers and notations found at the end of each TCPdump record is found in the next section, "Strange TCPdump Notation." h.rootservers.net does not have the answer to the query. It has a reference of another DNS server

that either has the answer or has a reference of who might have the answer. Querying name servers for the IP of www.sans.org is an iterative process that yields a reference of another

DNS server that might have the answer. This process repeats until contacting a name server that has the IP address answer.

Because h.root-servers referred dns.my.com to another DNS server, in the third line of the

preceding output, you see dns.my.com query this server, server1.sans.org, for the IP for www.sans.org. server1.sans.org happens to "own" the DNS record for www.sans.org and

can return the IP address associated with www.sans.org to dns.my.com. At long last,

dns.my.com delivers the response to host.my.com.

TCPdump has a unique format that contains necessary insight into what is happening between DNS connections. Look at the next section to help you decipher the TCPdump output.

Strange TCPdump Notation

Look at the exchange between dns.my.com and h.root-servers.net that follows: dns.my.com.53 > h.root-servers.net.53: 12420 (30) (DF)

h.root-servers.net.53 > dns.my.com.53: 12420- 0/3/3 (153) (DF)

The first line of TCPdump output is the query from dns.my.com to the root server. The first field that you have not seen before in conventional TCPdump output is the number 12420, following the colon after destination port 53. This is the DNS identification number. It is a unique identifying number that a DNS server or client uses to match a query and response. dns.my.com issues the request to the root server with the number 12420, and when it receives a response, it can pair it to the request. You have to be aware that a busy dns.my.com is probably doing a lot of other queries while it is doing yours, so it has to be able to match multiple queries with responses. The length of the UDP payload (not including the IP or UDP headers) is 30 bytes. And, the Don't Fragment (DF) flag is set so that this datagram won't be fragmented.

The response to query 12420 follows. A dash after 12420 signifies that recursion was not desired. This means that dns.my.com told the root server that it wanted a response that referenced where the next DNS server is—it did not want the root server to pursue finding the response itself.

Root servers are very busy computers, processing many initial DNS requests, and they cannot process queries in a recursive fashion like dns.my.com can. Root servers are only expected to give whatever knowledge they have about a good reference in pursuit of the answer. If you were hopelessly lost in a city somewhere and came across a policeman directing traffic at a busy intersection, you would know better than to ask him directions to Aunt Sadie's place. If you had the poor sense to ask, the best you could hope for is a general hasty reference to a gas station that could give you better directions.

In the response from the root server, you see some strange output in the format of 0/3/3. This says that there were zero answer records, meaning no IP address was found, but three authority records were found and three additional records were found. An authoritative server is one that "owns" and maintains records for a given domain. You don't see this in the TCPdump output, but the three authoritative servers (server1.sans.org, ns.BSDI.COM, and ns.DELOS.com) and the three additional records are shown with the pairing of the authoritative DNS servers with their IP addresses.

AUTHORITY RECORDS

sans.org	nameserver = server1.sans.org
sans.org	nameserver = ns.BSDI.COM
sans.org	nameserver = ns.DELOS.COM

ADDITIONAL RECORDS
server1.sans.org	Internet address = 167.216.198.40
ns.BSDI.COM	Internet address = 206.196.44.241
ns.DELOS.COM	Internet address = 65.102.83.117

The section, "Using DNS for Reconnaissance," shows you how to use the nslookup command to discover this information. By sending the IP addresses in additional records, when using the returned authoritative name servers, subsequent resolutions are unnecessary to translate those returned host names to IP addresses. Any one of those DNS servers has authority for the sans.org domain and can answer the query. As you saw, dns.my.com selects the first one, server1.sans.org, to use for the final resolution.

Finally, examine the remainder of the TCPdump output from the resolution process: dns.my.com.53 > server1.sans.org.53: 12421+ (30) (DF)

server1.sans.org.53 > dns.my.com.53: 12421* 1/3/3 (172) dns.my.com.53 > host.my.com.1716: 1* 1/3/3

(197) (DF)

dns.my.com has been informed that there are several authoritative servers, and it selects the first one, server1.sans.org, for resolution. It issues a new query 12421 and asks for recursion, noted by the plus sign. Essentially, dns.my.com has tasked server1.sans.org to find the IP

address. In this case, server1.sans.org is an authoritative name server for www.sans.org, so

it can answer the query itself. If it were not the authoritative name server, however, it would be asked to find the IP address by recursively issuing queries to other name servers until an IP address was found. Not all DNS servers are configured to perform recursive queries; so even though recursion might be desired, it is not necessarily done.

server1.sans.org responds to the query. The asterisk means that this is an authoritative response. This says that the record for www.sans.org is in the DNS database that

server1.sans.org maintains. One answer is returned—in this case, the IP address of www.sans.org, 12.33.247.6. You do not see the IP in the TCPdump output, but that is what

is in the payload of the UDP datagram. The three authority records and three additional records that were previously discussed are returned here too. Lastly, after dns.my.com has the

IP address, it returns it to host.my.com, the original querier.

Caching: Been There, Done That

This section briefly explains what happens to received responses. DNS servers cache or save responses that they receive. This makes the resolution process more efficient if the same DNS queries do not have to be repeated over and over again. This also potentially reduces the number of hits that other DNS servers take responding to queries. Chances are pretty good that the same host name to IP resolution that was requested once may be requested again soon thereafter. But, as you will soon see in the section, "Cache Poisoning," these savings, gained by caching responses, will open up some security risks if cached responses are not authentic

and valid.

If you were to ask for the www.sans.org web page again soon after the first request, the

resolution process would differ a little. Your host still issues a gethostbyname call to resolve the IP address for www.sans.org. When dns.my.com receives this request, however, it

checks its cache as usual before trying to resolve it. If everything is working correctly, dns.my.com finds the record residing in cache and returns the IP address to host.my.com. How long do cached records stay around on the DNS server? Well, it depends. Each cached record might have a different life span. It turns out that each response of a DNS resource record has a DNS time-to-live (TTL) value. Don't confuse this TTL value with the IP header TTL. They represent two very different and distinct functions. The DNS TTL value is set by the responding DNS server and cached by the receiving name server for the TTL time value. DNS servers that update records often are more likely to have lower TTL values than relatively static servers have.

Berkeley Internet Name Daemon

Berkeley Internet Name Daemon (BIND) is the de facto standard DNS implementation in use on the Internet today. Older versions of BIND are 4.x.x, whereas the more current versions are 8.x.x and 9.x.x. When you observe DNS servers that communicate with both source and destination ports of 53, it is usually indicative of the default behavior of BIND 4.x.x. By default, BIND versions 8 and later assign an ephemeral source port greater than 1023 in a querying DNS server datagram, similar to the behavior that you witnessed with other client applications, such as telnet.

However, BIND versions 8 and later can be configured to mimic version 4 behavior by using a default source port of 53. This is done using the query-source address * port 53 configuration file substatement. Some sites find that this configuration better suits existing firewall/router access rules.

Reverse Lookups

Occasionally, you will be given an IP address and want to see whether it resolves to a host name. This is done via a gethostbyaddr call by the client resolver.

Remember, DNS is a distributed hierarchy of responsibility, and resolution begins at the root

node and continues down in the DNS tree.You saw top-level domain nodes, such as .org, .mil,

.edu, and so forth. A special domain has been reserved for resolution of IP addresses to host names. At the top-level domain, this is the arpa suffix. A second-level domain follows, known

as in-addr. The tree expands outward beneath this for the legal first octets in the IP address, as you see in Figure 6.5. In the case of the IP for www.sans.org, for instance, the first octet is

12. Beneath this follows a subtree with the next node of 33, the second octet of the www.sans.org IP address. Continuing with this logic, the 247 and 6 nodes for the final two

octets fall below. Only this subtree is examined in this example, but this subtree spans all the possible IP addresses just as the other top-level domains begin the expansion of all the host names.

Figure 6.5. Reverse lookups, IP address to host name.

Resolutions of IP to host name are known as reverse lookups. When DNS attempts a reverse lookup for 12.33.247.6, the application software reformats this as a query to 6.247.33.12.in-

addr.arpa. The order of the octets is reversed to conform to the host name notation. For name www.sans.org, the name is formulated by starting at the bottom of the DNS tree with node

www, moving up to node sans, and topping out at node org. Similarly, with the IP address,

you must move from the most specific to the most general.

Master and Slave Name Servers

Each domain must have a master server, upon which database records of names and IP addresses are maintained. Then, for redundancy sake, one or more slave servers are often created in case the master server ever goes down. If there is no redundancy built in and the only DNS server for a particular domain were to go down, no queries could be answered for hosts in that domain. Unless entries were cached at other DNS sites, resolution of hosts in the domain whose DNS server was down could not be accomplished. Slave servers can share the load of responding to queries with a fully functioning master name server.

DNS information is maintained on the master server in flat text files. The slave name servers periodically contact the master name server to see whether any updates have been made for a particular domain. If so, the slave servers with older versions of BIND download all information for that domain, even if only one record has been modified. Newer versions of BIND will allow incremental updates that will download only changed records.