You type bank.com into your browser. DNS translates that to an IP address. Your browser connects to that IP. But what if someone poisoned the translation? What if bank.com resolves to an attacker’s server that looks identical to your bank? You’d type your credentials into a perfect replica and never know until the money disappeared. That’s not theoretical. It happens. And it works because DNS — the system that maps every domain name to every IP address on the internet — was designed in 1983 with zero authentication and zero encryption. Forty years later, most DNS traffic still travels in plaintext.

The TLDR

DNS is the internet’s naming system. It translates human-readable domain names into IP addresses. It was designed with no built-in security — queries and responses are unencrypted, unauthenticated, and trivially spoofable. Attack types include cache poisoning (injecting false records into DNS resolvers), DNS hijacking (compromising registrars or DNS servers directly), DNS tunneling (smuggling data through DNS queries), typosquatting, and DNS rebinding. Defenses include DNSSEC (cryptographic signing of DNS records), DNS over HTTPS (DoH) and DNS over TLS (DoT) for encryption, and DNS filtering services. Most folks are running their DNS traffic naked across the internet, and the usual suspects know it.

The Reality

DNS is the most critical infrastructure you never think about. Every website visit, every email delivery, every API call, every app update starts with a DNS query. If DNS goes down, the internet effectively stops working — as the 2016 Dyn DDoS attack demonstrated when it took down Twitter, Netflix, Reddit, and GitHub simultaneously.

The protocol itself is a relic. DNS queries are sent as plaintext UDP packets on port 53. There’s no built-in way to verify that a response came from the legitimate server or that it wasn’t modified in transit. Your ISP can see every domain you visit. Anyone on the same network can see your DNS queries. A sufficiently positioned attacker can inject fake responses. NIST SP 800-81-2 (Secure DNS Deployment Guide) exists because the base protocol provides none of the security a critical infrastructure system should have.

How It Works

DNS Resolution — The Lookup Chain

When you type a domain name, here’s the resolution path:

Your Device → Local DNS Cache
           → Router DNS Cache
           → Recursive Resolver (your ISP or 1.1.1.1, 8.8.8.8, etc.)
             → Root Nameserver (. → "try the .com servers")
             → TLD Nameserver (.com → "try ns1.example.com")
             → Authoritative Nameserver (example.com → 93.184.216.34)
           → Response cached at each level
         → Your browser connects to 93.184.216.34

The recursive resolver does the heavy lifting, walking up from root servers down to authoritative nameservers. Responses are cached at every level for the duration specified by the TTL (Time To Live). Caching is essential for performance — without it, every DNS query would require the full resolution chain. But caching is also the attack surface. Poison the cache, and every subsequent lookup gets the poisoned answer.

Record Types That Matter

Compromise any of these records, and you control where that domain’s traffic goes.

How It Gets Exploited

Cache Poisoning — The Kaminsky Attack

In 2008, Dan Kaminsky discovered a fundamental flaw in DNS that made cache poisoning drastically easier than anyone thought. The basic idea: an attacker sends a recursive resolver a query for a domain, then floods it with forged responses that claim to come from the authoritative nameserver. If a forged response arrives before the legitimate one and matches the expected transaction ID (a 16-bit number — only 65,536 possibilities), the resolver caches the fake answer.

Kaminsky’s insight: instead of trying to poison existing cached records (which requires waiting for the TTL to expire), you can query for random non-existent subdomains (random123.bank.com), triggering new lookups with new transaction IDs to guess against — and include an Authority section in the forged response that redirects the nameserver record for the entire zone. One successful poison, and you own all DNS resolution for that domain.

The fix was source port randomization (adding entropy beyond the 16-bit transaction ID), but it was a band-aid. The fundamental problem — unauthenticated responses — remains without DNSSEC.

DNS Hijacking

DNS hijacking bypasses the protocol entirely by compromising the infrastructure:

Registrar compromise: Attackers gain access to the domain registrar account (via credential theft, social engineering, or registrar vulnerabilities) and change the authoritative nameserver records. All DNS queries for the domain now resolve to the attacker’s servers. The Sea Turtle campaign compromised DNS registrars and TLD administrators across the Middle East to redirect traffic from government and military domains.

ISP-level hijacking: Some ISPs redirect DNS queries to their own resolvers, injecting ads or redirecting NXDOMAIN (non-existent domain) responses. Nation-states have been documented redirecting DNS at the ISP level for censorship and surveillance.

Router-level hijacking: Compromised home routers (via default credentials or firmware vulnerabilities) can have their DNS settings changed to point to attacker-controlled resolvers. Every device on the network then resolves DNS through the attacker. MITRE ATT&CK T1584.002 documents DNS server compromise as a pre-positioning technique.

DNS Tunneling — Data Exfiltration via Queries

DNS tunneling encodes data within DNS queries and responses. Since most firewalls allow outbound DNS traffic (it’s essential for normal operation), DNS becomes a covert channel for data exfiltration or command-and-control communication.

An attacker sets up an authoritative nameserver for a domain they control, say evil.com. A compromised machine encodes stolen data in DNS queries: encoded-data-chunk-1.evil.com, encoded-data-chunk-2.evil.com. The queries pass through the corporate firewall (it’s “just DNS”), reach the attacker’s nameserver, which decodes the data from the query. Slow, but effective — and invisible to most monitoring.

MITRE ATT&CK T1071.004 documents DNS as an application layer protocol used for command and control. Detection requires monitoring DNS query volume, entropy of queried domains, and unusual record type usage (TXT records are commonly used for tunneling due to their larger payload capacity).

Typosquatting

Register domains that are common misspellings of legitimate sites: gogle.com, amaz0n.com, microsft.com. Victims who mistype URLs land on attacker-controlled pages — phishing replicas, malware distribution, or ad farms. It’s low-tech, it’s obvious, and it works at scale because people make typos millions of times a day.

DNS Rebinding

DNS rebinding exploits the gap between DNS resolution and browser same-origin enforcement. An attacker’s domain initially resolves to their own server (which serves malicious JavaScript), then changes the DNS record to point to a target on the victim’s internal network (like 192.168.1.1). The browser treats subsequent requests as same-origin because the domain hasn’t changed — but they’re now hitting the victim’s router or internal services. This bypasses firewall rules because the traffic originates from the victim’s own browser.

What You Can Do

DNSSEC — Sign the Chain

DNSSEC adds cryptographic signatures to DNS records. The authoritative nameserver signs each record with its private key, and resolvers validate the signature against the public key published in the parent zone. It’s a chain of trust from the root zone down to the individual record.

DNSSEC prevents cache poisoning and response tampering because forged responses won’t have valid signatures. The limitation: DNSSEC authenticates and verifies integrity, but it does not encrypt. Query contents are still visible in plaintext. It also doesn’t protect against registrar compromise — if an attacker changes the NS records at the registrar, they can also update the DNSSEC keys.

If you own a domain, enable DNSSEC. If you run a resolver, enable DNSSEC validation.

DoH and DoT — Encrypt the Queries

DNS over HTTPS (DoH) wraps DNS queries inside HTTPS connections to port 443. It encrypts the query content and makes DNS traffic indistinguishable from normal web traffic. Your ISP can’t see which domains you’re looking up.

DNS over TLS (DoT) encrypts DNS queries over TLS on port 853. Unlike DoH, it uses a dedicated port, making it easier for networks to identify and block (which is either a feature or a bug depending on your perspective).

Both encrypt the transport, preventing eavesdropping on DNS queries. Neither authenticates the response — for that, you still need DNSSEC. The strongest configuration uses both: DoH/DoT for transport encryption plus DNSSEC for response authentication.

Configure your resolver: Switch to a DNS provider that supports DoH/DoT:

DNS Filtering

Services like Quad9 and Cloudflare’s 1.1.1.2 (malware blocking) filter known malicious domains at the resolver level. Pi-hole and AdGuard Home do the same on your local network. DNS filtering isn’t a replacement for other security controls, but it’s a low-friction layer that blocks connections to known malicious infrastructure before they’re established.

Monitor DNS Anomalies

Watch for unusual DNS patterns: high query volumes to single domains, unusually long query names (tunneling indicator), queries for uncommon record types (TXT, NULL), and queries to domains with high entropy in their names. These are indicators of DNS tunneling, DGA (Domain Generation Algorithm) malware, and data exfiltration.

Sources & Further Reading