Step 1: Create zones. We need to create two zone entries in the DNS server by adding the following
contents to /etc/bind/named.conf. The first zone is for forward lookup (from hostname to IP), and
the second zone is for reverse lookup (from IP to hostname). It should be noted that the example.com
domain name is reserved for use in documentation, and is not owned by anybody, so it is safe to use it.
zone "example.com" {
type master;
file "/etc/bind/example.com.db";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/192.168.0.db";
};
Step 2: Setup the forward lookup zone file. The file name after the file keyword in the above zone
definition is called the zone file, and this is where the actual DNS resolution is stored. In the /etc/bind/
directory, create the following example.com.db zone file. Readers who are interested in the syntax of
the zone file, can refer to RFC 1035 for details.
$TTL 3D ; default expiration time of all resource records without
; their own TTL
@ IN SOA ns.example.com. admin.example.com. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D ) ; Minimum
@ IN NS ns.example.com. ;Address of nameserver
@ IN MX 10 mail.example.com. ;Primary Mail Exchanger
www IN A 192.168.0.101 ;Address of www.example.com
mail IN A 192.168.0.102 ;Address of mail.example.com
ns IN A 192.168.0.10 ;Address of ns.example.com
*.example.com. IN A 192.168.0.100 ;Address for other URL in
; the example.com domain
The symbol ‘@’ is a special notation representing the origin specified in named.conf (the string after
"zone"). Therefore, ‘@’ here stands for example.com. This zone file contains 7 resource records
(RRs), including a SOA (Start Of Authority) RR, a NS (Name Server) RR, a MX (Mail eXchanger) RR, and
4 A (host Address) RRs.
Step 3: Set up the reverse lookup zone file. To support DNS reverse lookup, i.e., from IP address to
hostname, we also need to set up the DNS reverse lookup file. In the /etc/bind/ directory, create the
following reverse DNS lookup file called 192.168.0.db for the example.net domain:
$TTL 3D
@ IN SOA ns.example.com. admin.example.com. (

8H
2H
4W
1D)
@ IN NS ns.example.com.
101 IN PTR www.example.com.
102 IN PTR mail.example.com.
10 IN PTR ns.example.com.
Step 4: Restart the BIND server and test. When all the changes are made, remember to restart the
BIND server. Now, go back to the user machine, and ask the local DNS server for the IP address of www.
example.com using the dig command. Please describe and explain your observations.
3 Lab Tasks (Part II): Attacks on DNS
The main objective of DNS attacks on a user is to redirect the user to another machine Bwhen the user tries
to get to machine Ausing A’s host name. For example, when the user tries to access the online banking, if
the adversaries can redirect the user to a malicious web site that looks very much like the main web site of
bank, the user might be fooled and give away password of his/her online banking account.
When a user types in http://www.example.net in his/her browsers, the user’s machine will issue
a DNS query to find out the IP address of this web site. Attackers’ goal is to fool the user’s machine with a
faked DNS reply, which resolves the hostname to a malicious IP address. There are several ways to launch
such a DNS attack. See Figure 2 for the illustration of the attack surface and read Chapter 15 of the SEED
book for detailed analysis of the attack surface.
We will launch a series DNS attacks on the example.net domain. It should be noted that we are
using example.net as our target domain, not the example.com. The latter one is already hosted by
our own local DNS server in the setup, so no DNS query will be sent out for hostnames in that domain.

3.1 Task 4: Modifying the Host File
The host name and IP address pairs in the HOSTS file (/etc/hosts) are used for local lookup; they take
the preference over remote DNS lookups. For example, if there is a following entry in the HOSTS file in the
user’s computer, the www.example.com will be resolved as 1.2.3.4 in user’s computer without asking
any DNS server:
1.2.3.4 www.example.net
If attackers have compromised a user’s machine, they can modify the HOSTS file to redirect the user
to a malicious site whenever the user tries to access www.example.com. Assume that you have already
compromised a machine, please try this technique to redirect www.bank32.com to any IP address that
you choose.
It should be noted that /etc/hosts is ignored by the dig command, but will take effect on the ping
command and web browser etc. Compare the results obtained before and after the attack.
3.2 Task 5: Directly Spoofing Response to User
In this attack, the victim’s machine has not been compromised, so attackers cannot directly change the DNS
query process on the victim’s machine. However, if attackers are on the same local area network as the
victim, they can still achieve a great damage.

When a user types the name of a web site (a host name, such as www.example.net) in a web browser,
the user’s computer will issue a DNS request to the DNS server to resolve the IP address of the host name.
After hearing this DNS request, the attackers can spoof a fake DNS response (see Figure 3). The fake DNS
response will be accepted by the user’s computer if it meets the following criteria:
1. The source IP address must match the IP address of the DNS server.
2. The destination IP address must match the IP address of the user’s machine.
3. The source port number (UDP port) must match the port number that the DNS request was sent to
(usually port 53).

4. The destination port number must match the port number that the DNS request was sent from.
5. The UDP checksum must be correctly calculated.
6. The transaction ID must match the transaction ID in the DNS request.
7. The domain name in the question section of the reply must match the domain name in the question
section of the request.
8. The domain name in the answer section must match the domain name in the question section of the
DNS request.
9. The User’s computer must receive the attacker’s DNS reply before it receives the legitimate DNS
response.
To satisfy the criteria 1 to 8, the attackers can sniff the DNS request message sent by the victim; they can
then create a fake DNS response, and send back to the victim, before the real DNS server does. Netwox
tool 105 provide a utility to conduct such sniffing and responding. We can make up any arbitrary DNS
answer in the reply packets. Moreover, we can use the “filter” field to specify what kind of packets to sniff.
For example, by using "src host 10.0.2.18", we can limit the scope of our sniffing to packets only
from host 10.0.2.18. The manual of the tool is described in the following:
Listing 1: The usage of the Netwox Tool 105
Title: Sniff and send DNS answers
Usage: netwox 105 -h data -H ip -a data -A ip [-d device]
[-T uint32] [-f filter] [-s spoofip]
Parameters:
-h|--hostname data hostname
-H|--hostnameip ip IP address
-a|--authns data authoritative nameserver
-A|--authnsip ip authns IP
-d|--device device device name
-T|--ttl uint32 ttl in seconds
-f|--filter filter pcap filter
-s|--spoofip spoofip IP spoof initialization type
While the attack program is running, on the user machine, you can run dig command on behalf of the
user. This command triggers the user machine to send out a DNS query to the local DNS server, which
will eventually send out a DNS query to the authoritative nameserver of the example.net domain (if the
cache does not contain the answer). If your attack is successful, you should be able to see your spoofed
information in the reply. Compare your results obtained before and after the attack.
3.3 Task 6: DNS Cache Poisoning Attack
The above attack targets the user’s machine. In order to achieve long-lasting effect, every time the user’s
machine sends out a DNS query for www.example.net the attacker’s machine must send out a spoofed
DNS response. This might not be so efficient; there is a much better way to conduct attacks by targeting the
DNS server, instead of the user’s machine.
When a DNS server Apollo receives a query, if the host name is not within the Apollo’s domain, it
will ask other DNS servers to get the host name resolved. Note that in our lab setup, the domain of our DNS
server is example.com; therefore, for the DNS queries of other domains (e.g. example.net), the DNS server Apollo will ask other DNS servers. However, before Apollo asks other DNS servers, it first looks
for the answer from its own cache; if the answer is there, the DNS server Apollo will simply reply with
the information from its cache. If the answer is not in the cache, the DNS server will try to get the answer
from other DNS servers. When Apollo gets the answer, it will store the answer in the cache, so next time,
there is no need to ask other DNS servers. See Figure 3.
Therefore, if attackers can spoof the response from other DNS servers, Apollo will keep the spoofed
response in its cache for certain period of time. Next time, when a user’s machine wants to resolve the same
host name, Apollo will use the spoofed response in the cache to reply. This way, attackers only need to
spoof once, and the impact will last until the cached information expires. This attack is called DNS cache
poisoning.
We can use the same tool (Netwox 105) for this attack. Before attacking, make sure that the DNS
Server’s cache is empty. You can flush the cache using the following command:
$ sudo rndc flush
The difference between this attack and the previous attack is that we are spoofing the response to DNS
server now, so we set the filter field to "src host 192.168.0.10", which is the IP address of the
DNS server. We also use the ttl field (time-to-live) to indicate how long we want the fake answer to stay
in the DNS server’s cache. After the DNS server is poisoned, we can stop the Netwox 105 program. If
we set ttl to 600 (seconds), then DNS server will keep giving out the fake answer for the next 10 minutes.
Note: Please select the raw in the spoofip field; otherwise, Netwox 105 will try to also spoof the
MAC address for the spoofed IP address. To get the MAC address, the tool sends out an ARP request, asking
for the MAC address of the spoofed IP. This spoofed IP address is usually the IP address of an external DNS
server, which is not on the same LAN. Therefore, nobody will reply the ARP request. The tool will wait
for the ARP reply for a while before going ahead without the MAC address. The waiting will delay the tool
from sending out the spoofed response. If the actual DNS response comes earlier than the spoofed response,
the attack will fail. That’s why you need to ask the tool not to spoof the MAC address.
You can tell whether the DNS server is poisoned or not by observing the DNS traffic using Wireshark
when you run the dig command on the target hostname. You should also dumping the local DNS server’s
cache to check whether the spoofed reply is cached or not. To dump and view the DNS server’s cache, issue
the following command:
$ sudo rndc dumpdb -cache
$ sudo cat /var/cache/bind/dump.db
3.4 Task 7: DNS Cache Poisoning: Targeting the Authority Section
In the previous task, our DNS cache poisoning attack only affects one hostname, i.e., www.example.net.
If users try to get the IP address of another hostname, such as mail.example.net, we need to launch
the attack again. It will be more efficient if we launch one attack that can affect the entire example.net
domain.
The idea is to use the Authority section in DNS replies. Basically, when we spoofed a reply, in addition
to spoofing the answer (in the Answer section), we add the following in the Authority section. When this
entry is cached by the local DNS server, ns.attacker32.com will be used as the nameserver for future
queries of any hostname in the example.net domain. Since attacker32.com is a machine controlled
by attackers, it can provide a forged answer for any query.
;; AUTHORITY SECTION:
example.net. 259200 IN NS attacker32.com.

The purpose of this task is to conduct such as an attack. You need to demonstrate that you can get
the above entry cached by the local DNS server. After the cache is poisoned, run a dig command on any
hostname in the example.net domain, and use Wireshark to observe where the DNS query goes. It
should be noted that the attacker32.com this machine is not set up to serve as a DNS server. Therefore, you will not be able to get a answer from it,
but your Wireshark traffic should be able to tell you whether your attack is successful or not.
You need to use Scapy for this task. See the Guideline section for a sample code.
3.5 Task 8: Targeting Another Domain
In the previous attack, we successfully poison the cache of the local DNS server, so attacker32.com
becomes the nameserver for the example.com domain. Inspired by this success, we would like to extend
its impact to other domain. Namely, in the spoofed response triggered by a query for www.example.net,
we would like to add additional entry in the Authority section (see the following), so attacker32.com
is also used as the nameserver for google.com.
;; AUTHORITY SECTION:
example.net. 259200 IN NS attacker32.com.
google.com. 259200 IN NS attacker32.com.
Please use Scapy to launch such an attack on your local DNS server; describe and explain your observa-
tion. It should be noted that the query that we are attacking is still the query to example.net, not one to
google.com.
3.6 Task 9: Targeting the Additional Section
In DNS replies, there is section called Additional Section, which is used to provide additional information.
In practice, it is mainly used to provide IP addresses for some hostnames, especially for those appearing in
the Authority section. The goal of this task is to spoof some entries in this section and see whether they
will be successfully cached by the target local DNS server. In particular, when responding to the query for
www.example.net, we add the following entries in the spoofed reply, in addition to the entries in the
Answer section:
;; AUTHORITY SECTION:
example.net. 259200 IN NS attacker32.com.
example.net. 259200 IN NS ns.example.net.
;; ADDITIONAL SECTION:
attacker32.com. 259200 IN A 1.2.3.4 ¿
ns.example.net. 259200 IN A 5.6.7.8 ¡
www.facebook.com. 259200 IN A 3.4.5.6 ¬
Entries ¿and ¡are related to the hostnames in the Authority section. Entry ¬is completely irrelevant
to any entry in the reply, but it provides a “gracious” help to users, so they do not need to look up for the IP
address of Facebook. Please use Scapy to spoof such a DNS reply. Your job is to report what entries will be
successfully cached, and what entries will not be cached; please explain why.
3.7 What’s Next
In the DNS cache poisoning attack of this lab, we assume that the attacker and the DNS server are on the
same LAN, i.e., the attacker can observe the DNS query message. When the attacker and the DNS serverare not on the same LAN, the cache poisoning attack becomes much more challenging. If you are interested
in taking on such a challenge, you can try our “Remote DNS Attack Lab”.
4 Guideline
You need to use Scapy for several tasks in this lab. The following sample code shows how to sniff a DNS
query and then spoof a DNS reply, which contains a record in the Answer section, two records in the
Authority section and two records in the Additional section.
#!/usr/bin/python
from scapy.all import *
def spoof_dns(pkt):
if (DNS in pkt and ’www.example.net’ in pkt[DNS].qd.qname):
# Swap the source and destination IP address
IPpkt = IP(dst=pkt[IP].src, src=pkt[IP].dst)
# Swap the source and destination port number
UDPpkt = UDP(dport=pkt[UDP].sport, sport=53)
# The Answer Section
Anssec = DNSRR(rrname=pkt[DNS].qd.qname, type=’A’,
ttl=259200, rdata=’10.0.2.5’)
# The Authority Section
NSsec1 = DNSRR(rrname=’example.net’, type=’NS’,
ttl=259200, rdata=’ns1.example.net’)
NSsec2 = DNSRR(rrname=’example.net’, type=’NS’,
ttl=259200, rdata=’ns2.example.net’)
# The Additional Section
Addsec1 = DNSRR(rrname=’ns1.example.net’, type=’A’,
ttl=259200, rdata=’1.2.3.4’)
Addsec2 = DNSRR(rrname=’ns2.example.net’, type=’A’,
ttl=259200, rdata=’5.6.7.8’)
# Construct the DNS packet
DNSpkt = DNS(id=pkt[DNS].id, qd=pkt[DNS].qd, aa=1, rd=0, qr=1, ¿
qdcount=1, ancount=1, nscount=2, arcount=2,
an=Anssec, ns=NSsec1/NSsec2, ar=Addsec1/Addsec2)
# Construct the entire IP packet and send it out
spoofpkt = IPpkt/UDPpkt/DNSpkt
send(spoofpkt)
# Sniff UDP query packets and invoke spoof_dns().
pkt = sniff(filter=’udp and dst port 53’, prn=spoof_dns)
Line ¿constructs the DNS payload, including DNS header and data. Each field of the DNS payload is
explained in the following:
• id: Transaction ID; should be the same as that in the request.• qd: Query Domain; should be the same as that in the Request.
• aa: Authoritative answer (1 means that the answer contains Authoritative answer).
• rd: Recursion Desired (0 means to disable Recursive queries).
• qr: Query Response bit (1 means Response).
• qdcount: number of query domains.
• ancount: number of records in the Answer section.
• nscount: number of records in the Authority section.
• arcount: number of records in the Additional section.
• an: Answer section
• ns: Authority section
• ar: Additional section
5 Submission
You need to submit a detailed lab report, with screenshots, to describe what you have done and what you
have observed. You also need to provide explanation to the observations that are interesting or surprising.
Please also list the important code snippets followed by explanation. Simply attaching code without any
explanation will not receive credits.