DNS was built on trust. Every response is believed. Every packet is accepted at face value. As covered in DNS Fundamentals, there’s no authentication, no encryption, no integrity checking in the original protocol. RFC 1034 and RFC 1035 — the documents that defined DNS in 1987 — never mention the word “security.”
This isn’t a bug. It’s a design decision from an era when the internet was a few thousand researchers who knew each other by name. But that trust model became a liability the moment DNS started routing traffic for banks, hospitals, and governments.
Let’s examine the attacks that exploit these foundational weaknesses.
Cache Poisoning: The Classic Attack
Cache poisoning is the quintessential DNS attack, exploiting the resolution process at its weakest point. The idea is deceptively simple: trick a recursive resolver into caching a false record, and every client that uses that resolver will be directed to the attacker’s server.
Here’s how a basic cache poisoning attack works:
- The attacker sends a query to a target recursive resolver for
bank.example.com - The resolver forwards the query to the authoritative server for
example.com - Before the real answer arrives, the attacker floods the resolver with forged responses claiming to be from the authoritative server
- If a forged response matches the query’s transaction ID (a 16-bit number) and arrives before the real one, the resolver accepts and caches it
- Now every user of that resolver who visits
bank.example.comgets sent to the attacker’s IP
The critical vulnerability here is the transaction ID. It’s only 16 bits — that’s 65,536 possible values. An attacker who can send thousands of forged packets per second has a reasonable chance of guessing correctly.
RFC 5452 (“Measures for Making DNS More Resilient against Forged Answers”) documents the problem formally:
“The DNS relies on the ‘Transaction ID’ (TXID) field and the source port of a UDP packet to provide a modicum of security… these 16 bits of entropy are not sufficient.”
Source Port Randomization
The obvious defense is adding more entropy. If the resolver uses a random source port for each query, an attacker must guess both the transaction ID and the source port — multiplying the search space from 65,536 to over a billion possible combinations.
Most modern resolvers implement source port randomization, as recommended by RFC 5452. But for years, many popular DNS implementations used predictable or sequential source ports, making cache poisoning practical.
The Kaminsky Attack (2008)
In 2008, security researcher Dan Kaminsky discovered a devastating improvement to cache poisoning that sent shockwaves through the internet security community.
The classical cache poisoning attack has a timing problem: you can only attempt it when the resolver is actively looking up a domain, and if the real answer arrives first, the attack fails. Worse, once the legitimate answer is cached, you have to wait for the TTL to expire before trying again — potentially hours or days.
Kaminsky’s insight was elegant and terrifying: don’t attack the cached record. Attack a record that doesn’t exist yet.
The Attack Step by Step
- The attacker queries the target resolver for
random123.example.com— a subdomain that definitely doesn’t exist - Since this name has never been queried, there’s no cached answer. The resolver must query the authoritative server for
example.com - The attacker floods the resolver with forged responses for
random123.example.com - Here’s the key: the forged responses include a poisoned Authority section with a new NS record:
example.com. NS ns1.evil.com. - If the forged response is accepted, the resolver now believes that
ns1.evil.comis the authoritative server for all ofexample.com - If the attempt fails, the attacker simply tries again with
random456.example.com— a new random name, with no cached answer to block the attempt
This is catastrophically different from classical cache poisoning. Instead of poisoning a single record, the attacker poisons the delegation — hijacking the entire zone. And instead of waiting for a TTL to expire after a failed attempt, the attacker can retry immediately with a new random subdomain. The attack becomes a race that the attacker can run unlimited times per second.
Kaminsky coordinated a massive, secret patching effort across the DNS industry before publicly disclosing the vulnerability. The fix — universal source port randomization — was deployed across major DNS implementations in a synchronized release. It was one of the largest coordinated security patches in internet history.
DNS Amplification and Reflection DDoS
DNS isn’t just vulnerable to manipulation — it’s also a powerful weapon for distributed denial-of-service attacks. DNS amplification exploits two properties of the protocol:
1. UDP is connectionless. DNS primarily uses UDP (as detailed in the Protocol Deep Dive), which means the source IP address can be spoofed. The attacker sends queries with the victim’s IP as the source address, and the DNS server sends its responses to the victim.
2. Responses are larger than queries. A small DNS query can generate a massive response. A query for ANY records on a domain with many record types might be 60 bytes, but the response could be 3,000-4,000 bytes — an amplification factor of 50x or more.
Anatomy of an Amplification Attack
Attacker → [query: 60 bytes, spoofed source: victim IP] → Open Resolver
Open Resolver → [response: 3000+ bytes] → Victim
The attacker sends thousands of small queries per second to open recursive resolvers worldwide, each with the victim’s spoofed source IP. The resolvers dutifully send their large responses to the victim, overwhelming their bandwidth.
Amplification factors vary by record type:
| Query Type | Typical Amplification |
|---|---|
| A | 2-3x |
| TXT | 10-20x |
| ANY | 40-70x |
| DNSSEC-signed ANY | 70-100x |
RFC 5358 (“Preventing Use of Recursive Nameservers in Reflector Attacks”) recommends that recursive resolvers restrict access to authorized clients only — not operate as open resolvers. Despite this, hundreds of thousands of open resolvers remain accessible on the internet.
DNS amplification attacks have regularly exceeded hundreds of Gbps, and remain one of the most common DDoS vectors because open resolvers are plentiful and the amplification factor is enormous.
DNS Tunneling
DNS tunneling exploits the fact that DNS traffic is almost never blocked by firewalls. Even the most restrictive networks allow DNS — without it, nothing works. Attackers exploit this by encoding arbitrary data inside DNS queries and responses.
How It Works
The attacker registers a domain (e.g., tunnel.evil.com) and sets up a custom authoritative nameserver for it. The malware on the compromised machine inside the target network encodes data as DNS queries:
encoded-data-chunk-1.tunnel.evil.com → TXT query
encoded-data-chunk-2.tunnel.evil.com → TXT query
Each query travels through the corporate DNS resolver (which is allowed through the firewall) to the attacker’s authoritative server. The server decodes the query, and can send data back in TXT, NULL, or CNAME response records.
The bandwidth is low — typically 10-50 Kbps — but it’s enough to exfiltrate credentials, command-and-control traffic, or slowly steal sensitive documents. Tools like iodine, dnscat2, and dns2tcp automate this process.
Detection
DNS tunneling leaves detectable fingerprints:
- Unusually long domain names — encoding data requires long labels
- High volume of queries to a single domain — normal DNS patterns don’t involve thousands of queries to one obscure domain
- Unusual record types — heavy use of TXT or NULL records
- High entropy in subdomain labels — encoded data looks random, unlike normal hostnames
Enterprise DNS monitoring tools (discussed in Chapter 7) look for these patterns to detect tunneling attempts.
Typosquatting and Homograph Attacks
Not all DNS attacks target the protocol — some target the humans using it.
Typosquatting
Typosquatting registers domains that are common misspellings of popular sites: gooogle.com, amazom.com, microsft.com. Users who mistype a URL land on the attacker’s site, which might host phishing pages, malware downloads, or ad farms.
The scale is staggering. Studies have found that major brands often have hundreds or thousands of typosquatting domains registered against them. Some typosquatters register every possible single-character substitution, deletion, insertion, and transposition of popular domain names.
Homograph Attacks (IDN Abuse)
Internationalized Domain Names (IDN) support non-ASCII characters through Punycode encoding (RFC 3492). This enables domain names in any script — Cyrillic, Chinese, Arabic — which is great for global accessibility but creates a security nightmare.
The problem: many characters from different scripts look identical. The Cyrillic “а” (U+0430) is visually indistinguishable from the Latin “a” (U+0061). An attacker can register аpple.com (starting with Cyrillic “а”) which displays identically to apple.com in many browsers.
The Punycode encoding reveals the trick — xn--pple-43d.com — but users never see Punycode in the address bar.
Browsers have implemented various defenses: Chrome and Firefox now display Punycode instead of Unicode when a domain mixes scripts (e.g., Latin and Cyrillic characters in the same label). But single-script homograph attacks within scripts that share characters with Latin remain challenging to detect automatically.
The Fundamental Problem
Every vulnerability in this chapter traces back to the same root cause: DNS was designed as a public, unauthenticated, unencrypted protocol. Queries go out in plaintext. Responses are accepted on faith. Anyone on the network path can observe, modify, or forge DNS traffic.
The following chapters explore the solutions — DNSSEC for authentication, encrypted transports for privacy, and protective DNS for threat defense. Each addresses a different facet of this fundamental problem.
But first, let’s tackle the biggest and most complex solution: DNSSEC.