DNS cache poisoning is an attack in which an attacker causes a DNS resolver to store a fraudulent DNS record in its cache. When users subsequently request that domain, the resolver can return the forged record instead of the legitimate one, potentially redirecting them to an attacker-controlled destination.
DNS cache poisoning is a type of DNS spoofing, but the terms are not strictly interchangeable. DNS spoofing is the broader concept of causing a DNS query to receive a fraudulent answer, while cache poisoning specifically involves getting that false information stored in a resolver’s cache.
How DNS Cache Poisoning Works
The phone book.
DNS acts as the internet’s phone book, matching human-readable domain names (like example.com) to machine-readable IP addresses.
The cache shortcut.
DNS resolvers store recent lookups in a local cache, so repeat requests for the same domain don’t need a fresh lookup every time.
The injection.
Attackers exploit weaknesses in DNS resolution or response validation to cause a resolver to accept a forged DNS response and store the fraudulent information in its cache.
The redirect.
Unsuspecting users trying to visit a legitimate site are silently sent to the destination associated with the fraudulent DNS record, which may be attacker-controlled.
The persistence.
The fake record stays active in the cache until its Time-to-Live (TTL) expires or the cache is cleared manually -meaning subsequent requests using that resolver may continue receiving the fraudulent record during that period.
Risks and Real-World Impact
Credential theft.
Victims land on a convincing fake login page and hand over usernames and passwords directly to the attacker.
Malware distribution.
A poisoned domain can serve malicious downloads disguised as legitimate software or updates.
Intercepted communications.
Traffic that depends on correctly resolving a domain can be redirected to an unintended server. Whether an attacker can actually read or modify the resulting communication depends on additional protections such as HTTPS/TLS.
The best-known real-world example is the 2008 Kaminsky bug, named after security researcher Dan Kaminsky, which exposed a fundamental weakness in how DNS resolvers used transaction IDs and source ports to match responses to outstanding queries. The flaw made it possible for attackers to send large numbers of forged responses and increase the chance that a resolver would accept a fraudulent answer and cache it. It prompted an unusually coordinated, industry-wide emergency patch across major DNS software vendors and operators.
Prevention Methods
DNSSEC (Domain Name System Security Extensions).
Adds cryptographic digital signatures to DNS data, allowing validating resolvers to verify the authenticity and integrity of signed DNS records.
Encrypted DNS (DoH and DoT).
DNS over HTTPS and DNS over TLS encrypt the query and response, making it harder for an on-path attacker to observe or modify DNS traffic between a client and its resolver. However, encrypted DNS does not by itself prevent a resolver from returning data that is already poisoned in its cache.
Source port and transaction ID randomization.
Randomizing these values makes it harder for an attacker to successfully forge a DNS response that matches an outstanding query, reducing the risk of cache poisoning.
Reduced TTLs on sensitive records.
Can limit how long a successfully poisoned entry remains cached, but does not prevent the poisoning attack itself.
DNS Cache Poisoning vs. DNS Spoofing: Is There a Real Difference?
DNS spoofing is the broader category of attacks that cause DNS resolution to return fraudulent information. DNS cache poisoning is a specific technique in which fraudulent DNS information is accepted and stored in a resolver’s cache.
For example, an attacker may attempt to send a forged DNS response to a recursive resolver. If the resolver accepts the response and caches the fraudulent record, this becomes DNS cache poisoning. Subsequent users relying on that resolver may receive the false record until it expires or is removed.
Not every DNS spoofing attack involves cache poisoning. DNS traffic can also be manipulated in transit, DNS infrastructure can be compromised, or DNS configuration can be changed to direct users to an unauthorized resolver.
In simple terms:
- DNS spoofing = broader category
- DNS cache poisoning = a specific technique that stores fraudulent DNS information in a resolver's cache
The Cache Is the Attack Surface, Not Just the Shortcut
DNS cache poisoning works because the same mechanism that makes DNS fast caching answers instead of looking them up every time is exactly what gives a single successful forgery its reach and staying power. The goal is not to avoid caching, but to ensure that resolvers can validate DNS information before accepting and caching it. DNSSEC, randomized source ports and transaction IDs, and secure resolver configuration all help reduce the risk of cache poisoning.
Frequently Asked Questions (FAQ)
1. How do you stop DNS poisoning?
Use DNSSEC where supported, keep DNS resolver software updated, use randomized source ports and transaction IDs, and secure DNS configurations. DoH/DoT can also protect DNS traffic from on-path interception, but does not by itself prevent cache poisoning.
2. What's the difference between DNS hijacking and DNS poisoning?
DNS cache poisoning involves getting fraudulent DNS information stored in a resolver’s cache. DNS hijacking generally refers to unauthorized control or modification of DNS settings or infrastructure, although terminology can vary between sources.
3. Can you give a real-world example of DNS poisoning?
The 2008 Kaminsky vulnerability demonstrated how weaknesses in DNS response validation could be exploited to increase the likelihood of fraudulent responses being accepted and cached by recursive resolvers.
4. What are the symptoms of a DNS attack, including cache poisoning?
Possible signs include unexpected DNS results, being redirected to an unfamiliar destination, or browser certificate warnings. However, different DNS results can also have legitimate causes such as CDNs, load balancing, or normal DNS changes.
Secure DNS. Block threats before they spread.
Prevent DNS attacks, block malicious domains, and protect critical traffic without disrupting your online services.
