Tài liệu IP Behavior VI Domain Name System (DNS) pdf

8 - 1
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
1
IP Behavior VI
Domain Name System (DNS)
Hello again I am Judy Novak. If you are taking the IP Behavior series in successive webcasts, my
name and voice may be familiar to you by now since I am the author of a couple of previous
webcasts. I still work for Jacob and Sundstrom in the Computer Security and Incident Response
Team at the Army Research Lab as a Shadow analyst. Stephen Northcutt has graciously requested
that I author this webcast on the Domain Name System or DNS. I’d personally like to thank my
excellent technical editors Bill Ralph of Naval Surface Warfare Center and Hal Pomeranz of Deer
Run Associates.
What’s the big deal with DNS? Isn’t it basically used to translate a hostname to an IP number and
that’s it? Well sure, that is a big and important part of DNS, but it is much more. Having examined
traffic for over two years on a military network, we see much interest in our DNS servers from less-
than-upstanding citizens.
Our DNS servers are probably the most common targets of reconnaissance efforts. Your DNS server
is a cherished prize for a hacker to compromise, so they are going to see how vulnerable it is by
pounding on it for weaknesses. Some of the reasons that the DNS server is targeted are, first, this is a
good reconnaissance method of learning about all the DNS information in preparation for launching
an attack. Second, if an intruder can inject spurious DNS information in the local server, this can be
used as an attack on other hosts. Finally, UDP port 53, the port commonly associated with DNS
traffic, is often left open on packet filtering devices so that internal name servers can function.
After completion of this webcast, the student will have a good foundation of DNS theory and practical
application. You will be able to see how DNS queries are answered, how the DNS server interacts
with other DNS servers, how DNS can be used to discover information about a site, and ways that
DNS can be used for exploitation purposes. In short, this will aid you in doing network security to
analyze the nature of DNS traffic seen on the network.
8 - 2
IP Behavior VI – SANS GIAC LevelTwo

- ©2000, 2001
2
Objectives
• Explain DNS theory including:
– Client and server interaction
– Server to server interaction
– Primary and secondary servers
– Transport protocol used (TCP/UDP)
–WINS
• Intelligence gathering tools
• DNS - the dark side
The objectives of this webcast are to teach the underlying theory of DNS so the student can interpret
tcpdump output of DNS transactions and examine DNS events occurring on the network with some
insight about what is transpiring.
Specifically, we will examine how a DNS query is answered. DNS is different than a normal client
server application in this aspect. Typically, in client server applications such as telnet or ftp, the client
requests a connection to a desired server and the interaction is pretty much between those two hosts.
For DNS, however, when a client issues a DNS query, a DNS server will accept the query, perhaps
interact with one or more additional DNS servers, and when it receives the response to the query, it will
return it to the client.
We will look at the role of primary and secondary name servers and discuss the interaction between
them. Also, unlike other services, DNS can switch between UDP and TCP protocols depending on the
kind of DNS activity. We will briefly cover the way in which Windows hosts do hostname resolution.
We will also talk about some ways that others may use your DNS server to gather information about
the DNS server itself and hosts that the DNS server knows about. Finally, we will look at examples of
how DNS was used for malicious purposes.
8 - 3
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
3

Going places
www.sans.org
host.my.com
How do you go from your host to
www.sans.org?
Step 1: Resolve www.sans.org to
an IP number.
Step 2: Request a connection to
the resolved IP number.
The slide “Going places” supposes that you want to go to the SANS website, www.sans.org to see what
the latest offerings and postings of interest might be. You bring up your Netscape browser and enter
the URL . Seconds later, if you are not on a slow or congested network, you will
see the www.sans.org web page.
Remember that TCP/IP datagrams use IP numbers for all source and destination addresses. TCP/IP
does not use hostnames. However, we humans tend to remember hostnames far better than we
remember IP numbers so we speak in hostnames. It’s obvious that we need some kind of translation
mechanism between the way we reference hosts -- hostnames and the way TCP/IP must reference hosts
-- IP numbers.
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 number. Your
host needs this IP number to package into the datagram when it sends the connection request to
www.sans.org out on the network. We’ll examine this Step 1 process from the above slide in the next
several slides.
8 - 4
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
4
Client resolver
www.sans.
org

gethostbyname(www.sans.org)
host.my.com dns.my.com
Find the IP address
return IP address 167.216.133.33
resolver
name server
Continuing with the process of resolution from hostname www.sans.org to IP number, look at slide
“Client resolver”. Here, we see the host on which we have our Netscape browser, host.my.com
attempt resolution of www.sans.org.
Assuming that your host is not a name server, it is mostly passive throughout the resolution process. It
simply fires off the request for the translation, and resumes the process of connecting to the
www.sans.org web page after it receives a reply of the IP address. The workhorse behind the
resolution process is the DNS server which 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) This default DNS server is typically
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 hostname to an IP address. In this case, a gethostbyname call is
sent from host.my.com to the DNS server. This requests that the hostname www.sans.org be translated
to an IP address. The DNS server receives this request, processes it, and returns it to host.my.com.
8 - 5
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
5
DNS server resolution (part I)
dns.my.com
IP for www.sans.org
h.root-servers.net

Ask host server1.sans.org
Resuming our resolution journey on slide “DNS server resolution (part I)”, we see dns.my.com take
over the actual duties of finding the answer of the IP of www.sans.org. dns.my.com begins its search
with a root server to find the resolution.
In order to resolve external names, many times, your local name server must contact a root name
server. Root name servers maintain a mapping between domain names (sans.org) and the authoritative
name servers 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 numbers of the root servers to contact.
Obviously, the local name server must be pre-configured with a list of known root name servers. This
information is maintained by the InterNIC and may be downloaded from

8 - 6
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
6
DNS server resolution (part II)
dns.my.com
IP for www.sans.org
IP is 167.216.233.33
server1.sans.org
Continuing our resolution journey on slide “DNS server resolution (part II)”,
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.
dns.my.com then queries server1.sans.org and receives an authoritative answer, the IP number of
167.216.133.33.
8 - 7
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
7

Requisite picture of DNS
structure
root servers
arpa com edu gov mil net org jp
sans
www
www.sans.org
in-addr
If you look at the next slide “Requisite picture of DNS structure”, we need to interject a little theory
about the nature of DNS.
DNS is a globally distributed system which depends on the cooperative interaction of many DNS
servers to store records about “domains” and communicate with each other. A domain is a subset of
DNS records associated with a logical grouping. For instance, sans.org, is the domain that logically
contains all hosts that SANS might use.
The distributed system has been set up as a hierarchy of special servers known as root servers at the top
of the domain tree. These servers simply point to other DNS servers that may have dominion of DNS
records being sought. You are probably familiar with the top-level domains, those falling directly
under the root servers as .edu, .org, .com, .net, .mil, .gov to name the domestic domains. There are
additional top-level domains for foreign countries, such as .jp for Japan.
8 - 8
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
8
tcpdump output of resolution
host.my.com.1716 > dns.my.com.domain: 1+ (35)
dns.my.com.domain > h.root-servers.net.domain: 12420 (30) (DF)
h.root-servers.net.domain > dns.my.com.domain: 12420- 0/3/3
(153) (DF)
dns.my.com.domain > server1.sans.org.domain: 12421+ (30) (DF)
server1.sans.org.domain > dns.my.com.domain: 12421* 1/3/3

(172)
dns.my.com.domain > host.my.com.1716: 1* 1/3/3
(197) (DF)
= Client
= Server
Moving to slide “tcpdump output of resolution”, we can see what was happening on the network.
First we see host.my.com issue the request to resolve www.sans.org to dns.my.com. While tcpdump
prints the word “udp” for some UDP protocols, there is no such blatant clue in tcpdump DNS output.
Regardless of this omission, the above transactions used UDP. UDP was selected for the method of
transmission of the majority of DNS traffic since the queries and responses are often short and the
application itself can withstand lost or missing data. When anticipated data is not received, a new
query is reissued.
Next, dns.my.com attempts a connection to h.root-servers.net on port domain which is port 53. Note
that both source and destination ports are 53. We see h.root-servers.net respond back to dns.my.com on
source and destination ports 53 as well. We’ll discuss the numbers and notations found at the end of
each tcpdump record in the next slide. h.root-servers.net doesn’t have the answer to the query,
however it has a reference of another DNS server that may have the answer or may have a reference of
who may have the answer. Querying name servers for the IP of www.sans.org is a repeated process
that may yield a reference of another DNS server that may have the answer until finally a name server
is contacted that has the answer of the IP number.
Since h.root-servers referred dns.my.com to another DNS server, we next 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 is able to return to dns.my.com the IP number associated with
www.sans.org.
Before we continue with the resolution process, we need to digress on the next slide to explain the
tcpdump format for DNS records. It is a unique format and it contains necessary insight into what is
happening between connections.
8 - 9
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001

9
What is that strange
tcpdump notation?
dns.my.com.domain > h.root-servers.net.domain: 12420 (30) (DF)
h.root-servers.net.domain > dns.my.com.domain: 12420- 0/3/3 (153) (DF)
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.133.33
ns.BSDI.COM internet address = 205.230.225.16
ns.DELOS.COM internet address = 192.65.171.1
Let’s look at slide “What is that strange tcpdump notation?”. The first line of tcpdump output is the
query from dns.my.com to the root server. The first field that we haven’t seen before in conventional
tcpdump output is the number 12420 following the colon after domain. 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 is able to pair it to the request. Remember, dns.my.com is probably doing a lot of other
queries while it is doing ours 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, we have the don’t
fragment flag set so this datagram won’t be fragmented.
The response to query 12420 follows. There is a dash after the 12420 signifying that recursion was not
available. dns.my.com did not tell the root server that it wanted a response that referenced where the
next DNS server might be - it did not want the root server to pursue finding the response itself. Root
servers are very busy machines and cannot process queries in a recursive fashion as dns.my.com is
doing. They are only expected to give whatever knowledge they have about a good reference in pursuit
of the answer.
In the response from the root server, we see some strange output in the format of 0/3/3. This says that
there were 0 answer records - this means no IP was found, but 3 authoritative records were found and 3

additional records were found. An authoritative server is one that “owns” and maintains records for a
given domain. We’ve listed the 3 authoritative servers - server1.sans.org, ns.BSDI.COM, and
ns.DELOS.com. The 3 additional records are shown with the pairing of the authoritative DNS servers
with their IP addresses. By sending the IP numbers in additional records, we didn’t have to resolve the
hostnames sent to IP numbers. Any one of those DNS servers has authority for the sans.org domain
and will be able to answer the query. As you saw, dns.my.com selects the first one, server1.sans.org to
use for the final resolution.
8 - 10
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
10
tcpdump output of resolution (2)
dns.my.com.domain > server1.sans.org.domain: 12421+
(30) (DF)
server1.sans.org.domain > dns.my.com.domain: 12421*
1/3/3 (172)
dns.my.com.domain > host.my.com.1716: 1* 1/3/3
(197) (DF)
Moving to slide “tcpdump response output”, we examine the remainder of the tcpdump output from
the resolution process. 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. However, if it were not the authoritative name server, it would have to find the IP number by
recursively issuing queries to other name servers until an IP number was found.
server1.sans.org responds to the query. The asterisk means that this is an authoritative response. This
means that the record for www.sans.org is in the DNS database that server1.sans.org maintains. One
answer is returned - the answer in this case is the IP number of www.sans.org, 167.216.133.33. We
don’t see the IP in the tcpdump output, but that is what is in the payload of the UDP datagram. The 3
authority records and 3 additional records that we saw on the previous slide are returned here too.

Finally, once dns.my.com has the IP address, it delivers it to host.my.com, the original querier.
8 - 11
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
11
Caching – been there, done that
dns.my.com
What is IP of www.sans.org?
167.216.133.33
www.sans.org =
167.216.213.33
cached responses
Turning to slide “Caching - been there, done that”, we illustrate 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 don’t have to be repeated over and over again. This also potentially
will cut down on hits that other DNS servers take in helping you respond to queries. Chances are good
that the same hostname to IP resolution that was requested once may be requested again soon
thereafter.
So, if we were to ask for the www.sans.org web page again, the resolution process would be a little
different. Our host machine would still issue a gethostbyname call sending the argument of
www.sans.org. However, when dns.my.com received this request, it would check its cache as usual
before trying to resolve it. If everything is working as it should, dns.my.com would find the record
residing in cache and would return the IP number to host.my.com.
How long do cached records stay around on the DNS server? Well, it depends; each cached record
may have a different life span. It turns out that each response of a DNS resource record has a time to
live value. This time to live value is set by the responding DNS server and cached by the receiving
name server for the TTL time value. DNS servers that may update records often, may have lower time
to live values than relatively static servers.
8 - 12
IP Behavior VI – SANS GIAC LevelTwo

- ©2000, 2001
12
nslookup
• Tool that uses “resolver” software
• Allows you to make DNS queries and see responses
dns.my.com
host.my.com
nslookup www.sans.org
167.216.133.33
Next we look at a very helpful tool for using DNS in slide “nslookup”. Suppose you wanted to see the
responses host.my.com received from the resolutions it asked for. nslookup acts much as a DNS client
would, but displays the information so that you can see. In fact, that is how we got the authoritative
name server hostnames and IP numbers for the sans.org domain. This is a very helpful interactive tool
that can be used on a Unix or Windows NT host.
There are many more questions that can be asked of a DNS server than hostname. We examine some
of these in the next several slides. Using nslookup, we can formulate queries and see the kinds of
responses we get. There is a debug setting that allows you to see more of the data in the DNS message
that is sent and returned than just the query and response values. We’ll examine this too.
Finally, you can use another DNS server to do resolution for you. Instead of using your default DNS
server, you can direct your queries to another DNS server and see the responses.
8 - 13
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
13
Sample nslookup output
host.my.com% nslookup
Default Server: dns.my.com
Address: 192.168.4.4
> www.sans.org
Server: dns.my.com

Address: 192.168.4.4
Name: www.sans.org
Address: 167.216.133.33
> set debug
> www.sans.org
Let’s look at slide “Sample nslookup output” to get an idea of the capabilities of the nslookup tool.
We see host.my.com issue the nslookup command. We enter into the nslookup interactive process and
receive notification of the default DNS server being used to resolve our queries and its associated IP
number.
At the greater than prompt we enter www.sans.org to find its IP number. Again we get confirmation of
the DNS server and IP number being used to resolve the query. We see the answer below that of
167.216.133.33.
Next, we put nslookup in debug mode and reissue the query for www.sans.org. Debug mode give you
much more information about the query process.
(continued on the next slide)
8 - 14
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
14
Sample nslookup debug output
Got answer:
HEADER:
opcode = QUERY, id = 15135, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 3, additional = 3
ANSWERS:
-> www.sans.org
internet address = 167.216.133.33
ttl = 14373 (14373)
AUTHORITY RECORDS:

-> SANS.ORG
nameserver = server1.SANS.ORG
ttl = 14373 (14373)
-> SANS.ORG
nameserver = ns.BSDI.COM
ttl = 14373 (14373)
-> SANS.ORG
nameserver = ns.DELOS.COM
ttl = 14373 (14373)
Moving to slide “Sample nslookup debug output”, we see output from the debug option.
The debug output tells us that an answer was returned to our query. The query was issued with a DNS
identification number of 15135, and the response was error free. A recursive query was issued, and
recursion was available on the response. We asked one question (the IP number of www.sans.org) and
we received one answer - the IP number. We got 3 authority records and three additional records
delivered in the response. The answer delivered was the IP number 167.216.133.33 and it has a time to
live value of 14373. This is in seconds - computed in a more human readable format; this is just under
four hours. This means this record will be cached in dns.my.com for this amount of time. After that
my DNS server will expire the cached record and have to reissue the query.
This TTL value of 14373 represents the amount of time remaining before the resource record gets
flushed from the cache of dns.my.com. It may not reflect the original TTL value returned with the
query. In this instance, the original TTL value was 14400 from a query executed 23 seconds ago.
Next, all the authoritative DNS servers are listed for the sans.org domain. Any of the listed three DNS
servers has the database records for hosts in the sans.org domain.
(continued on the next slide)
8 - 15
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
15
Sample nslookup debug output(2)
ADDITIONAL RECORDS:

-> server1.SANS.ORG
internet address = 167.216.133.33
ttl = 134384 (134384)
-> ns.BSDI.COM
internet address = 205.230.225.16
ttl = 127742 (127742)
-> ns.DELOS.COM
internet address = 192.65.171.1
ttl = 127742 (127742)
------------
Non-authoritative answer:
Name: www.sans.org
Address: 167.216.133.33
Not all the debug output would fit on one slide so take a look at the next slide “Sample nslookup
debug output(2)”. The additional records are included here. This is the IP numbers associated with
the name servers. This is an optimizing benefit to have the IP numbers because it saves additional
DNS lookups.
Finally, we see the actual query parameter - www.sans.org and the answer in the form of the IP
number. Why do you think we received the message Non-authoritative answer? This means that we
didn’t receive the answer from any of the authoritative hosts listed in the previous slide. How could
that be? Remember this is the second time we queried for host www.sans.org in the nslookup process.
The first time we did, we didn’t have the debug option turned on. We turned the option on and then
issued the query for www.sans.org again.
So the first response was cached. When we asked the same question a few minutes later, the answer
was obtained from cache and not from the authoritative server. Retrieving the answer from cache, even
though it was previously from authoritative source, is not considered an authoritative answer.
8 - 16
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
16

Reverse lookups
Root servers
arpa
in-addr
167
216
233
33
IP number - 167.216.233.33
33.233.216.167.in-addr.arpa
How do you resolve
an IP number to a
host name?
Use the DNS
domain in-addr.arpa
to navigate the DNS
hierarchy.
org
0 255
0
0
0
255
255
255
We discuss resolving IP numbers to hostnames in the slide “Reverse lookups”. Occasionally, you’ll
be given an IP number and want to see if it resolves to a hostname. This is known as a gethostbyaddr
call made by the client resolver.
As we examined earlier in this webcast, DNS is a distributed hierarchy of responsibility and ownership
begins at the root servers and continues down in the DNS tree. We saw top level domain nodes such as

.org, .mil, .edu and so forth. A special domain has been reserved for resolution of IP numbers to
hostnames. At the top level domain, this is the arpa suffix. A second level domain follows known as
in-addr. Beneath this, the tree expands outward for the legal first octets in the IP number. For instance,
in the case of the IP for sans.www.org, the first octet is 167. Beneath this will follow a subtree with the
next node of 216, the second octet of the www.sans.org IP number. Following this logic, the 233 and
33 nodes for the final two octets fall below. We examine just this one subtree in this example, but this
spans all the possible IP numbers just as the other top level domains begin the expansion of all the
hostnames.
Resolutions of IP to hostname are known as reverse lookups. When we attempt a reverse lookup for
167.216.233.33, the application software reformats this as a query to 33.233.216.167.in-addr.arpa. We
reverse the order of the octets to conform to the hostname notation. For name www.sans.org, we
formulated the name by starting at the bottom of the DNS tree with node www, we moved up to node
sans and topped out at node org. Similarly, with the IP number, we must move from the most specific
to the most general.
8 - 17
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
17
Primary - Secondary name servers
Primary server Secondary server
• Primary server is the one that maintains zone maps
• Zone maps are the set of domain names for which DNS is the
authoritative nameserver
• Zone maps resident on primary server upon start-up
• Secondary server gets its zone maps from the primary server
zone maps
zone maps downloaded
Turning to slide “Primary - Secondary name servers”, we look at two different kinds of DNS servers.
Each domain has to have a primary server, one upon which database records of names and IP addresses
are maintained. Then, for redundancy sake, one or more secondary servers are often created in case the

primary server ever goes down. If there were no redundancy built in, if 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, all resolution of hosts in the domain whose DNS server was
down could not be accomplished. Secondary servers can share the load of responding to queries with
the primary name server.
DNS information is maintained on the primary server in flat text files. The secondary name servers
periodically contact the primary name server to see if any updates have been made for a particular
domain. If so, the secondary server downloads all information for that domain -- even if only one
record has been modified.
8 - 18
IP Behavior VI – SANS GIAC LevelTwo
- ©2000, 2001
18
Zone transfers
Primary Server
Evil Host
Legitimate Secondary Server
We’ll now examine how changes are propagated from the primary to the secondary name server on
slide “Zone transfers”. When the secondary server restarts or when it periodically queries the primary
server and finds updated records, a zone transfer is performed between the primary and secondary
servers.
This is simply a transfer of the zone maps or DNS records from the primary server to the secondary
server. Unlike most DNS transactions, this is done using TCP since there is a lot of data and reliable
delivery is important. The zone transfer seems like an innocuous process. Between the same domain
primary and secondary servers, it usually is. However, what if a hacker could do a zone transfer of
your domain data? This would give him or her all the IP numbers and hosts in your domain. This is
very valuable data that should not be readily available to anyone.
Obviously, we’d like to try to prevent this kind of misuse. There are a couple of ways that this can be
done. In versions of BIND 4.9.3 and later, there is a configuration parameter that allows the DNS
administrator to specify IP numbers or subnets that are authorized to do zone transfers.

If your version of BIND doesn’t support this feature, another option is to block inbound traffic to TCP
port 53. This will prevent transfers, but may block other legitimate data as well. However, if this is
your only option, it is preferable to prevent the zone transfer even at the expense of blocking other
legitimate data, as we will see on the next slide.