This chapter covers DNS poisoning and spoofing, two critical attack vectors that compromise the integrity of DNS resolution. These techniques are frequently tested on the PT0-002 exam under domain 'Attacks and Exploits' (Objective 3.1). Expect approximately 5-8% of exam questions to involve DNS attacks, including identification, execution methods, and mitigation strategies. Mastering these concepts is essential for both the exam and real-world penetration testing.
Jump to a section
Imagine a large company where employees call a central operator to get the extension number of another employee. The operator has a list of names and their extensions. An attacker bribes the operator to change a few entries: when someone asks for 'IT Support', the operator gives the attacker's extension instead of the real IT desk. The caller then dials the attacker, thinking they are speaking to IT. This is DNS poisoning: corrupting the directory itself. Now consider a different scenario: the operator is honest, but an attacker calls the operator pretending to be 'John from HR' and asks the operator to update John's extension to a new number. The operator, not verifying the identity, changes the entry. This is DNS spoofing: injecting false information into the directory via a forged request. Both result in callers reaching the wrong destination, but the method differs—one corrupts the stored data, the other injects false data during a transaction. In DNS terms, the operator is the DNS server, the extension number is the IP address, and the caller is the client performing a DNS lookup.
What is DNS Poisoning and Spoofing?
DNS poisoning (also called DNS cache poisoning) is an attack that corrupts the DNS resolver's cache with false information, causing it to return incorrect IP addresses for legitimate domain names. DNS spoofing (or DNS forgery) is a broader term that includes poisoning but also encompasses attacks where an attacker forges DNS responses to a specific query, often without modifying the cache. The PT0-002 exam tests both, but emphasizes cache poisoning as a persistent attack.
How DNS Works (Brief Recap)
DNS resolution involves a hierarchy: client → recursive resolver → root server → TLD server → authoritative server. The recursive resolver caches responses to speed up future queries. Cache entries have a Time-To-Live (TTL) value, specified in seconds by the authoritative server. Common TTLs range from 300 (5 minutes) to 86400 (1 day). The resolver discards entries after the TTL expires.
DNS Cache Poisoning Mechanism
A cache poisoning attack exploits the lack of authentication in traditional DNS (before DNSSEC). The attacker sends a forged DNS response to a recursive resolver before the legitimate response arrives. The resolver accepts the first response it receives (UDP, port 53) and caches it. The forged response includes false A or AAAA records, redirecting future queries to an attacker-controlled IP.
Key requirements for successful poisoning: - The attacker must know or guess the transaction ID (TXID) – a 16-bit value in the DNS header, ranging from 0 to 65535. - The attacker must send the forged response from the correct source IP (the authoritative server's IP) and to the correct destination port (usually 53). - The forged response must have a matching query name and type.
The Birthday Attack (Kaminsky Attack): Dan Kaminsky discovered a technique in 2008 that dramatically increased poisoning success. Instead of poisoning a specific domain, the attacker sends many queries for nonexistent subdomains (e.g., random123.example.com) to the resolver. Each query triggers a lookup to the authoritative server. The attacker floods forged responses for each query, guessing different TXIDs. With many queries, the probability of guessing a correct TXID increases significantly. Once one forged response is accepted, the attacker includes an additional NS record in the glue section, redirecting the entire domain's authoritative server to the attacker's DNS server. This gives the attacker control over all future lookups for that domain.
Kaminsky Attack Steps: 1. Attacker queries recursive resolver for a random subdomain of target domain (e.g., 12345.example.com). 2. Resolver queries the authoritative NS for example.com. 3. Attacker sends many forged responses with different TXIDs, each containing a bogus NS record pointing to attacker's DNS server. 4. If one forged response matches the TXID, the resolver caches the NS record. 5. Subsequent queries for any subdomain of example.com go to the attacker's DNS server.
Impact: The attacker can redirect all traffic for the domain, including email, web, and any other services.
DNS Spoofing (Forged Responses)
DNS spoofing is simpler: the attacker intercepts a DNS query and sends a forged response before the legitimate server. This can be done via:
Man-in-the-middle (MITM) attack on the network.
ARP spoofing to redirect traffic through the attacker.
Rogue DHCP server assigning a malicious DNS server.
Spoofing does not necessarily poison the cache; it affects only the single query. However, if the resolver caches the forged response, it becomes poisoning.
DNSSEC as a Mitigation
DNSSEC (DNS Security Extensions) uses digital signatures to authenticate DNS responses. Each authoritative zone signs its records with a private key; resolvers verify the signature using the public key stored in DS records. This prevents spoofing and poisoning because forged responses lack valid signatures. However, DNSSEC is not universally deployed, and the exam expects you to know its role.
Other DNS Attacks
DNS Tunneling: Encapsulating non-DNS traffic (e.g., HTTP, SSH) in DNS queries/responses to bypass firewalls. Often used for command-and-control (C2) exfiltration.
DNS Rebinding: An attacker registers a domain that resolves to an IP they control, then changes the DNS record to point to an internal IP (e.g., 192.168.1.1). The victim's browser, after initial load, makes requests to the internal IP, bypassing same-origin policy.
NXDOMAIN Attack: Flooding a resolver with queries for nonexistent domains, causing it to spend resources on non-existent lookups (a form of DoS).
Default Values and Timers
DNS UDP port: 53
DNS TCP port: 53 (for zone transfers and responses >512 bytes)
Transaction ID (TXID): 16-bit, 0-65535
Default TTL: Varies; common values: 300 (5 min), 3600 (1 hour), 86400 (1 day)
Resolver cache size: OS-dependent; e.g., Windows default is 1 MB
Kaminsky attack requires: Approximately 2^16 queries to guarantee success (birthday paradox).
Commands for DNS Testing (PenTest+)
nslookup – Query DNS records interactively.
dig – More powerful DNS lookup tool (Linux/macOS).
dig @resolver domain – Query a specific resolver.
dig +short domain – Get short answer.
dig axfr @ns1.example.com example.com – Attempt zone transfer (AXFR).
dnsrecon – DNS enumeration tool.
dnsenum – Another DNS enumeration tool.
fierce – DNS reconnaissance tool.
Verification of Poisoning
Check resolver cache: ipconfig /displaydns (Windows), sudo killall -USR1 dnsmasq (dnsmasq), or query with dig and observe TTL.
Compare IP returned by resolver vs. authoritative server.
Interaction with Related Technologies
ARP Spoofing: Often used to perform MITM for DNS spoofing.
DHCP Spoofing: Rogue DHCP server can assign malicious DNS server IP.
IPv6: DNS attacks also work over IPv6; AAAA records are targeted.
DNSSEC: As mentioned, prevents poisoning but adds complexity.
Exam Emphasis (Objective 3.1)
The PT0-002 exam focuses on:
Identifying DNS poisoning/spoofing in logs.
Understanding the Kaminsky attack.
Knowing mitigation techniques (DNSSEC, randomize TXID, use of TCP, short TTLs).
Difference between poisoning and spoofing.
Tools used for DNS attacks (dnschef, ettercap, bettercap).
Query Trigger by Attacker
The attacker sends a DNS query for a nonexistent subdomain (e.g., random.example.com) to the target recursive resolver. This forces the resolver to perform a full iterative lookup, starting from the root servers, down to the authoritative server for example.com. The attacker uses a unique random subdomain for each query to avoid cached results. The resolver sends a query to the authoritative NS for example.com, expecting a legitimate response.
Forged Response Injection
The attacker rapidly sends numerous forged DNS responses to the resolver, each with a different transaction ID (TXID). Each forged response appears to come from the authoritative server (source IP spoofed) and contains a false A record for the queried subdomain, plus an additional NS record that delegates the entire example.com zone to the attacker's DNS server. The resolver accepts the first response with a matching TXID and caches both the A record and the NS record.
Cache Poisoning Success
Once the resolver caches the forged NS record, all future queries for any subdomain of example.com are directed to the attacker's DNS server. The attacker's server can then respond with arbitrary IP addresses for any hostname in the domain. The poisoned cache persists until the TTL expires, which is set by the attacker in the forged response. Typical TTL values used by attackers are long (e.g., 86400 seconds) to maximize the attack window.
Victim Traffic Redirection
When a victim user attempts to visit a legitimate site (e.g., www.example.com), their device queries the poisoned resolver. The resolver, having the false NS record, queries the attacker's DNS server. The attacker's server responds with the IP address of a malicious server (e.g., a phishing site or malware distribution point). The victim's browser connects to the malicious server, believing it is the legitimate site, and may disclose sensitive information.
Attack Persistence and Cleanup
The attacker may continue to serve malicious responses until the poisoned entry expires. To maintain control, the attacker can periodically re-poison the cache before the TTL expires. Once the attack is discovered, administrators must flush the resolver's cache (e.g., `ipconfig /flushdns` on Windows, `systemd-resolve --flush-caches` on Linux) and implement DNSSEC or other mitigations to prevent recurrence.
Enterprise Scenario 1: Large ISP Recursive Resolver Poisoning
A major ISP's recursive DNS resolvers serve millions of customers. An attacker targets these resolvers using the Kaminsky attack. The attacker queries for random subdomains of a popular banking domain (e.g., bank.com). After poisoning, all ISP customers trying to access bank.com are redirected to a phishing site that mimics the bank's login page. The attacker harvests credentials. Detection occurs when customers report login failures or SSL certificate warnings (since the phishing site uses a self-signed certificate). Mitigation involves flushing the ISP's resolver caches, implementing DNSSEC validation, and deploying source port randomization to make TXID guessing harder. The ISP also shortens TTLs for sensitive domains and monitors for unusual query patterns.
Enterprise Scenario 2: Internal Corporate DNS Spoofing via ARP Poisoning
An internal attacker on a corporate network uses ARP spoofing to become a man-in-the-middle between clients and the internal DNS server. The attacker's tool (e.g., ettercap) intercepts DNS queries and responds with forged A records, redirecting internal users to a malicious server hosting a fake HR portal. The attacker captures login credentials. The attack is discovered when an employee notices the SSL certificate mismatch. The company mitigates by enabling DNSSEC, using DHCP snooping and dynamic ARP inspection on switches, and deploying endpoint detection tools that flag ARP anomalies.
Scenario 3: DNS Rebinding Attack on IoT Devices
An attacker registers a domain (e.g., evil.com) and initially sets its A record to a public server they control. A victim visits evil.com, which loads a JavaScript that makes subsequent requests to the same domain. The attacker then changes the DNS record to point to a private IP (e.g., 192.168.1.1 – a router's admin interface). The victim's browser, due to same-origin policy, allows the script to interact with the router, potentially changing settings or exfiltrating data. This attack bypasses firewalls because the requests originate from the victim's browser. Mitigation includes DNS rebinding protection in browsers (e.g., Firefox's DNS rebinding protection), using DNSSEC, and not relying on DNS-based security.
PT0-002 Exam Focus on DNS Poisoning and Spoofing
Objective 3.1 (Attacks and Exploits): The exam expects you to differentiate between DNS poisoning and spoofing, understand the Kaminsky attack mechanism, and identify appropriate mitigations.
Common Wrong Answers: 1. 'DNS poisoning and DNS spoofing are the same.' Wrong: Poisoning corrupts the cache; spoofing forges a response for a single query. The exam may ask which attack persists after the resolver reboots – that's poisoning. 2. 'DNSSEC prevents all DNS attacks.' Wrong: DNSSEC prevents spoofing and poisoning but does not prevent DNS tunneling or rebinding. Also, DNSSEC must be fully deployed to be effective. 3. 'The Kaminsky attack requires the attacker to be on the same network.' Wrong: The Kaminsky attack can be launched from anywhere; it only requires the ability to send UDP packets with a spoofed source IP. 4. 'Using TCP for DNS prevents poisoning.' Wrong: TCP does not prevent poisoning; it only makes spoofing slightly harder because the attacker must also predict the TCP sequence number. DNSSEC is the proper mitigation.
Specific Numbers and Terms: - TXID is 16 bits (0-65535). - Default DNS port: UDP 53. - TTL values: common exam trick is to ask how long a poisoned entry lasts – answer is the TTL set by the attacker. - Kaminsky attack: 2008, Dan Kaminsky.
Edge Cases: - If DNSSEC is partially deployed (e.g., resolver validates but authoritative server does not sign), poisoning is still possible if the resolver accepts unsigned responses. - IPv6 DNS attacks: AAAA records can be poisoned similarly. - Windows vs. Linux caching: Windows caches negative responses (NXDOMAIN) for a shorter time (default 15 seconds).
Eliminating Wrong Answers: - If a question asks about an attack that affects future queries for multiple domains, it's poisoning. - If the attack requires intercepting traffic on the local network, it's likely spoofing via MITM. - If the question mentions 'random TXID' and 'many queries', it's Kaminsky.
DNS cache poisoning corrupts the resolver's cache with false DNS records, affecting all subsequent queries until TTL expires.
The Kaminsky attack (2008) uses the birthday paradox to poison a resolver by sending many queries for nonexistent subdomains.
DNS spoofing is a broader term that includes poisoning but also covers one-off forged responses.
DNSSEC uses digital signatures to authenticate DNS responses, preventing both poisoning and spoofing.
Transaction ID (TXID) is a 16-bit value (0-65535) that the attacker must guess to succeed.
DNS uses UDP port 53 for queries and TCP port 53 for zone transfers and large responses.
Common tools for DNS attacks: dnschef, ettercap, bettercap, Metasploit auxiliary modules.
Mitigation strategies: DNSSEC, randomize TXID and source port, short TTLs, limit recursion to authorized clients.
These come up on the exam all the time. Here's how to tell them apart.
DNS Cache Poisoning
Corrupts the resolver's cache for a period determined by TTL.
Affects all subsequent queries for the poisoned domain until cache expires.
Example: Kaminsky attack.
Mitigated by DNSSEC, source port randomization, and short TTLs.
More dangerous because it persists and impacts multiple users.
DNS Spoofing (Forged Response)
Forces a single response to a specific query; may not be cached.
Only affects the current query; does not persist unless cached.
Example: MITM attack using ARP spoofing.
Mitigated by DNSSEC, but also by network security measures like ARP inspection.
Requires the attacker to be on the same network segment (for MITM).
Mistake
DNS poisoning and DNS spoofing are exactly the same attack.
Correct
DNS spoofing is the act of sending a forged response to a single query. DNS poisoning specifically refers to corrupting the resolver's cache so that the false entry persists for the TTL duration. Spoofing can lead to poisoning if the forged response is cached.
Mistake
DNSSEC completely eliminates all DNS attacks.
Correct
DNSSEC prevents cache poisoning and response spoofing by authenticating responses with digital signatures. However, it does not prevent DNS tunneling, DNS rebinding, or DDoS attacks on DNS infrastructure.
Mistake
The Kaminsky attack only works on recursive resolvers that do not randomize source ports.
Correct
Source port randomization makes the attack harder but not impossible. The attacker must also guess the source port, increasing the search space. However, if the resolver uses a predictable port, the attack is easier.
Mistake
Using TCP for DNS queries prevents cache poisoning.
Correct
TCP does not prevent poisoning; it only makes spoofing more difficult because the attacker must also predict the TCP sequence number. The resolver still caches the response if it accepts it. DNSSEC is the proper mitigation.
Mistake
DNS cache poisoning only affects the specific domain queried.
Correct
In the Kaminsky attack, the attacker includes a false NS record that delegates the entire domain to the attacker's server, allowing redirection of all subdomains, not just the queried one.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DNS spoofing is the act of sending a forged DNS response to a query, tricking the client into thinking it came from a legitimate server. DNS poisoning is a specific type of spoofing where the forged response is cached by a recursive resolver, affecting future queries. In short, all poisoning is spoofing, but not all spoofing is poisoning.
The Kaminsky attack exploits the birthday paradox to poison a DNS resolver's cache. The attacker sends many queries for random subdomains of a target domain. For each query, the attacker sends a flood of forged responses with different transaction IDs. One of these responses will match the resolver's query, and the resolver caches the false NS record, delegating the entire domain to the attacker's DNS server.
DNSSEC (DNS Security Extensions) adds digital signatures to DNS records. Authoritative servers sign their records with a private key. Resolvers verify the signature using the public key obtained via the chain of trust. A forged response would lack a valid signature, so the resolver rejects it. This prevents cache poisoning and spoofing.
Yes, DNS can use TCP for responses larger than 512 bytes or for zone transfers. Poisoning over TCP is harder because the attacker must also guess the TCP sequence number. However, if the resolver caches the response, poisoning is still possible. DNSSEC is the definitive mitigation.
Common tools include dnschef (a DNS proxy that can forge responses), ettercap (MITM tool with DNS spoofing plugin), bettercap (modern MITM framework), and Metasploit's auxiliary/server/dns_spoof module. Also, custom scripts using Scapy or raw sockets.
Look for discrepancies between the IP returned by your resolver and the authoritative answer. Use `dig +trace` to see the full resolution path. Monitor for unusual query patterns (e.g., high volume of NXDOMAIN responses). Check DNS cache entries with `ipconfig /displaydns` (Windows) or `sudo killall -USR1 dnsmasq` (Linux).
DNS rebinding uses a domain that initially resolves to an attacker's server, then changes the DNS record to point to an internal IP. The victim's browser, due to same-origin policy, allows the attacker's script to access the internal IP. This is different from poisoning because it exploits the time lag between DNS resolution and browser enforcement, not cache corruption.
You've just covered DNS Poisoning and Spoofing — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?