DNS was designed in 1983 to resolve names quickly over UDP, with no authentication built into the original protocol — a gap that attackers have exploited for decades in three structurally different ways. In July 2008, security researcher Dan Kaminsky disclosed CVE-2008-1447, a flaw that let an off-path attacker poison a recursive resolver's cache for an entire domain by racing forged responses against a query's 16-bit transaction ID, triggering a coordinated multi-vendor patch release across BIND, Microsoft DNS, and Cisco within weeks. DNS tunneling takes the opposite approach, hiding data inside a protocol that firewalls almost always leave wide open by default. And NXDOMAIN floods, also called DNS water torture, weaponize the resolution process itself, burning CPU on authoritative servers with queries for subdomains that were never meant to exist. Each technique targets a different layer of the DNS pipeline — the cache, the payload, and the query-response cycle — and each has a distinct, well-documented network-layer defense. This post walks through how the three attacks work and what actually stops them.
How does DNS cache poisoning actually work?
DNS cache poisoning works by forging a fake authoritative response and getting a resolver to accept and cache it before the real answer arrives. Because DNS runs over UDP, a resolver has no persistent connection to verify — it just needs a response matching the query's destination port, source port, and a 16-bit transaction ID (65,536 possible values). Before Kaminsky's 2008 disclosure, many resolvers used a fixed or predictable source port, meaning an attacker only had to guess the transaction ID, and could brute-force thousands of guesses per second by triggering repeated queries for non-existent subdomains of the target domain. Once one guess landed before the legitimate response, the resolver cached the attacker's forged A or NS record for the record's full TTL, redirecting every client behind that resolver. The fix set the template for defense-in-depth: randomize the source port on every query (turning one 16-bit guess into two), and separately deploy DNSSEC so responses carry a cryptographic signature resolvers can validate against a chain of trust back to the root zone.
What is DNS tunneling and why is it hard to spot?
DNS tunneling encodes arbitrary data — command-and-control traffic or exfiltrated files — inside DNS queries and responses, typically using subdomain labels (<encoded-data>.attacker-domain.com) or TXT and NULL record types, because DNS is one of the few protocols almost every firewall permits outbound by default without deep inspection. It's hard to spot because a single tunneled session looks like ordinary name resolution traffic unless you're looking at the right signals: abnormally long or high-entropy subdomain labels, an unusually high volume of distinct queries against one registered domain, a spike in TXT or NULL record queries relative to normal A/AAAA traffic, and a resolver that almost never returns a real answer for that domain. Detecting it at the network layer means running DNS traffic analytics or passive DNS logging that scores queries on label entropy and query-type distribution rather than matching known-bad domains, since tunneling tools can rotate domains freely. Forcing all endpoint traffic through designated internal resolvers, then blocking direct outbound UDP/TCP 53 to the internet, closes off the most common bypass path attackers use once tunneling is detected.
What makes an NXDOMAIN flood effective against authoritative DNS?
An NXDOMAIN flood — also known as DNS water torture or a pseudo-random subdomain (PRSD) attack — works by sending massive volumes of queries for randomly generated, non-existent subdomains of a real target domain (for example, xk29fj3.victim.com), forcing every query to miss cache and travel all the way to the authoritative nameserver, which then has to process a genuine cache miss for each one. As Akamai's research on the technique describes, because each subdomain is unique, negative caching (defined in RFC 2308) provides no relief — there's nothing to cache that a future query will ever reuse — so the authoritative infrastructure's CPU and query-handling capacity gets exhausted, degrading or blocking resolution for legitimate visitors to the domain. The attack is often routed through open recursive resolvers or a botnet to obscure the source and amplify volume. It's a Layer 7 DDoS technique, meaning it can succeed at query volumes far below what would saturate network bandwidth, making it invisible to defenses that only watch for volumetric traffic spikes.
Which detection signals catch an NXDOMAIN flood before it degrades service?
The clearest signal is a sudden, sustained spike in the ratio of NXDOMAIN responses to total responses for a specific domain, paired with high cardinality in the unique subdomains queried per second — legitimate traffic rarely produces thousands of distinct, never-repeated subdomain labels in a short window. Authoritative DNS operators and CDNs monitor this ratio continuously because a healthy domain typically holds a low, stable NXDOMAIN percentage; a jump to a majority of responses being NXDOMAIN is a strong indicator of a water-torture attack in progress, as Akamai's threat research on PRSD attacks documents. Query source diversity is a secondary signal: floods routed through open resolvers or botnets show query patterns arriving from thousands of source IPs rather than the normal, more concentrated set of recursive resolvers a domain typically sees. Because the queries themselves are individually well-formed DNS lookups, standard packet-rate or bandwidth-based DDoS detection tools often miss the attack entirely, which is why NXDOMAIN-ratio monitoring has to run at the DNS application layer, not the network layer alone.
What network-layer mitigations stop each attack?
Response rate limiting (RRL) on authoritative nameservers is the primary defense against NXDOMAIN floods — it caps how many identical or similar responses (including NXDOMAIN) a server sends to a single source within a time window, throttling flood traffic while letting legitimate resolvers' retries through. Tuned negative-caching TTLs per RFC 2308 reduce repeat load from legitimate retries, and anycast routing combined with overprovisioned authoritative capacity absorbs volume that RRL alone can't fully block. For cache poisoning, source-port randomization and DNSSEC validation remain the baseline, supplemented by 0x20 encoding — randomizing the case of letters in a query name as extra entropy an attacker must also guess. For tunneling, egress filtering that forces all DNS traffic through monitored internal resolvers, combined with entropy- and volume-based alerting on those resolver logs, closes the visibility gap. None of these three defenses substitute for the others — they protect different stages of the same protocol, which is why mature DNS security postures run all three simultaneously rather than picking one.