DNS attacks: spoofing, cache poisoning, and tunneling

DNS is the internet’s “contact book” — it translates names into IPs. Because it is an old protocol with no built-in authentication, it is a constant target for abuse. Understanding these attack vectors is essential for defending it.

DNS Spoofing

The attacker forges a DNS response before the legitimate one reaches the client:

Client asks: what is the IP for bank.example.com?
Attacker responds first: 203.0.113.99 (malicious IP)
Client accesses fake site without noticing

Works when the DNS transaction ID is predictable (16 bits — 65,536 possibilities).

Cache Poisoning

A more powerful variant: the attacker poisons a DNS resolver’s cache, affecting all clients using it:

Attacker floods the resolver with forged responses
Tries to guess the correct transaction ID (Kaminsky attack, 2008)
Resolver stores the fake record → all clients receive the wrong IP

Defense: DNSSEC cryptographically signs DNS records. The resolver validates the signature before accepting the response.

DNS Tunneling — data exfiltration

Data is encoded into DNS queries to bypass firewalls that block other ports but allow DNS:

# Secret data encoded as a subdomain
secret-data-in-base32.attacker.com → resolves to any IP
Attacker's server captures the query and extracts the data

Legitimate tools like iodine and dnscat2 are used in authorized pentests to verify whether DNS is being monitored.

Tunneling indicators:

• Very long subdomains (>50 characters)
• High query volume to a single domain
• TXT or NULL records with large payloads

DNS Hijacking

Attacker compromises the authoritative DNS server or a home router and changes records:

example.com A → should point to 198.51.100.10
After hijacking → points to 203.0.113.50 (phishing)

Monitoring for suspicious DNS queries

# Capture DNS queries with tshark
tshark -i eth0 -f "port 53" -Y "dns.flags.response == 0" \
  -T fields -e dns.qry.name

# Suspicious output — long subdomains generated by malware (DGA):
a3f9x1k2m.malware.io
b7h2q9w4n.malware.io

DNSSEC — how it works

Zone example.com signs records with a private key
Resolver receives response + RRSIG signature
Resolver validates with public key published in DNS (DNSKEY)
Forged response → invalid signature → discarded

# Check if a domain uses DNSSEC
dig +dnssec example.com
dig DS example.com @8.8.8.8

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Encrypt DNS queries, preventing interception and modification in transit:

Standard DNS → UDP/53 → visible and modifiable on the network
DoH          → HTTPS/443 → encrypted, looks like regular web traffic
DoT          → TCP/853 → encrypted, dedicated port

Complete defense: DNSSEC (data integrity) + DoH/DoT (privacy in transit).