How DNS Attacks Work: DNS Spoofing, Cache Poisoning & DNS Hijacking Explained

01 // Protocol Architecture

The DNS Resolution Chain & Its Inherent Trust Flaws

Designed in 1983 by Paul Mockapetris and codified in RFC 1034 and RFC 1035, the Domain Name System (DNS) was engineered for an academic network that presumed mutual trust between all participating nodes. To ensure maximum speed and minimal operational overhead, DNS was built primarily over the User Datagram Protocol (UDP) on port 53.

Unlike TCP, UDP is connectionless. There is no three-way handshake (SYN → SYN-ACK → ACK), no sequence number synchronization, and no native session state. A DNS packet simply consists of a source IP, destination IP, port numbers, and a 12-byte header followed by the query payload.

The Stateless Matching Problem: 16-Bit Transaction IDs

When a recursive resolver dispatches an iterative UDP query to an authoritative server, how does it know that the response packet arriving milliseconds later is legitimate? Historically, the protocol relied solely on matching three parameters:

• Source IP Address: Must match the queried authoritative server IP.
• Destination UDP Port: Must match the resolver's outbound UDP port.
• 16-Bit Transaction ID (TXID): A random integer in the range 0x0000 to 0xFFFF (65,536 possible values).

Because UDP headers do not authenticate source IP addresses, any attacker capable of spoofing raw IP packets can forge a response packet pretending to originate from the authoritative nameserver. If the attacker guesses the 16-bit Transaction ID and arrives at the recursive resolver before the authentic answer, the resolver accepts the forged answer as fact, discards the authentic packet when it arrives later, and commits the malicious record to memory.

02 // Threat Vector 1

DNS Spoofing: Local Man-in-the-Middle Injection

DNS Spoofing is the broad category of attacks where an adversary feeds fraudulent DNS resolution data to a client or server. In its most common local incarnation, DNS spoofing occurs directly on the local network segment (LAN, enterprise Wi-Fi, or public hotspot).

1. ARP Poisoning & Gateway Impersonation

On an unsegmented Ethernet or Wi-Fi network, an attacker issues gratuitous Address Resolution Protocol (ARP) replies mapping the default gateway's IP address to the attacker's MAC address. Once established as the Man-in-the-Middle (MitM), the attacker inspects outbound UDP port 53 packets in real time. Because the attacker sees the exact query Transaction ID as it passes through their network interface, they do not need to guess anything: they emit an immediate forged DNS response containing a spoofed IP address before the real gateway can forward the packet upstream.

2. Rogue DHCP Server & Evil Twin Access Points

In public environments (airports, cafes, hotels), an attacker deploys a rogue Wi-Fi access point ("Evil Twin") with a higher signal strength or runs a rogue DHCP server that replies faster than the legitimate router. When clients connect, the rogue DHCP server assigns a DNS server IP owned and controlled by the adversary. Every subsequent domain query from that client is resolved directly to malicious infrastructure.

3. Host-Level File Tampering (The Malware Vector)

Infostealers (such as LummaC2, StealC, and RedLine) and commodity Trojans frequently modify local host resolution tables (e.g. C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux/macOS). Because the OS checks the local hosts file before querying any network DNS server, hardcoded mappings immediately redirect security update servers, antivirus telemetry endpoints, or banking portals to localhost or command-and-control proxies.

03 // Threat Vector 2

DNS Cache Poisoning & The Kaminsky Breakthrough

While local spoofing compromises only machines on the immediate network segment, DNS Cache Poisoning targets the shared recursive resolver operated by an ISP, enterprise network, or cloud provider. If an attacker successfully poisons a central recursive resolver, hundreds of thousands of downstream users querying that domain are simultaneously redirected without any compromise occurring on their individual endpoints.

The Classical Birthday Paradox Limitation

Prior to 2008, DNS cache poisoning was heavily constrained by the domain's Time-To-Live (TTL). If an attacker wanted to poison the cache for bank.com, they sent a query for bank.com to trigger the resolver into querying upstream. The attacker then flooded the resolver with a few hundred guessed Transaction IDs.

If all guesses failed and the authentic response arrived first, the authentic bank.com record was cached with a TTL of, for example, 86,400 seconds (24 hours). The attacker could not make another attempt until the 24-hour TTL expired, making brute-force guessing statistically impractical.

Dan Kaminsky's discovery triggered the largest coordinated multi-vendor security patch in Internet history in July 2008. The immediate stopgap fix was Source Port Randomization (SPR) (formalized in RFC 5452). Instead of sending every query from UDP port 53, resolvers were updated to randomize both the 16-bit Transaction ID and the 16-bit ephemeral source port (~60,000 ports). This increased the guessing entropy from \(2^{16} = 65,536\) to \(2^{16} \times 2^{16} \approx 4.29 \times 10^9\) combinations, making blind packet race attacks mathematically unfeasible over conventional network bandwidths.

04 // Threat Vector 3

DNS Hijacking: Routing & Infrastructure Seizure

Unlike DNS spoofing and cache poisoning—which exploit stateless packet transmission and timing races—DNS Hijacking seizes control of the underlying infrastructure, authoritative configuration records, or global network routing tables.

05 // Taxonomy & Distinction

Comparative Matrix: Spoofing vs. Poisoning vs. Hijacking

Security professionals frequently conflate these three terms. The table below delineates the precise technical boundaries across attack layer, injection mechanism, blast radius, persistence, and primary countermeasure.

06 // Safe Interactive Model

Interactive Resolution & Attack Simulation Lab

Explore how recursive DNS resolution operates, trigger a simulated Kaminsky cache poisoning race condition, and observe how cryptographic DNSSEC verification stops rogue packets in their tracks.

07 // Defensive Architecture

Cryptographic Hardening & Zero-Trust Mitigations

Securing name resolution requires a multi-layered defense model spanning transport encryption, cryptographic signature validation, port entropy, and routing authentication.

1. DNSSEC: Cryptographic Authenticity for DNS Records

Specified in RFC 4033, RFC 4034, and RFC 4035, Domain Name System Security Extensions (DNSSEC) adds digital signatures to DNS data. DNSSEC does not encrypt queries; instead, it guarantees two critical properties: Origin Authentication (confirming the record came from the genuine zone owner) and Data Integrity (proving the record was not altered in transit).

• RRSIG (Resource Record Signature): Digital signature attached to every Resource Record Set (RRset), generated using the zone's private key.
• DNSKEY: Public key used by resolvers to verify RRSIG signatures. A zone typically uses a Zone Signing Key (ZSK) for daily records and a Key Signing Key (KSK) to sign the ZSK.
• DS (Delegation Signer): A cryptographic hash of the child zone's KSK published in the parent zone (e.g. .com). This creates an unbroken Chain of Trust anchored at the ICANN Root Trust Anchor.
• NSEC / NSEC3: Cryptographic proof of non-existence, preventing attackers from spoofing NXDOMAIN responses.

server:
    verbosity: 1
    interface: 127.0.0.1
    port: 53
    
    # Enforce DNSSEC Validation
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-clean-additional: yes
    val-permissive-mode: no
    
    # Maximize Source Port & Query Randomization (RFC 5452)
    outgoing-range: 8192
    outgoing-port-permit: 1024-65535
    use-caps-for-id: yes          # DNS 0x20 bit encoding
    
    # Harden Cache & Guard Against Glue Record Pollution
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-below-nxdomain: yes
    harden-referral-path: yes
    
    # Rate Limiting against Denial-of-Service / Poisoning bursts
    ratelimit: 1000
    ip-ratelimit: 100

2. Encrypted DNS: Protecting the Last Mile (DoH, DoT, DoQ)

While DNSSEC protects against record tampering, it transmits queries in cleartext. Encrypted DNS protocols protect the transport path between the client stub resolver and the recursive resolver:

• DNS-over-HTTPS (DoH - RFC 8484): Encapsulates DNS queries in HTTP/2 or HTTP/3 over standard HTTPS (port 443), making DNS traffic indistinguishable from web traffic and defeating ISP snooping and local Wi-Fi spoofing.
• DNS-over-TLS (DoT - RFC 7858): Wraps DNS directly inside TLS over dedicated port 853, widely adopted in mobile operating systems (Android Private DNS).
• DNS-over-QUIC (DoQ - RFC 9250): Leverages QUIC on port 853 for ultra-low latency, zero head-of-line blocking, and fast connection migration.

3. Defending the Routing & Registrar Plane

• BGP RPKI (Resource Public Key Infrastructure): Route Origin Authorizations (ROAs) cryptographically link IP prefixes to authorized Autonomous System Numbers (ASNs), preventing BGP prefix hijacking against authoritative DNS infrastructure.
• Registry Lock & EPP Protection: Domain Registry Locks require out-of-band identity verification (phone authentication, multi-party approval) before nameserver records can be altered, preventing registrar account takeovers.

08 // Incident Response & Runbook

Hands-On Diagnostic & Auditing Runbook

Use these terminal inspection patterns to audit DNSSEC trust chains, inspect authoritative delegation, test DoH endpoints, and detect DNS resolution anomalies.

# 1. Trace the complete recursive resolution chain with DNSSEC validation
dig +trace +dnssec +multiline example.com

# 2. Query DNSKEY and verify the Authenticated Data (ad) flag
dig @8.8.8.8 example.com +dnssec

# 3. Cryptographically validate the DNSSEC chain using BIND's delv utility
delv @1.1.1.1 example.com

# 4. Inspect NS delegation and Glue records directly from TLD nameservers
dig @a.gtld-servers.net example.com

# 5. Query a DNS-over-HTTPS (DoH) resolver directly with curl
curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

# 6. Check DNS 0x20 bit capitalization support on a local resolver
dig 0x20.example.com @127.0.0.1

09 // Technical FAQ

Frequently Asked Questions

Does HTTPS make DNS security unnecessary?

No. While HTTPS displays a certificate warning if an attacker redirects web traffic to a rogue server lacking a valid certificate, DNS redirection still succeeds. Attackers exploit DNS redirection to harvest metadata, launch Denial of Service attacks, spoof unencrypted legacy protocols (SMTP, FTP, IoT telemetry), or conduct SSL stripping attacks if HTTP Strict Transport Security (HSTS) is missing.

If I use 1.1.1.1 or 8.8.8.8, am I immune to DNS attacks?

Public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) enforce strict DNSSEC validation, Source Port Randomization, and query rate limiting, shielding you from cache poisoning at their layer. However, if your local network is compromised (ARP spoofing / rogue DHCP), if your router's DNS settings are altered, or if you use unencrypted UDP 53 to reach those resolvers, local attacks remain fully effective. Use DoH or DoT to secure the path to the resolver.

What is the difference between DoH and DNSSEC?

DoH encrypts the communication channel between your device and the resolver (privacy & anti-eavesdropping). DNSSEC signs the actual DNS records end-to-end from the zone owner down to the resolver (authenticity & integrity). They are complementary: DoH protects the last mile, while DNSSEC protects the recursive resolution chain.

10 // Conclusion

Building an Uncompromising DNS Trust Model

DNS was built in an era when networks were small, cooperative, and insulated. Today, it remains the foundational lookup mechanism of the global internet. Defending against DNS spoofing, Kaminsky cache poisoning, and infrastructure hijacking requires moving beyond the naive assumption of stateless packet trust.

By combining DNSSEC validation at the resolver, DNS-over-HTTPS/TLS on the client, Source Port Randomization, and BGP RPKI enforcement at the network edge, organizations can transform the fragile 1980s protocol into a hardened zero-trust resolution pipeline.