DNS cache poisoning is a cyberattack where false information is entered into a DNS cache to redirect users to incorrect or malicious websites. Also known as DNS spoofing, this tactic intercepts the "phone book" of the internet to send traffic to the wrong IP addresses until the cached data is corrected. For marketers and SEO practitioners, this represents a severe risk to brand reputation and traffic integrity.
What is DNS cache poisoning?
DNS cache poisoning involves placing corrupt Domain Name System data into a DNS resolver’s cache. DNS resolvers are designed to translate human-readable names like example.com into machine-readable IP addresses. To speed up the web, resolvers save these responses in a local cache for a specific period, known as the Time to Live (TTL).
Attackers exploit the fact that many resolvers cannot verify the data they store. Once a resolver caches a fraudulent IP address, it supplies that false data to every user who makes the same request until the TTL expires or the information is manually removed. This attack does not disconnect a real website from its actual IP address; it simply redirects the pathway for users relying on the poisoned resolver.
Why DNS cache poisoning matters
- Risk of traffic hijacking: Attackers can divert your legitimate visitors to a site of their choosing, causing an immediate drop in organic traffic.
- Credential and data theft: Poisoned caches are often used to facilitate phishing campaigns where users unknowingly enter login details or credit card information on a fake version of your site.
- Search engine penalties: If a domain is redirected to a site serving malware or computer worms, the legitimate brand may suffer long-term damage to its search rankings.
- Censorship: Several governments have intentionally poisoned DNS caches to deny access to specific web resources within their countries.
How DNS cache poisoning works
- The query: A DNS resolver makes a request to an authoritative nameserver to find an IP address.
- The impersonation: Attackers impersonate the authoritative nameserver by forging a reply before the real response arrives.
- The UDP vulnerability: Unlike TCP, which requires a communication "handshake," DNS uses UDP (User Datagram Protocol). In UDP, there is no guarantee that a connection is open, making it easy for attackers to forge headers and pretend to be a legitimate server.
- The race against time: Attackers have only a few milliseconds to send a fake reply before the legitimate response from the authoritative server arrives.
- The storage: If the resolver receives the forged response first, it accepts and caches the data uncritically.
To succeed, attackers must guess several factors: which queries are not currently cached, which port the resolver is using (which is now often randomized), the request ID number, and the authoritative nameserver the query is headed toward.
Variations of the attack
| Variation | Mechanism | Impact |
|---|---|---|
| Domain Redirect | Redirects the name server of the attacker’s domain to the target's name server, then assigns a malicious IP address as the "Additional Section" in the response. | Allows the attacker to resolve queries for the entire target domain. |
| NS Record Redirect | Redirects the Name Server (NS) record of a domain unrelated to the request to an IP address specified by the attacker. | The vulnerable server caches unrelated authority info, hijacking the target domain's traffic. |
| Malware-based Poisoning | Malware on a user's device alters the local DNS cache in the browser. | Directs that specific user to malicious sites whenever they click links. |
Best practices
- Adopt DNSSEC: Use Domain Name System Security Extensions to verify the integrity and origin of DNS data using public key cryptography. [DNSSEC extensions were first published in 2005] (Cloudflare), providing a way to digitally sign information.
- Update DNS software regularly: Maintain a strict cadence for patching applications to prevent the exploitation of known vulnerabilities. [BIND versions 9.5.0-P1 and above perform checks to ignore irrelevant records] (Wikipedia), which helps prevent common poisoning techniques.
- Enable source port randomization: Randomizing the source port of DNS requests, combined with secure random numbers for cryptographic nonces, reduces the probability of an attacker winning the "race" to provide a fake reply.
- Adopt DNS over HTTPS (DoH): Encrypt DNS traffic through an HTTPS session to improve privacy and hide queries from external viewers who might attempt to intercept or forge responses.
- Flush your DNS cache: If you suspect poisoning, use operating system functions to clear your local cache. This ensures the device has a "fresh start" and pulls correct information during its next query.
Common mistakes
Mistake: Using a slow or vulnerable DNS resolver. Fix: Choose a fast, DoS-resistant resolver with built-in poisoning controls. Attackers rely on delayed responses to buy time for their forged replies.
Mistake: Relying on the default "principle of trust." Fix: Traditional DNS was built on trust because the early internet was restricted to university and research centers. Modern setups should assume requests are compromised until validated through a Zero Trust approach.
Mistake: Overlooking traffic anomalies. Fix: Monitor for unexpected, sharp drops in web traffic or large changes in DNS activity for your domain, which are telltale signs of a poisoning event.
Mistake: Assuming all Top Level Domains (TLDs) are secure. Fix: Verify your specific TLD's protection. [As of 2020, all original TLDs and most large countries' ccTLDs support DNSSEC] (Wikipedia), but many second-level domains still do not.
DNS Cache Poisoning vs. DNS Spoofing
| Feature | DNS Cache Poisoning | DNS Spoofing |
|---|---|---|
| Definition | The actual method of entering corrupt data into a resolver's memory. | The broad category of attacks or the end result where a user sees a fake site. |
| Relationship | The attack mechanism. | The outcome of the attack. |
| Goal | Storing false records. | Diverting traffic to a malicious server. |
In common usage, the terms are interchangeable, though poisoning is technically the process and spoofing is the achieved status.
FAQ
How can I detect if my DNS cache has been poisoned? Manual detection is difficult. The most common indicators are unexpected drops in traffic or significant spikes in unusual DNS activity. Automated DNS security tools are the most effective way to identify inconsistencies between cached data and the data held by authoritative nameservers.
What happens if a government poisons a DNS cache? This is typically done for censorship. By intentionally entering false information into the country's DNS infrastructure, a government can deny access to specific web resources or redirect citizens to government-controlled landing pages instead of the intended websites.
Does clearing my browser cache fix DNS poisoning? Not necessarily. Browsers have their own caches, but the operating system and the ISP's recursive resolvers also maintain caches. To resolve the issue on your device, you should flush the DNS cache at the operating system level. If the poisoning occurred at the ISP level, you must wait for the TTL to expire or use a different, unpoisoned DNS resolver.
How does DNSSEC stop these attacks? [DNSSEC was implemented in Internet root zone servers in 2010] (Wikipedia) to add a layer of authentication. It uses public key cryptography to digitally sign DNS records. When a resolver receives a response, it checks the digital signature to ensure the data has not been tampered with and originated from the legitimate authoritative server.
Why is UDP more vulnerable than TCP for DNS? TCP requires a "handshake" to initiate communication, which creates a verified connection between two parties. DNS uses UDP, which has no handshake. An attacker can send a message via UDP with a forged header and the recipient has no built-in way to verify that the sender is who they claim to be.
