Skip to content

🔓 Project 04 — DNS Cache-Poisoning Attack Lab

Network Security

View the live site — ijk37.com

Project 04: DNS Cache-Poisoning Attack Lab

Home All Projects Notes Quiz

Type: Attack lab (Linux VMs) Modules: 06 (DNS & DNS Security) Difficulty: ⭐⭐⭐⭐

🎯 Objective

Set up a local caching DNS resolver and successfully poison its cache with a forged response, so it returns an attacker-controlled IP address for a legitimate domain — without ever compromising the real authoritative server.

🛠️ Setup

Three Linux VMs on the same virtual network:

VM Role Notes
Victim Resolver Runs a caching DNS resolver (e.g. BIND in recursive mode) Configured to use the "Authoritative" VM for a test zone
Authoritative The legitimate, "real" name server for a test domain (e.g. example32.com) Represents the domain the attacker wants to hijack
Attacker Runs a Scapy script that races forged DNS responses Needs to be able to see/predict when the Victim Resolver sends its query (easiest in a lab where the attacker shares the network segment)

Confirm normal resolution works first: from a client pointed at the Victim Resolver, dig example32.com should correctly return the Authoritative server's real answer before you attempt anything else.

🧩 Tasks

🔹 Part A — Confirm the Baseline

  1. Configure the Victim Resolver to recursively resolve queries, using the Authoritative VM as the source of truth for example32.com.
  2. From a separate client, query it and confirm you get the real, correct IP back consistently.

🔹 Part B — Race the Real Response

  1. Write a Scapy script on the Attacker VM that crafts a forged DNS response: matching source IP (spoofed to look like the Authoritative server), matching destination IP/port (the Victim Resolver), matching query name, and — the hard part — a matching transaction ID.
  2. Trigger a fresh query from the client to the Victim Resolver (so its cache doesn't already have an answer) and immediately fire the forged response from the Attacker, trying to win the race against the real authoritative response.
  3. Confirm success: query the Victim Resolver again and observe that it now returns the attacker's IP, not the real one — the poisoned entry is cached and will be served to any future querier until the TTL expires.

🔹 Part C — Discuss the Harder Case

  1. Read 06-06: The Kaminsky Attack and explain, in your own words, what would make this attack dramatically harder against a resolver that randomizes both the query's source port and its transaction ID per query (as modern resolvers do).
  2. Estimate roughly how many forged responses an attacker would statistically need to send to have a good chance of guessing both correctly within the real response's arrival window, and explain why this is why source-port randomization was a critical historical fix (not just transaction ID randomization alone).

✅ Verification Checklist

  • Confirmed correct baseline resolution before attempting the attack.
  • Successfully poisoned the Victim Resolver's cache with a forged response.
  • Captured a dig/nslookup output showing the poisoned (wrong) IP being served.
  • Explained, referencing the Kaminsky attack lesson, why source port + transaction ID randomization together make this attack much harder in practice.

📦 Deliverables

  • The Scapy script used to craft and send the forged DNS response.
  • Before/after dig/nslookup output showing normal resolution, then poisoned resolution.
  • A short written explanation (half a page) of why the attack worked in this simplified lab setup and what specifically would need to change to defend against it.

🚀 Stretch Goals

  • Enable DNSSEC validation on the Victim Resolver and re-attempt the attack — show that the forged (unsigned or incorrectly signed) response is now rejected.
  • Extend the Scapy script to also inject a malicious record in the Authority section (see 06-07: Fake Records in Legitimate DNS Response) rather than just overwriting the Answer section, and observe the broader hijack this enables.
  • Measure how the size of the race window (time between the real query and the real response arriving) affects your practical success rate.

See also notes: [[06-01-dns-infrastructure]], [[06-02-dns-query-process]], [[06-05-dns-cache-poisoning]], [[06-06-kaminsky-attack]]