DNS Attacks: Understanding the Threat Landscape

DNS is simultaneously one of the internet's most critical services and one of its most vulnerable. Every connection begins with DNS—making it an extraordinarily valuable attack target. Compromise DNS, and you can redirect users anywhere, steal credentials, distribute malware, or render services completely inaccessible.

The original DNS protocol was designed for reliability and efficiency, not security. It trusts responses without verification, transmits in plaintext, and has limited defense against volumetric attacks. These fundamental weaknesses have spawned an entire category of attacks that security professionals must understand and defend against.

Cache poisoning is one of the most dangerous DNS attacks—it allows an attacker to inject false DNS records into a resolver's cache, affecting all clients using that resolver. Once poisoned, the resolver returns the attacker's IP address for the target domain until the cache entry expires.

How cache poisoning works:

1. Attacker identifies target domain (e.g., bank.com) and victim resolver
2. Attacker triggers resolver to query for target domain (if not already cached)
3. Before the legitimate response arrives, attacker floods resolver with forged responses
4. If a forged response matches transaction ID/port, resolver accepts and caches it
5. All subsequent queries for bank.com return attacker's IP until TTL expires

The matching challenge:

For poisoning to succeed, the forged response must match:

• Transaction ID (16 bits = 65,536 possibilities)
• Source port (resolver's UDP port for the query)
• Query name and type
• Expected response format

The Kaminsky Attack (2008):

Dan Kaminsky discovered a devastating cache poisoning technique that dramatically increased attack efficiency:

Traditional poisoning: Attacker must guess transaction ID for queries to the TARGET domain. If wrong, must wait for TTL to expire and try again (could take days).

Kaminsky's insight: Query for RANDOM subdomains (abc123.target.com, def456.target.com) that won't exist. Include a poisoned "additional" record for the parent domain (target.com) in the forged authority section. Each random subdomain is a fresh opportunity—no waiting for TTL expiration.

Attack multiplication:

• 65,536 transaction IDs × 65,536 possible source ports = ~4.3 billion combinations
• Before Kaminsky: Attack might take weeks
• After Kaminsky: With random subdomains, can try thousands of queries per second
• Modern resolvers with source port randomization: Still a race, but much harder

Mitigations:

1. Source Port Randomization (SPRS) — Use random UDP source ports (not just fixed 53)
2. 0x20 Encoding — Randomize case in query names (google.COM vs GoOgLe.com)
3. DNSSEC — Cryptographically validate responses
4. Response Rate Limiting — Limit responses to suspicious query patterns

DNS amplification attacks exploit the protocol's asymmetry—small queries generate large responses—to amplify attack traffic for Distributed Denial of Service (DDoS). By spoofing the victim's IP address as the source, attackers can direct massive traffic volumes toward targets.

Attack mechanics:

1. Attacker identifies open DNS resolvers that accept queries from any source
2. Attacker spoofs victim's IP address as the query source
3. Attacker sends small DNS queries designed to generate large responses
4. Open resolvers send large responses to victim's IP (the spoofed source)
5. Victim is overwhelmed by response traffic

Amplification factor:

The amplification factor measures how much the traffic is multiplied:

Amplification = Response Size / Query Size

DNS can achieve amplification factors of 50-100x or more:

• Query: ~60 bytes (asking for large record)
• Response: ~3000-6000 bytes (TXT, ANY, or DNSSEC-signed responses)
• Amplification: 50-100x

Scale of amplification attacks:

Real-world DNS amplification attacks have reached staggering scales:

• 2013 Spamhaus attack: 300 Gbps, one of the largest at the time
• 2016 OVH attack: 1.1 Tbps from combined DNS + NTP amplification
• 2018+ attacks: Regularly exceed 1 Tbps using DNS + memcached + other amplifiers

Why DNS is attractive for amplification:

1. Stateless UDP — No handshake means easy IP spoofing
2. High amplification — Excellent query:response ratio
3. Ubiquitous open resolvers — Millions of misconfigured servers
4. Legitimate traffic — Hard to distinguish attack from real queries
5. Anycast distribution — Many reflecting sources available globally

Mitigations:

For resolver operators:

• Deploy BCP38 (Source Address Validation) — reject spoofed packets
• Disable open recursive resolution — only serve configured clients
• Implement Response Rate Limiting (RRL)
• Block or limit ANY queries (RFC 8482)
• Use DNS cookies (RFC 7873)

For potential victims:

• DDoS mitigation services (Cloudflare, Akamai, AWS Shield)
• Excess bandwidth capacity
• Anycast distribution of services
• Rate limiting at network edge

DNS hijacking refers to attacks that redirect DNS queries or modify responses to send users to attacker-controlled destinations. Unlike cache poisoning (which targets a single resolver), hijacking can occur at multiple points in the DNS resolution path.

Levels of DNS hijacking:

Registrar-level hijacking:

One of the most devastating attacks involves compromising domain registrar accounts:

1. Attacker gains access to registrar control panel (phishing, credential stuffing, social engineering)
2. Attacker changes domain's NS records to point to attacker-controlled nameservers
3. TLD servers (e.g., .com) now delegate to attacker's servers
4. Attacker responds with any records they choose
5. All DNS queries for the domain now resolve to attacker's servers

Case study: 2019 Sea Turtle campaign

Advanced persistent threat actors hijacked DNS for dozens of organizations across the Middle East and North Africa:

• Targeted registrars and DNS providers directly
• Modified NS records to inject attacker-controlled nameservers
• Intercepted credentials for email, VPNs, and other sensitive services
• Obtained legitimate TLS certificates for hijacked domains (via email validation)
• Persisted for years before detection

BGP hijacking for DNS:

Attackers can use BGP (internet routing) hijacking to intercept DNS traffic:

1. Attacker announces BGP routes for DNS server IP prefixes
2. Internet traffic destined for those IPs routes through attacker
3. Attacker intercepts queries, returns malicious responses
4. Attacker may forward legitimate traffic to avoid detection

Notable incident: In 2018, attackers used BGP hijacking to intercept Route 53 DNS traffic, stealing cryptocurrency by redirecting MyEtherWallet.com.

DNS tunneling exploits the DNS protocol to smuggle arbitrary data through networks that would otherwise block such traffic. Because DNS is essential for normal operation, it's rarely blocked—even on heavily restricted networks. Attackers use this for data exfiltration, command-and-control (C2) communication, and bypassing captive portals.

How DNS tunneling works:

1. Attacker controls a domain (e.g., evil.com) and its authoritative nameserver
2. Client encodes data into DNS query names: dGhpcyBpcyBzZWNyZXQ.data.evil.com
3. Query travels through network (allowed as "normal" DNS)
4. Attacker's nameserver receives query, decodes the subdomain data
5. Response data encoded in TXT, NULL, or other record types
6. Bidirectional communication channel established via DNS

Data encoding techniques:

DNS labels (between dots) are limited to 63 characters; total domain name is limited to 253 characters. Tunneling uses various encoding:

• Base32/Base64 — Encode binary data in domain-safe characters
• Hexadecimal — Simpler but less efficient encoding
• Custom encodings — Balance efficiency and detection evasion

Tunneling bandwidth:

DNS tunneling is slow compared to direct connections:

• Query: ~200 characters of data (after encoding overhead)
• Response: ~4000 bytes in TXT record
• Latency: DNS resolution delays for each "packet"
• Throughput: Typically 10-100 KB/s

Detection indicators:

1. Long subdomains — Normal queries rarely have lengthy encoded labels
2. High query entropy — Encoded data has high randomness
3. Unusual query volume — Tunnel requires many queries per "connection"
4. Uncommon record types — TXT, NULL, CNAME queries unusual for normal browsing
5. Query timing patterns — Regular intervals suggest automated tunneling
6. Single domain, many queries — Tunnel uses attacker's domain repeatedly

Beyond protocol-level attacks, DNS enables various domain name-based attacks that exploit human perception and behavior. These attacks don't require compromising DNS infrastructure—they abuse how humans interpret domain names.

Homograph attacks in detail:

Internationalized Domain Names (IDN) allow Unicode characters in domain names. This creates security issues when different scripts have similar-looking characters:

All these look identical in most fonts! An attacker registers xn--pple-43d.com (displayed as аpple.com with Cyrillic 'a') and creates a convincing Apple phishing site.

Mitigation: Modern browsers display Punycode for mixed-script domains or domains with suspicious character combinations. Firefox, Chrome, and Safari have increasingly strict policies about when to display Unicode domains.

Subdomain takeover example:

1. Company creates subdomain: app.example.com → CNAME → example.herokuapp.com
2. Company shuts down Heroku app but doesn't remove CNAME
3. Attacker creates new Heroku app at example.herokuapp.com
4. app.example.com now points to attacker's content
5. Attacker can serve malicious content on company's domain

DNS rebinding is a clever attack that bypasses same-origin policy protections in browsers, allowing malicious websites to attack internal network resources that should be unreachable from the internet. It exploits the fact that DNS responses can change during a browser session.

The attack concept:

1. Victim visits attacker's site: evil.com
2. Browser resolves evil.com → attacker's server (203.0.113.1)
3. Page loads with JavaScript that waits for DNS cache to expire
4. Attacker's DNS server changes evil.com → internal IP (192.168.1.1)
5. JavaScript makes request to evil.com (now 192.168.1.1)
6. Browser considers this same-origin (still evil.com)
7. JavaScript can read responses from internal device!

Why this works:

The browser's same-origin policy is based on protocol, host, and port (e.g., https://evil.com:443). It doesn't consider IP address. When evil.com rebinds to an internal IP, the browser still considers requests to evil.com as same-origin—even though the IP changed.

Attack targets:

1. Router admin interfaces — Change DNS settings, enable remote administration
2. IoT devices — Smart home devices often lack authentication
3. Internal web applications — Access supposedly "internal-only" tools
4. Localhost services — Development servers, Docker dashboards, databases
5. Cloud metadata services — 169.254.169.254 for AWS/GCP instance credentials

Advanced techniques:

• Multiple A records: Return both external and internal IPs; browser may try both
• Short TTL racing: Near-zero TTL forces constant re-resolution
• CNAME switching: Point to controlled subdomain that rebinds
• Time-of-check attacks: Rebind during in-flight requests

Defenses:

Beyond manipulation attacks, DNS infrastructure faces availability attacks designed to disrupt service. Given DNS's critical role, even temporary unavailability can have widespread impact.

Resource exhaustion attacks:

Random subdomain attack (water torture):

This sophisticated attack combines resolver and authoritative server exhaustion:

1. Attacker generates queries for: abc123.victim.com, def456.victim.com, etc.
2. Each random subdomain is a cache miss (can't be cached in advance)
3. Resolver must query authoritative server for every request
4. Authoritative server is overwhelmed by query volume
5. Resolver's pending query slots fill up
6. Legitimate queries for victim.com are delayed or dropped

Why it's effective:

• Random subdomains defeat caching
• Resolver contributes its resources to attacking authoritative server
• Both resolver and authoritative server are impacted
• Traffic looks legitimate (valid DNS queries)

DDoS attacks against DNS providers:

Major DNS providers have become DDoS targets:

• 2016 Dyn attack: Mirai botnet attack took down Dyn DNS, affecting Twitter, Netflix, GitHub, etc.
• 2019 AWS Route 53: Brief availability issues from DDoS attack
• Regular attacks: Authoritative DNS for major domains faces constant attack pressure

Defense strategies: