DNS Attacks and Defenses

DNS spoofing and cache poisoning

DNS spoofing injects forged answers so victims resolve a name to an attacker-controlled IP. Cache poisoning targets a resolver: if an attacker can get a forged record accepted into a resolver's cache, every user of that resolver is redirected until the TTL expires. Classic attacks raced the real authoritative server's reply; modern resolvers add randomization to make this harder, but it remains a core threat DNSSEC was designed to stop.

DNS hijacking

DNS hijacking changes the authoritative records by compromising the resolver, the DNS server, or, most damagingly, the registrar account that controls the domain. Take over the registrar login and you can repoint the entire domain, including issuing new TLS certificates. This is why MFA on your domain registrar is one of the highest-value security controls you have.

DNS tunneling for exfiltration and C2

Firewalls almost always allow DNS, so attackers abuse it as a covert channel. DNS tunneling encodes stolen data (or command-and-control traffic) inside DNS queries and responses: data goes out as long, high-entropy subdomain labels to an attacker-controlled authoritative server. Detection signals: unusually high query volume to one domain, abnormally long subdomains, high-entropy/random-looking names, and queries for record types you rarely see. SIEM rules and DNS analytics catch these patterns.

DNS rebinding and defenses

DNS rebinding is a browser-based attack: an attacker's domain first resolves to their server, then rebinds to an internal IP (like 127.0.0.1 or a router), using a very short TTL, to bypass the same-origin policy and reach internal services from the victim's browser. Defenses across these attacks: DNSSEC (cryptographically signs records so forgeries are detected), DNS over HTTPS (encrypts the query so it cannot be observed or tampered with in transit), monitoring DNS logs for anomalies, registrar account security with MFA, and (for rebinding) validating Host headers and blocking responses that resolve to private ranges.

Lab: redirect a domain with dnschef

Isolated network, attacker-controlled fake DNS.

1. 1

   1. On an isolated network, set up Kali and a victim container.

2. 2

   2. On Kali, run dnschef to answer a target domain with an attacker IP:

3. 3

   dnschef --fakeip <attacker_ip> --fakedomains target.local

4. 4

   3. Point the victim's resolver at Kali (DHCP or manual /etc/resolv.conf in the lab).

5. 5

   4. From the victim, resolve target.local and watch it hit the attacker's server instead of the real one.

6. 6

   5. Reflect on how DNSSEC (signed answers) and DoH (encrypted queries) would change this.

Which single control most directly prevents an attacker from repointing your entire domain?

Pick one.

Common mistakes only experienced defenders catch

No MFA on the registrar, the single most catastrophic DNS gap. Assuming DNSSEC encrypts queries (it authenticates records; DoH encrypts the query). Ignoring DNS logs, where tunneling and beaconing hide in plain sight. Forgetting internal services can be reached via rebinding from a browser. Trusting that 'DNS just works' and never monitoring for anomalies. Leaving stale records that leak the real origin behind a CDN.