DNS Poisoning vs DNS Spoofing
| Term | Meaning | Effect |
|---|---|---|
| DNS spoofing | A false DNS response is sent or accepted | One or more clients receive a wrong answer |
| DNS cache poisoning | A resolver stores a false answer in its cache | Many subsequent users receive the wrong answer until TTL expires |
| Local override | A hosts file, rogue router, or malware changes resolution | Only the affected device or network is redirected |
How the Attack Works: Forging Responses
Standard DNS over UDP is connectionless and unauthenticated. A resolver sends a query with a 16-bit transaction ID and typically listens on a fixed source port. An attacker who can send packets to the resolver faster than the legitimate authoritative server can respond has a chance to forge a matching reply. The forged reply must include the correct transaction ID and be addressed to the resolver's source port. If the resolver accepts the forged response before the legitimate one arrives, it caches the attacker's answer. All subsequent clients asking the same question receive the poisoned answer for as long as the TTL allows it to remain in cache.
The Kaminsky Attack
In 2008, security researcher Dan Kaminsky disclosed a practical amplification of the basic poisoning technique that made the attack far more efficient. Prior to this, an attacker needed to guess the transaction ID for a specific query and race the legitimate response — a narrow window. Kaminsky's insight was to query for random, non-existent subdomains of the target domain (e.g., random123.example.com, random456.example.com) in rapid succession. Because these names do not exist, the resolver must query the authoritative server each time, generating a fresh transaction ID for each query. The attacker floods the resolver with forged responses for each query, guessing different transaction IDs. With enough attempts, eventually one forged response matches. The poisoned answer can include a fake NS record for the entire example.com zone, redirecting all future lookups for any name under that domain to attacker-controlled nameservers. The attack can poison an entire domain in seconds on a vulnerable resolver. Emergency patches deployed across the industry in 2008 added source port randomization as a primary mitigation.
Birthday Attack Probability
The effectiveness of DNS poisoning is a birthday problem. With only a 16-bit transaction ID, there are 65,536 possible values. An attacker sending forged responses at high speed has a roughly 50% chance of a match after about 256 attempts (square root of 65,536). Source port randomization adds another 16 bits of entropy, raising the space to approximately 2^32 combinations — around 4 billion. At that scale, a brute-force guess requires many millions of forged packets before a match is likely, making opportunistic poisoning impractical. However, an on-path attacker who can observe query parameters still trivially wins, which is why encrypted transport is a stronger defense.
Resolver Randomization: Source Port and Query ID
Post-Kaminsky resolvers implement two layers of randomization. Transaction ID randomization uses a cryptographically random 16-bit value for each query rather than a sequential counter. Source port randomization selects a random UDP source port for each outgoing query from a large pool, rather than using a fixed port like 53. Together these increase the entropy an attacker must guess. BIND, Unbound, and most modern resolvers implement both by default. Some NAT devices and firewalls re-map UDP source ports, inadvertently de-randomizing the port and reducing the entropy back toward the transaction ID alone — a known deployment pitfall that was exploited in the years following the Kaminsky patch.
DNSSEC as a Defense
DNSSEC adds cryptographic signatures to DNS records. Zone operators sign their records with a private key. Resolvers that validate DNSSEC use the corresponding public key, obtained through a chain of trust rooted at the signed DNS root zone, to verify each response. A forged answer will not carry a valid signature and will be rejected by a validating resolver regardless of whether the transaction ID and source port matched. DNSSEC does not encrypt query content or hide what name is being resolved — it provides only origin authentication and data integrity. For DNSSEC to protect a user, both the zone must be signed and the resolver must validate signatures. A validating resolver that receives an unsigned response for a signed zone returns a SERVFAIL error rather than the unverified answer.
DNS-over-HTTPS and DNS-over-TLS
Encrypted DNS transports eliminate the UDP spoofing attack surface entirely. DNS-over-TLS (DoT, RFC 7858) wraps DNS in a TLS session on TCP port 853. DNS-over-HTTPS (DoH, RFC 8484) sends DNS queries as HTTPS requests, typically on port 443, making DNS traffic indistinguishable from web traffic. Because the connection is authenticated by a TLS certificate and all data is encrypted, a network attacker cannot inject forged responses — they cannot even observe the query content. Major public resolvers including Cloudflare (1.1.1.1), Google (8.8.8.8), and NextDNS support both DoT and DoH. Firefox and Chrome have built-in DoH support. The limitation is that DoH/DoT protect only the client-to-resolver leg; the resolver itself still queries authoritative servers over standard UDP unless it also uses encrypted transports for upstream queries.
Real-World Incidents
DNS poisoning has caused significant outages and attacks in practice. In 2010, a Chinese DNS misconfiguration caused .com and .net queries relayed through Chinese resolvers to return incorrect results for major sites including Facebook, Twitter, and YouTube, affecting users in Chile and the United States whose ISPs had peering arrangements that routed through affected infrastructure. In 2019, a series of DNS hijacking attacks targeting Middle Eastern government and infrastructure domains used stolen registrar credentials to redirect authoritative DNS to attacker nameservers, allowing interception of email and VPN traffic by presenting fraudulent certificates obtained from CAs that validated domain control. These incidents illustrate that poisoning can occur at the resolver cache layer, at the authoritative server layer through credential compromise, and at the registrar layer through account takeover.
How to Check if Your Resolver Validates DNSSEC
Several public test tools verify whether your current DNS resolver performs DNSSEC validation. The simplest method is to query a deliberately broken DNSSEC domain: dnssec-failed.org is maintained by Comcast specifically for this purpose. A validating resolver returns SERVFAIL for this domain; a non-validating resolver returns the (invalid) address. You can test from the command line with dig dnssec-failed.org and checking whether the response is SERVFAIL, or use the web-based test at dnssec.vs.uni-due.de. The presence of the ad (Authenticated Data) flag in a dig response to a DNSSEC-signed domain indicates the resolver validated the signature chain successfully.
Practical Defenses
- Use resolvers that validate DNSSEC, such as Cloudflare 1.1.1.1, Google 8.8.8.8, or a self-hosted Unbound instance with validation enabled.
- Enable DoH or DoT on clients and browsers to protect the client-to-resolver path from spoofing.
- Sign your own DNS zones with DNSSEC and publish DS records at your registrar.
- Add CAA records to your domain so only authorized CAs can issue certificates for it.
- Protect registrar and DNS hosting accounts with hardware MFA to prevent credential-based hijacking.
- Monitor your authoritative DNS records with automated tools that alert on unexpected changes.
- Keep HTTPS enforced everywhere so a DNS redirect does not automatically become a content interception — an attacker who cannot obtain a valid certificate for your hostname will trigger a browser warning.
Frequently Asked Questions
What is DNS poisoning?
DNS poisoning is when DNS returns a false answer, such as sending a domain to the wrong IP address, often by corrupting or spoofing resolver cache data.
Does HTTPS protect against DNS poisoning?
HTTPS helps because a fake destination should not have a valid certificate for the real hostname, but DNS poisoning can still cause warnings, outages, or attacks against users who ignore certificate errors.
Does DNSSEC stop DNS poisoning?
DNSSEC helps resolvers validate that DNS records were signed by the legitimate zone, but it must be correctly deployed and validated to provide protection.