Writeup · Aug 12, 2026
DNS Spoofing in a Lab: What Scapy Teaches You About Trust
Defensive lessons from an authorized Scapy DNS-spoofing lab: packet flow, race conditions, detection signals, and the distinct roles of DNSSEC, DoT, and DoH.
I built a custom DNS-spoofing lab with Scapy to study how ARP manipulation and
forged DNS responses interact on a local network. The project is documented in
full-custom-dns-spoofer-with-scapy.
This work was performed only in an isolated, authorized lab. Intercepting or altering traffic on a network without explicit permission is unethical and may be illegal.
Lab boundary and packet flow
The environment used two virtual machines on a host-only network: a Linux client and a lab router running the interception code. No production or third-party network was in scope.
Linux client
│ 1. DNS query
▼
Lab router / Scapy interceptor ──────► Upstream resolver
│ │
│ 2. Forged response │ Legitimate response
└──────────────────────────────────┘
response race
The exercise made one point especially clear: crafting a DNS answer is only one part of the system. A successful man-in-the-middle (MITM) position also depends on maintaining the layer-2 path, handling packet forwarding correctly, and observing the race between a forged reply and the legitimate resolver response.
What the lab demonstrated
Traditional DNS responses are not inherently authenticated. A client that accepts an unauthenticated response can be misdirected if an attacker is able to observe or influence the relevant network path.
The defensive technologies often discussed beside DNS solve different problems:
- DNSSEC provides data-origin authentication and integrity for signed DNS data; it does not provide confidentiality.
- DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt DNS transport between the client and its configured resolver. They do not, by themselves, authenticate the zone data in the way DNSSEC does.
These controls can complement one another, but they are not interchangeable.
Detection opportunities
Defenders can look for signals at several layers:
- unexpected or rapidly changing ARP mappings, especially for the default gateway;
- duplicate IP-to-MAC associations observed by network monitoring;
- DNS answers that conflict across resolvers or arrive with abnormal timing;
- sudden changes in resolver configuration or encrypted-DNS endpoints;
- certificate warnings or TLS hostname mismatches after an unexpected DNS answer.
No single signal proves DNS spoofing. Correlating endpoint, switch, resolver, and network telemetry provides much stronger evidence than relying on one local cache.
Practical takeaways
- Map the complete packet path before reasoning about an application-layer symptom.
- Treat local-network trust as an assumption that must be tested and monitored.
- Use encrypted resolver transport and DNSSEC validation for their intended, distinct protections.
- Design lab tooling with an explicit authorization boundary and document that boundary beside the code.