How DNS Normally Works
When you type example.com in a browser, your device queries a recursive DNS resolver (usually your ISP's or a public resolver like 1.1.1.1). The resolver queries the DNS hierarchy — root nameservers → TLD nameservers → authoritative nameserver — then caches the answer for the TTL period (seconds to hours). Subsequent queries for the same name return the cached answer without re-querying the hierarchy.
The weakness: traditional DNS uses UDP, which is connectionless and unauthenticated. Any response claiming to be from the authoritative nameserver can potentially be accepted.
The Classic Poisoning Attack
Before 2008, DNS resolvers used predictable transaction IDs (16-bit values, 0–65535) and often a fixed source port. An attacker could:
- Trigger a resolver to query an authoritative nameserver for a target domain.
- Flood the resolver with forged responses containing the correct transaction ID and a malicious IP.
- If the forged response arrived before the legitimate one, the resolver cached the malicious record.
Guessing a 16-bit transaction ID required at most 65,536 attempts — trivial at network speeds.
The Kaminsky Attack (2008)
Dan Kaminsky's 2008 discovery dramatically worsened the threat. Rather than targeting example.com itself (which, once cached, wouldn't be re-queried until TTL expiry), his attack targeted random subdomains of the victim domain (aaa.example.com, bbb.example.com, …). Each unique subdomain triggered a fresh resolver query — allowing continuous attack attempts. The poisoned response also included a forged NS record for example.com in the additional section, poisoning the entire zone's authority record.
This transformed the attack from "wait for TTL expiry" to "continuously attempt until successful." The fix was randomizing source ports (adding ~16 more bits of entropy), making brute-force impractical without a network-level off-path position.
Modern Defenses
DNSSEC (DNS Security Extensions) cryptographically signs DNS records. A resolver with DNSSEC validation rejects any response whose signature doesn't verify against the zone's public key — forged records are detected regardless of transaction ID or port guessing. DNSSEC is the definitive defense but requires the domain owner to sign their zone and the resolver to validate signatures. Adoption is growing but not universal.
DNS over HTTPS (DoH) / DNS over TLS (DoT) encrypt the DNS query channel, preventing on-path injection. They don't authenticate the DNS records themselves (that's DNSSEC's job) but prevent an attacker who can observe or inject into the network path from poisoning responses.
Source port randomization (implemented post-Kaminsky in all major resolvers) adds ~16 bits of entropy, requiring ~4 billion guesses rather than 65,536 — effective against off-path attackers without network-level access.
Local DNS Poisoning: The /etc/hosts File and Router Hijacking
DNS poisoning doesn't require attacking a public resolver. Malware commonly modifies the local hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux/macOS) to redirect specific domains. Router firmware compromises change the router's DNS server setting, redirecting all queries from connected devices. These local attacks bypass all public resolver defenses.
Frequently Asked Questions
Does HTTPS protect against DNS poisoning?
Partially. If redirected to a malicious IP, the browser validates the TLS certificate. The attacker cannot get a valid certificate for the target domain (without a CA compromise), so the browser shows a certificate error. Users who ignore the warning are unprotected. HSTS preloading and certificate pinning provide stronger protection than standard HTTPS alone.
What is the difference between DNS poisoning and DNS hijacking?
DNS poisoning corrupts a resolver's cache by injecting forged records — it races against the legitimate response. DNS hijacking redirects queries at a different layer: malware changes the system DNS setting, an ISP intercepts traffic, or a compromised router serves malicious DNS. Hijacking controls the resolver itself; poisoning exploits the resolver's trust in responses.