DNS Security Threats

On the morning of October 21, 2016, millions of people across the northeastern United States opened their browsers and found the internet broken. Twitter would not load. Reddit returned errors. Netflix, Spotify, Amazon, PayPal — all unreachable. The culprit was not a severed undersea cable or a power grid failure. It was a flood of junk traffic aimed at a single DNS provider called Dyn, generated by roughly 100,000 hijacked security cameras, baby monitors, and home routers. A botnet called Mirai had turned the internet’s address book into a single point of failure.

The Dyn attack was a wake-up call, but DNS has always been a target. Understanding why — and knowing the specific attack types — is the first step toward defending the infrastructure that every internet connection depends on.

Why DNS Is a Target

DNS was designed in 1983 for a small network of trusted academic institutions. Three properties of that original design make it attractive to attackers:

1. Unencrypted by default. Traditional DNS queries travel in plaintext over UDP. Anyone on the network path can read and modify them.
2. Universally trusted. Every application and device depends on DNS. Corrupt the response and you redirect the connection before encryption begins.
3. Ubiquitous and firewall-friendly. DNS traffic on port 53 passes through virtually every firewall, making it a reliable covert channel.

Cache Poisoning and the Kaminsky Attack

What It Is

Cache poisoning injects false DNS records into a resolver’s cache. Once poisoned, the resolver sends every user who asks for yourbank.com to the attacker’s server instead of the real one — and the users never see a warning.

How It Works

DNS resolvers accept the first matching response they receive. Traditional DNS relies on a 16-bit transaction ID (only 65,536 possible values) to match responses to queries. An attacker floods the resolver with forged responses, each guessing a different transaction ID. If one matches before the legitimate answer arrives, the poisoned record is cached and served to all subsequent users.

The Kaminsky Attack (2008)

In 2008, Dan Kaminsky discovered a way to make cache poisoning drastically more effective. The classical attack required waiting for a cached record to expire. Kaminsky realized that querying random non-existent subdomains (83.example.com, 84.example.com) gives unlimited attempts — each is a fresh query with no cached answer to compete against. A successful forged response could poison authority records for the entire parent domain.

CVE-2008-1447 affected virtually every DNS implementation. A coordinated multi-vendor patch was secretly prepared and released July 8, 2008; details leaked July 21.

Defenses: Source port randomization, DNSSEC validation, and DNS cookies (RFC 7873). The 2020 SAD DNS attack (CVE-2020-25705) demonstrated that side-channel techniques could partially bypass port randomization.

DNS Spoofing

DNS spoofing is the broader category of attacks that return false DNS answers. Cache poisoning is one method; others include compromising the resolver itself, ARP spoofing combined with DNS interception, or running a rogue DHCP server that points clients to an attacker-controlled resolver.

Between 2010 and 2011, multiple Brazilian ISPs had their DNS caches poisoned, redirecting users from banking sites to phishing pages. Thousands submitted credentials to attackers.

Defenses: DNSSEC provides cryptographic proof that records are authentic. Encrypted DNS protocols (DoH, DoT) prevent on-path interception.

DDoS Attacks Using DNS

DNS is both a target and a weapon in distributed denial-of-service attacks.

DNS Amplification and Reflection

A small DNS query (~60 bytes) can produce a large response (~4,000—5,000 bytes). Attackers send queries with a spoofed source IP — the victim’s address. Resolvers send large responses to the victim, amplifying bandwidth by 28x to 54x.

Metric	Value
DNS attack growth (2022—2024)	+215%
Average amplification attack size growth	+483%
DNS share of network DDoS (H1 2024)	21% (up from 6% in H1 2022)

The largest events include a 2.3 Tbps attack mitigated by AWS Shield (February 2020) and a 2.4 Tbps campaign against a European cloud provider in 2021.

NXDOMAIN / Water Torture Attacks

Water torture attacks target DNS infrastructure directly. Attackers flood resolvers with queries for randomly generated non-existent subdomains (askdhfj.example.com, qpxvud.example.com). Each forces a full resolution attempt that can never be cached. These Layer 7 attacks are harder to filter than volumetric floods because each query looks legitimate.

The Dyn Attack: A Case Study

The October 2016 Dyn attack remains the most significant DNS infrastructure attack in history.

Detail	Value
Attack vector	Mirai botnet — ~100,000 hijacked IoT devices
Peak traffic	~1.2 Tbps
Attack waves	3 consecutive waves throughout the day
Affected services	Twitter, Reddit, Netflix, Spotify, Amazon, PayPal, and dozens more
Aftermath	14,000+ platforms (8% of Dyn’s customers) switched DNS providers

The attack exploited concentration risk: dozens of major services relied on a single DNS provider. The Mirai source code was published after the attack, including default credentials for 60+ IoT device types.

Defenses: Multi-provider DNS redundancy, anycast routing, rate limiting, and BCP38/BCP84 (source address validation).

DNS Tunneling

What It Is

DNS tunneling hides arbitrary data inside DNS queries and responses. An attacker encodes data — stolen files, shell commands, anything — as subdomain labels or TXT record values, then sends them through the DNS system. Because port 53 traffic is allowed through nearly every firewall, this creates a covert channel that bypasses most network security controls.

How It Works

A typical DNS tunnel works like this:

Exfiltrated data encoded as subdomain:
  dGhpcyBpcyBzZWNyZXQ.tunnel.evil.example.com

The attacker's authoritative server for evil.example.com
decodes the base64 subdomain label and recovers the data.
Responses carry return data in TXT or CNAME records.

Common tools include Iodine, DNS2TCP, and DNScat2. These tools can achieve throughput of several hundred kilobits per second — slow by modern standards, but more than sufficient for exfiltrating documents or maintaining command-and-control (C2) channels.

Real-World Impact: SolarWinds/SUNBURST (2020)

The SolarWinds supply chain attack used DNS tunneling for C2 communication. SUNBURST encoded victim information into subdomain queries to avsvmcloud[.]com, blending in with normal DNS traffic. The attack affected 18,000+ organizations, including US government agencies.

Defenses: DNS traffic analysis (detecting long subdomain labels, unusual query volumes), DNS firewalls/RPZ (Response Policy Zones), and ML detection systems achieving 99.68—99.82% accuracy in lab settings.

Typosquatting and Homograph Attacks

Typosquatting

Attackers register misspelled versions of popular domains — gogle.com, amazn.com, faecbook.com — and serve phishing pages or malware. The Anticybersquatting Consumer Protection Act (1999) and ICANN’s UDRP dispute process help, but every popular domain has hundreds of plausible typos.

Homograph Attacks

International Domain Names (IDN) allow Unicode characters in domain labels, encoded as Punycode (xn--...). Many Unicode characters look identical to ASCII letters — Cyrillic a (U+0430) is pixel-identical to Latin a (U+0061) in most fonts.

In 2017, Xudong Zheng demonstrated that xn--80ak6aa92e.com (all Cyrillic) renders as apple.com in the browser. Attackers later used a Cyrillic adobe.com to distribute the Betabot trojan.

Legitimate:  apple.com   (Latin characters)
Homograph:   аррlе.com   (Cyrillic а, р, р, l, е)
Punycode:    xn--80ak6aa92e.com

Modern browsers now display Punycode when a domain mixes scripts or matches a confusable pattern, but homograph attacks remain effective in email clients, mobile apps, QR codes, and shortened URLs — anywhere the full URL is not visible.

Defenses: Browser script-mixing detection, registry-level restrictions on confusable registrations, ICANN policy prohibiting confusable IDN TLDs, and user awareness.

BGP Hijacking of DNS

BGP is the routing protocol that determines how traffic flows between networks. BGP hijacking announces false routes, rerouting traffic through an attacker’s network. When hijacked prefixes include DNS infrastructure, the attacker intercepts DNS traffic at the routing level — below where DNSSEC and other DNS security measures operate.

Date	Incident	Impact
April 2018	BGP hijack of Amazon Route 53	MyEtherWallet users redirected to phishing site; ~$150,000 in Ethereum stolen
December 2017	Russian AS announced prefixes for Google, Apple, Facebook, Microsoft	Traffic rerouted through Russian network
April 2020	Rostelecom leaked 8,800+ prefixes	Affected Amazon, Google, Facebook, Akamai, Cloudflare for ~2 hours

The MyEtherWallet attack is instructive: BGP hijacking redirected DNS queries for a cryptocurrency wallet, and DNSSEC would not have helped because the attack operated below the DNS layer.

Defenses: RPKI (Resource Public Key Infrastructure) for route origin validation, BGP monitoring, and multi-provider DNS with anycast.

DNS Rebinding

What It Is

DNS rebinding attacks exploit the gap between how browsers enforce the same-origin policy (based on hostnames) and how DNS maps hostnames to IP addresses. By rapidly changing a domain’s DNS response from a public IP to a private one, an attacker can make a victim’s browser send requests to devices on their local network — routers, IoT devices, internal services — as if those requests came from the same origin.

How It Works

Time 0:   Victim opens evil.example.com
          DNS: evil.example.com -> 1.2.3.4 (TTL=1)
          Browser loads attacker's page and JavaScript

Time 1s:  TTL expires, DNS cache entry is evicted

Time 2s:  JavaScript makes XHR to evil.example.com/api
          DNS: evil.example.com -> 192.168.1.1 (TTL=1)
          Browser connects to 192.168.1.1 (victim's router)
          Same origin! JavaScript can read the response.

Real-World Impact

In 2018, researcher Brannon Dorsey demonstrated DNS rebinding attacks against consumer IoT devices: Google Home and Chromecast (scan WiFi networks, determine physical location, factory reset), Sonos speakers (execute shell commands), Roku devices (send remote control commands), and WiFi thermostats (change building temperatures, steal API keys). Google, Roku, and Sonos all issued security patches.

Defenses: Private Network Access (CORS-RFC1918) in browsers, DNS pinning (caching DNS results longer than TTL), Host header validation on internal services, and DNS firewalls that block external responses containing private IP addresses.

The Bigger Picture

DNS security is not a single problem with a single solution. Each attack targets a different layer:

Layer	Attack	Primary Defense
Protocol	Cache poisoning, spoofing	DNSSEC, source port randomization
Infrastructure	DDoS, water torture	Redundancy, anycast, rate limiting
Application	Tunneling	Traffic analysis, DNS firewalls
Human	Typosquatting, homographs	Browser protections, user awareness
Network	BGP hijacking	RPKI, multi-provider DNS
Browser	DNS rebinding	Private Network Access, Host validation

The DNS security solutions market was valued at approximately $1.05—1.12 billion in 2024 and is projected to reach $2.31 billion by 2033. That growth reflects a simple truth: DNS was built on trust, and every layer of that trust needs defending. The next step is understanding DNSSEC — the cryptographic foundation that addresses the most fundamental vulnerability of all.