Topic: Local DNS Attack

Network Cyber Security Lab Report

<Netanel Shen> <318379492> <Software Engineering>
<Cybersecurity project> <b> <2025>

Submitted: <05/11/25>

1
1 Introduction
This lab taught me how attackers on the same network can trick the DNS system to
send users to fake websites. I learned how to sniff and spoof DNS packets and how
to poison the DNS server's cache with wrong IP addresses. The goal was to
understand how these attacks work and how to defend against them. DNS is super
important—if it's not secure, attackers can make users visit fake banking sites or steal
passwords. This lab showed me how that can happen and why DNS security really
matters.

Related articles:

• https://www.cloudflare.com/learning/dns/dns-cache-poisoning/

• https://www.paloaltonetworks.com/cyberpedia/what-is-a-dns-attack

The cloudflare article is no different than my introduction, whilst the palo alto also
explains related attack such as DNS hijacking, reflection, domain generation
algorithm etc'.

2 Lab Goal
The SEED Labs Local DNS Attack Lab helps students understand how the Domain
Name System (DNS) works and how attackers can abuse it in local networks. DNS is
like the phone book of the internet—it changes website names (like
www.example.com) into IP addresses that computers use to find each other. This
process happens behind the scenes every time someone visits a website. If someone
can trick DNS into giving the wrong IP address, they can send users to fake or
harmful websites. This is known as a DNS spoofing or cache poisoning attack.

In this lab, students set up a fake network using Docker containers to practice these
attacks safely. The setup includes four machines: a user, a local DNS server, and two
attacker machines. The attacker watches for DNS requests and then quickly sends a
fake answer before the real one arrives. If the fake answer gets accepted, the user
ends up on a fake website instead of the real one.

The lab teaches different attack techniques, such as sending fake answers directly
to the user or poisoning the DNS server’s cache so that everyone on the network
gets fake answers. Students also learn how to spoof entire domains by changing NS
(Name Server) records and how to add fake IP addresses to the Additional section
of DNS replies.

The lab also shows how tools like Scapy (a Python-based packet manipulation tool)
can be used to create and send fake DNS replies. Students learn how to write code
that listens for DNS queries and sends fake responses back.

2
Overall, this lab helps students learn how local DNS attacks work, why they are
dangerous, and what kind of security protections (like DNSSEC and randomization)
are needed to stop them. It’s a hands-on way to understand a real-world
cybersecurity threat.

3 Environment Set Up
• To perform the Local DNS Attack Lab, we used the SEED Ubuntu 20.04 VM, a
secure and pre-configured environment designed for cybersecurity
experiments. The lab simulates a network where a local attacker performs DNS
spoofing and cache poisoning attacks. The network includes four machines:
the attacker, a user, a local DNS server, and the attacker’s nameserver. These
machines all communicate over the subnet 10.9.0.0/24 as shown in the network
topology diagram.OS : SEED Ubuntu 20.04 VM

• Docker (Dockerfile- attacker NS, local DNS server, user)

• Docker compose (docker-compose.yml)

• Scapy

• BIND 09

Each role in the topology is implemented as a Docker container. The attacker

container is run in host network mode to enable packet sniffing across the
LAN. This allows the attacker to see DNS requests from the user container and
reply with spoofed DNS answers faster than the real server.

We used Dockerfiles to build each container (attacker, user, local DNS server,
attacker’s nameserver). Each Dockerfile installs required packages like BIND9,
Python3, and Scapy. The attacker container uses a shared folder (./volumes)
mounted via Docker volumes. This allows us to edit attack scripts from the
host VM and run them inside the container.

Network Topology

Here is the network diagram

representing the setup:

This environment simulates a

realistic scenario of local DNS
attacks and provides a safe way
to study, launch, and analyze DNS
spoofing and cache poisoning
techniques.

3
4 Methodology
The SEED Labs Local DNS Attack Lab aims to demonstrate how DNS spoofing and
cache poisoning attacks work on a local network. DNS (Domain Name System) is a
core protocol that maps human-readable domain names to IP addresses. In this lab,
we simulate a controlled environment to perform and analyze local DNS attacks.

The lab uses SEED Ubuntu 20.04 VM as the base operating system and Docker
containers to emulate four networked devices:

1. Attacker (10.9.0.1)

2. User (Victim) (10.9.0.5)

3. Local DNS Server (10.9.0.53)

4. Attacker’s Nameserver (10.9.0.153

The attacker container was configured in host network mode to allow packet
sniffing, since containers normally can't see other containers' traffic. Additionally, a
shared volume (./volumes:/volumes) allowed Python scripts to be easily edited from
the host VM and executed in the attacker container.

The BIND 9 DNS server was installed on the local DNS container. Important
configurations included:

• Disabling DNSSEC for simplicity

• Fixing source port to 33333

• Setting up a forward zone for attacker32.com to forward to the attacker's

nameserver

Task 1: Spoofing DNS Response to the

User

The first attack used Scapy to sniff DNS

requests from the user and send
spoofed responses. The attacker sniffed
for requests to www.example.com, then
crafted a fake response with a forged IP
like 1.2.3.4. The goal was to respond
faster than the real DNS server.

4
Task 2: DNS Cache Poisoning

This task targeted the local DNS server.

Instead of spoofing the user each time,
we sent a spoofed reply to the DNS
server itself. If successful, all future
queries for www.example.com would
return the attacker’s IP from the cache.

After the attack, the cache showed the

fake IP, and user queries were
redirected accordingly, even if the
attacker script wasn’t running anymore.

Task 3: Spoofing NS Records

Here, the attacker inserted a fake NS (Name Server) record into the Authority section
of the DNS reply:

Once cached, this made the local DNS trust the attacker's nameserver for all
subdomains of example.com. The attack had a broader effect: not just
www.example.com, but also mail.example.com, etc., would resolve to fake values if
queried.

5 Lab Results
Present the data or findings from your lab exercise. Use tables and graphs as
necessary to illustrate your results.

Show screen shots of the results of the attack and response that you performed.

Write 300-500 words.

6 Personal Reflection
From this lab, I learned how DNS works behind the scenes, how DNS cache
poisoning attacks are done, and how attackers can trick users into visiting
fake websites by sending spoofed DNS responses. I also learned how to use
tools like Scapy to sniff and spoof packets, and how the DNS server stores
records in its cache.

The hardest part for me was getting the spoofed response to arrive before
the real one. Sometimes the real DNS reply came too fast, so my fake packet

5
was ignored. It was also tricky to figure out the correct network interface
name for packet sniffing and spoofing inside the container.

The most interesting part was seeing how one fake DNS reply can poison the
DNS server's cache and affect all future requests. I was surprised how easy it
was to make the server believe a fake IP if everything was timed correctly.

To prevent these attacks in the real world, DNS servers should use random
source port numbers and random transaction IDs to make spoofing harder.
Also, DNSSEC (DNS Security Extensions) can be enabled to digitally sign DNS
data, so even if a fake reply is sent, the client can detect that it's not
authentic. Limiting who can access the DNS server from the network can also
help.

Overall, this lab helped me understand how DNS works and how dangerous it
can be if DNS servers are not protected correctly.

7 Conclusion
In this lab exercise, I explored how DNS cache poisoning works by setting up a local
DNS environment with Docker containers and launching spoofing attacks using
Scapy. I learned how attackers can intercept DNS queries and inject fake responses
to redirect users to malicious sites, and how such fake entries can be stored in the
DNS server’s cache. I successfully demonstrated direct spoofing to the user, cache
poisoning, and spoofing NS and additional records. One limitation I faced was
timing—my spoofed responses sometimes arrived too late, especially inside Docker
containers. To fix this, I had to artificially delay legitimate responses using the tc
command on the router. In future work, it would be useful to explore remote DNS
attacks and implement real-world protections like DNSSEC and source port
randomization to better understand how to defend against such threats.