Network Security DNS Attacks

The Domain Name System (DNS) is the internet's address book. Every time you type a website name, DNS translates it to an IP address. This translation process runs billions of times per second globally, mostly without security verification. Attackers exploit DNS's trusted position in network communications to redirect traffic, intercept data, and disrupt services.

How DNS Works (Quick Recap)

You type: www.mybank.com

Step 1: Your device asks your local resolver (usually your router or ISP)
Step 2: Resolver asks the Root DNS servers: "Who manages .com?"
Step 3: Root server responds: "Ask the .com nameservers"
Step 4: Resolver asks .com servers: "Who manages mybank.com?"
Step 5: .com server responds: "Ask mybank's authoritative nameserver"
Step 6: Resolver asks mybank's DNS: "What is the IP of www.mybank.com?"
Step 7: Authoritative server responds: "203.0.113.50"
Step 8: Your browser connects to 203.0.113.50

Attack DNS at any step → redirect users to malicious destinations.

DNS Cache Poisoning

DNS resolvers cache answers to avoid asking the same question repeatedly. Cache poisoning injects false DNS records into a resolver's cache. Every user of that resolver then gets the false IP for a domain, redirecting them to an attacker-controlled site — potentially for hours or days until the cache expires.

CACHE POISONING ATTACK:

Resolver asks: "What is the IP of mybank.com?"
Attacker races to respond before the real DNS server:
Attacker's fake response: "mybank.com = 1.2.3.4" (attacker's server)

Resolver caches: mybank.com = 1.2.3.4
TTL: 3600 seconds (cached for 1 hour)

Every user asking for mybank.com in the next hour:
→ Gets 1.2.3.4 (attacker's server)
→ Sees a perfect copy of the bank website
→ Enters real credentials → attacker collects them

The Kaminsky Attack (2008)

Security researcher Dan Kaminsky discovered a fundamental flaw in DNS that allowed cache poisoning at massive scale. An attacker could inject poisoned records for an entire domain in seconds by flooding a resolver with fake responses using randomly guessed transaction IDs. This discovery led to emergency patches across DNS software worldwide and accelerated DNSSEC adoption.

DNS Spoofing

Similar to cache poisoning, but targeted at individual queries rather than resolver caches. In a MITM position on a local network, an attacker can intercept DNS queries and send fake responses directly to the victim's device before the legitimate DNS server responds.

DNS SPOOFING ON LOCAL NETWORK:

Victim asks: "What is the IP of google.com?"
       ↓
Query travels on local network
       ↓
[Attacker intercepts and responds first]
"google.com = 192.168.1.100" (attacker's device)
       ↓
Victim connects to 192.168.1.100 thinking it is Google
Attacker serves a fake Google login page

DNS Amplification (DDoS)

DNS resolvers respond to queries with answers that are often much larger than the query itself. Attackers send DNS queries with the victim's IP address as the source. DNS servers send large responses to the victim, amplifying the attacker's bandwidth.

DNS AMPLIFICATION:
Attacker sends: 40-byte query (source IP = victim's IP)
DNS server sends: 3,000-byte DNSSEC response to VICTIM

Amplification factor: 75x
10,000 open resolvers × 1 Mbps each = 10 Gbps hitting victim
Attacker used only: 133 Mbps of bandwidth

DNS Hijacking

DNS hijacking changes the DNS settings at the device, router, or domain registrar level to use attacker-controlled DNS servers. Instead of poisoning a cache, the attacker becomes the DNS server. All DNS queries from affected users return whatever the attacker decides.

ROUTER DNS HIJACKING:
Attacker compromises home router (default admin password still set)
Changes router's DNS server from 8.8.8.8 to 192.168.1.1 (attacker's DNS)

Victim's device asks router: "What is paypal.com's IP?"
Router asks attacker's DNS server
Attacker's DNS returns: "paypal.com = attacker's IP"
Victim enters PayPal credentials on fake site

DNS Tunneling

DNS tunneling encodes non-DNS data inside DNS queries and responses to exfiltrate data or establish covert communication channels. Firewalls almost always allow DNS traffic (port 53) to pass. Attackers use this permitted channel to bypass firewall rules and communicate with malware already inside the network.

DNS TUNNELING FOR DATA EXFILTRATION:

Normal DNS query: "What is the IP of example.com?"

DNS Tunnel query: "What is the IP of
                  SECRETDATA_BASE64ENCODEDCHUNK1.attacker.com?"
                   ↑ 
                   stolen data encoded in the domain name label

Attacker's DNS server receives the query and reads the stolen data
from the subdomain labels.
Firewall sees only normal-looking DNS traffic.

Defenses Against DNS Attacks

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records. Resolvers that support DNSSEC verify the signature on every response. A poisoned or spoofed response without a valid signature is rejected.

Without DNSSEC:
DNS response: "mybank.com = 1.2.3.4"  ← accepted without question

With DNSSEC:
DNS response: "mybank.com = 203.0.113.50"
Signature:    [cryptographic proof from mybank's DNS key]
Resolver:     Verifies signature → valid → accept

Attacker's fake response:
"mybank.com = 1.2.3.4"
Signature:    [no valid signature]
Resolver:     Signature invalid → REJECT

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

Traditional DNS queries travel in plain text over UDP. Anyone on the network can read and modify them. DoH and DoT encrypt DNS queries, preventing interception and spoofing on the local network.

DNS Monitoring and Anomaly Detection

Monitor DNS traffic for signs of tunneling (unusually long domain names, high query rates to single domains, rare record types), fast-flux domains (rapidly changing IPs), and queries to known malicious domains. Security platforms that integrate threat intelligence feeds block queries to attacker infrastructure automatically.

DNS Security Checklist:
✓ Enable DNSSEC on all zones you control
✓ Use a recursive resolver that validates DNSSEC
✓ Enable DNS over HTTPS or DNS over TLS for client queries
✓ Change default router admin credentials to prevent DNS hijacking
✓ Use DNS filtering (block known malicious domains)
✓ Monitor DNS logs for tunneling indicators
✓ Disable open recursive resolution (prevent your DNS from being used in amplification)
✓ Restrict DNS zone transfers to authorized secondary servers only

DNS is trusted implicitly by almost every application and operating system. Attacks that poison this trust layer bypass all application-level security controls — the user connects to the attacker's server over a valid HTTPS connection because the DNS told them it was the right address. Securing DNS is as foundational as securing the perimeter firewall.