I recently started gathering materials for an article about DNSSEC and stumbled upon something fascinating — I couldn’t find a single confirmed case of a significant security incident involving DNS cache poisoning in the past five years. That struck me as odd.

Can you imagine? A once-popular and widely feared attack technique hasn’t been successfully used, at least publicly, in half a decade. Clearly, something has changed. Let’s explore what happened, and whether DNS cache poisoning is still a threat worth worrying about.

What Is DNS Cache Poisoning?

DNS cache poisoning, also known as DNS spoofing or DNS response tampering

is a method of deceiving systems by injecting fraudulent DNS responses into the cache of a DNS resolver. This tricks users into connecting to malicious servers instead of legitimate ones.

To understand how it works, let’s first look at the basics of DNS resolution — and then walk through a detailed attack scenario.

What Happens During a Normal DNS Lookup?

Imagine Alice, a regular user who wants to buy Bitcoin using her credit card on a trusted cryptocurrency exchange run by Bob.

She opens her browser and types in:

https://bobcrypto.io

At this point, her computer needs to translate the domain name into an IP address in order to connect to Bob’s server using the Internet Protocol. This is where the Domain Name System (DNS) comes into play.

Step 1: Alice’s Device Checks Locally

Her device first checks if it already knows the IP address for bobcrypto.io — maybe it visited the site earlier, and the address is still cached.

If the address isn’t cached, the system moves to the next step.

Step 2: The Resolver Walks the DNS Hierarchy

Alice’s computer sends a DNS query to a recursive resolver — usually provided by her internet service provider or a public service like Cloudflare or Quad9.

The query is essentially asking:

“What is the A record (or AAAA record) for bobcrypto.io?”

• An A (Address) record maps the domain name to an IPv4 address, like 203.0.113.42.
• An AAAA (Quad-A) record maps it to an IPv6 address, like 2001:db8::1.

The resolver has its own cache and may already know the answer. If not, it begins the process of resolving the request through the DNS hierarchy.

1. Root server → Points to name servers for the .io top-level domain.
2. .io TLD server → Points to the authoritative name server for bobcrypto.io.
3. Authoritative name server → Provides the A and/or AAAA records for bobcrypto.io.

The recursive resolver caches the result for future queries and sends the IP address back to Alice’s device.

    sequenceDiagram
	  participant Alice as Alice
	  participant Resolver as Recursive<br>Resolver
	  participant Root as Root Server
	  participant TLD as .io TLD Server
	  participant AS as Authoritative<br>Server
	
	  Alice ->> Resolver: Query A/AAAA for bobcrypto.io
	  Resolver ->> Root: Where is .io?
	  Root -->> Resolver: List of .io TLD servers
	  Resolver ->> TLD: Where is bobcrypto.io?
	  TLD -->> Resolver: bobcrypto.io name server
	  Resolver ->> AS: A/AAAA for bobcrypto.io
	  AS -->> Resolver: 203.0.113.42 / 2001:db8::1
	  Resolver -->> Alice: IP address (A/AAAA records)

Step 3: Alice Connects to Bob’s Crypto Exchange

Now equipped with the correct IP address, Alice’s browser initiates a secure HTTPS connection to Bob’s legitimate server. She can now enter her credit card details and purchase Bitcoin.

The Classic DNS Spoofing Scenario: DNS Cache Poisoning

Now let’s imagine what happens when an attacker manipulates the DNS process itself. In this classic spoofing scenario, the attacker — let’s call her Eve — doesn’t target Alice or Bob directly. Instead, she targets the recursive DNS resolver that sits between them. Eve’s goal is to make the resolver return a forged IP address for bobcrypto.io, pointing to a server that she controls.

DNS cache poisoning exploits the fact that recursive resolvers temporarily store (cache) responses to DNS queries. Eve wants to insert a false DNS response into that cache — so when Alice asks for bobcrypto.io, the resolver replies with the wrong IP address.

Here’s how the classic attack unfolds:

1. Eve (the attacker) triggers a DNS query for bobcrypto.io by sending a request through the resolver.
2. She then floods the resolver with fake DNS responses, racing to guess the right combination of response parameters, like Transaction ID and Source port.
3. If a forged response arrives before the legitimate one — and matches the expected parameters — the resolver accepts Eve’s fake data as authentic.
4. That poisoned response is cached and served to future users asking for the domain — including Alice.

    sequenceDiagram
	  participant Alice as Alice
	  participant Resolver as Recursive<br>Resolver
	  participant Root as Root Server
	  participant TLD as .io TLD Server
	  participant AS as Authoritative<br>Server
	  participant Eve as Eve<br>(Attacker)
	
	  Eve ->> Resolver: Query A/AAAA for bobcrypto.io
	
	  Resolver ->> Root: Where is .io?
	  Root -->> Resolver: List of .io TLD servers
	
	  Resolver ->> TLD: Where is bobcrypto.io?
	  TLD -->> Resolver: bobcrypto.io name server
	
	  Resolver ->> AS: A/AAAA for bobcrypto.io
	
	  par Spoofing Race
	    Eve -->> Resolver: Forged response: bobcrypto.io → 198.51.100.66
	    AS -->> Resolver: Legit response: bobcrypto.io → 203.0.113.42
	    Note over Resolver, Eve: Resolver accepts forged response<br>and caches it
	  end
	
	  Alice ->> Resolver: Query A/AAAA for bobcrypto.io
	  Resolver -->> Alice: Fake IP address (198.51.100.66)

Alternative Scenario: On-Path Spoofing (Tampering in Transit)

In another variant of DNS spoofing, Eve doesn’t attempt to poison a resolver’s cache. Instead, she intercepts DNS queries directly in transit. This attack requires Eve to have on-path access between the victim and their DNS resolver — a classic Man-in-the-Middle (MitM) position.

Let’s walk through an example:

1. Alice connects to a malicious Wi-Fi hotspot named FreeCaffeWiFi, believing it’s legitimate.
2. Eve controls the hotspot and is running a transparent DNS proxy.
3. When Alice tries to visit bobcrypto.io, her device sends a DNS query to her configured resolver.
4. Instead of forwarding the request, Eve intercepts it and immediately responds with a forged DNS reply.
5. The response directs Alice to the IP address of a phishing server controlled by Eve.

To Alice, everything appears normal — the browser connects to bobcrypto.io, but it’s actually loading content from a malicious server.

    sequenceDiagram
	  participant Alice as Alice
	  participant Eve as Eve's<br>Malicious<br>Hotspot
	  participant Phishing as Eve's<br>Phishing<br>Server
	
	  Note over Alice, Eve: Alice connects to public Wi-Fi: "FreeCaffeWiFi"
	
	  Alice ->> Eve: DNS query for bobcrypto.io
	  Eve -->> Alice: Spoofed DNS response → 198.51.100.66 (phishing IP)
	  Alice ->> Phishing: HTTPS request to bobcrypto.io

This type of attack is often seen in rogue access point setups, compromised local networks, or when DNS queries are sent unencrypted.

Consequences of DNS Cache Poisoning

A successful DNS cache poisoning attack can be highly disruptive and dangerous. Attackers are able to silently reroute users to malicious websites without their knowledge. One of the most concerning aspects is that a single compromised recursive resolver can affect thousands of users at once, making the attack highly efficient and scalable.

The two most common and impactful consequences of a successful DNS cache poisoning attack:

1. Data Theft
   Victims may be redirected to phishing websites that closely mimic trusted services. When users enter their login credentials or sensitive information, the data is captured by the attacker and may be used for fraud or sold on criminal marketplaces.
2. Malware Infection
   Spoofed DNS responses can lead users to malicious sites designed to infect their systems. This can happen via drive-by downloads or deceptive prompts that trick users into installing malware.

Of course, these are not the only possible consequences — but they are among the most frequent and damaging outcomes observed in real-world cases.

Successful DNS Cache Poisoning Attacks

Let’s overview a few successefull DNS spoofing attacks, and see how they can be leveraged in a variety of ways, from a simple traffic redirection to large-scale disruption and malware distribution. I think it will definitely be clear why this was so serious¹ after you read about them.

I can show you how deep the Internet really goes

Discover exposed assets, infrastructure links, and threat surfaces across the global Internet.

1. Massive DNS poisoning attacks in Brazil in 2011

In November 2011, Kaspersky’s Global Research & Analysis Team (GReAT) reported² a series of large-scale DNS cache poisoning attacks targeting multiple Internet Service Providers (ISPs) in Brazil. These attacks redirected users to malicious websites prompting them to download and install malware, such as a Trojan banker disguised as a “Google Defence” tool. The malware exploited vulnerabilities in outdated Java Runtime Environments, including CVE-2010-4452, to execute arbitrary code on users’ machines. The attackers utilized compromised IP addresses to host various malicious files, including executables and Java applets, which were detected by Kaspersky’s heuristic engine.

A clean machine displaying warning when opening Google.
Screenshot by GReAT (securelist.com)

Additionally, some companies reported attacks on their network devices, where attackers remotely accessed routers or modems and modified their DNS configurations. Consequently, when employees attempted to access websites, they were prompted to execute a malicious Java applet, leading to the installation of a Trojan banker.

2. The Poisoned Hurricane in 2014

In 2014, a sophisticated cyberattack known as the “Poisoned Hurricane” leveraged a vulnerability in Hurricane Electric’s authoritative DNS servers to redirect users to attacker-controlled websites. These servers, which were configured to allow anyone to register a free DNS zone and create records pointing to arbitrary IP addresses, were exploited by attackers to hijack legitimate domains. While this case is not a classic DNS cache poisoning attack, it exploits similar principles.

By creating fake DNS entries for domains like adobe.com and outlook.com, the attackers redirected users to malicious sites. When infected machines queried these spoofed domains, the servers returned attacker-controlled IP addresses, effectively poisoning the DNS cache of those machines. This redirection facilitated the distribution of a variant of the PlugX malware, also known as Kaba, which was configured to use Hurricane Electric’s servers as recursive resolvers. As a result, users were directed to fake websites, leading to credential theft, malware installation, and other malicious activities. By August 4, 2014, Hurricane Electric had ceased returning answers for these hijacked domains.

3. A Cache Poisoning Attack Targeting DNS Forwarding Devices

In August 2020, Xiaofeng Zheng and colleagues presented³ a novel cache poisoning attack targeting DNS forwarding devices, titled “Poison Over Troubled Forwarders”. This research highlights a critical vulnerability in the DNS infrastructure, where DNS forwarders—devices that relay DNS queries from clients to recursive resolvers — can be exploited to inject malicious DNS records.

A slide from the presentation by USENIX dedicated to the "Poison Over Troubled Forwarders" attack

The attack leverages a controlled domain to insert rogue DNS records into the cache of vulnerable forwarders, circumventing existing defenses against traditional cache poisoning. The team identified several susceptible implementations across popular home router models and DNS software, including those from major vendors like D-Link, Linksys, and Microsoft DNS.

Why DNS Cache Poisoning Is No Longer Widely Exploited

Actually, I can’t find anything newer than this last attack, based on defragmentation. And to be honest, it’s too complicated and has many implementation restrictions.

The question is – why? Over the last decade, a few measures have been implemented on a global level that make DNS cache poisoning almost impossible to execute on a large scale.

1. DNSSEC Deployment

DNS Security Extensions (DNSSEC) is one of the most important safeguards introduced to protect against DNS spoofing. In fact, it was specifically developed in response to threats like DNS cache poisoning. DNSSEC adds a layer of cryptographic verification to DNS records, allowing resolvers to confirm the authenticity of data received from authoritative servers.

However, DNSSEC only works when both the resolver and the domain support it — and it does not enforce validation at the operating system level. This means DNSSEC cannot protect clients from attacks involving compromised resolvers or poisoned forwarders. Still, its growing adoption has significantly reduced the opportunities for cache poisoning through traditional recursive resolution paths.

That said, DNSSEC adoption remains relatively low. While some top-level domains and large organizations have implemented it, the majority of domain owners still do not sign their zones. On the client side, many resolvers — including those used by ISPs or mobile providers — do not validate DNSSEC by default.

2. Browser-Side Security Measures

I believe that the key enhancement is the adoption of HTTPS as the default connection method. The availability of free, automated certificate issuance — primarily driven by the ACME protocol⁴ and certification authorities like Let’s Encrypt — has democratized HTTPS adoption. So even if an attacker can perform a successful DNS spoofing attack, the absence of a valid certificate will significantly reduce the damage, as browsers will flag the connection as insecure.

You might ask: well, why don’t attackers just redirect users to HTTP instead?

1. Many services today implement HSTS (HTTP Strict Transport Security) policies, which prevent browsers from falling back to insecure HTTP connections once a site has been accessed over HTTPS.

2. Even without this policy, modern browsers default to HTTPS when a user enters a domain name — not HTTP. The browser automatically attempts a secure connection first, making it harder for attackers to exploit HTTP redirection.

3. Finaly, if an attacker somehow redirects a user to an HTTP version of the site, modern browsers will clearly inform the user. Warnings about insecure connections or insecure form submissions are now standard and highly visible — discouraging users from proceeding or entering sensitive data.

3. Increased Implementation Complexity

Lastly, modern DNS resolvers and client-side libraries now incorporate multiple hardening techniques that make spoofing responses much harder:

• Randomized Source Ports: By randomizing the UDP port used for each DNS request, attackers can no longer reliably guess the correct tuple (source port, transaction ID).
• Defensive Caching: Recursive resolvers now often ignore unsolicited or out-of-window responses, reducing the risk of accepting forged answers.
• 0x20 Bit Encoding: Randomizes the capitalization of letters in DNS queries (e.g., GoOgLe.CoM). The resolver checks if the response preserves the case, adding extra entropy.

Together, these factors have pushed DNS cache poisoning into the realm of impractical attacks for most adversaries. While theoretically possible, it’s no longer a viable tool for widespread exploitation — especially compared to easier and more scalable alternatives like phishing or BGP hijacking.

Why We Can’t Just Forget About DNS Spoofing

Despite its declining relevance on the public internet, DNS spoofing is not a fully extinct threat. There are still scenarios where this technique can be practically exploited, especially in environments where modern protections are absent or misconfigured.

One such area is the use of unsecured protocols that don’t rely on HTTPS or certificate validation — including legacy systems, custom enterprise software, or internal tools.

IoT devices are another weak point. Many smart devices use lightweight or outdated DNS clients, lack support for DNSSEC, and do not enforce HTTPS. They often accept whatever DNS configuration is pushed to them, making them vulnerable to DNS cache poisoning or malicious redirection inside a compromised network.

Finally, lateral movement within local networks remains a relevant attack surface. If an attacker gains a foothold in a local network, they may spoof DNS responses locally to redirect traffic, harvest credentials, or install malware. In such environments, browser-based defenses and certificate validation may not apply — especially for internal domains or services.

Modern Trends

While classic DNS cache poisoning attacks have become rare, the elegance, stealth, and power of DNS manipulation remain attractive to attackers. The ability to silently redirect traffic, impersonate trusted services, and intercept sensitive data is still a powerful concept in offensive operations.

In recent years, we’ve seen a shift from traditional spoofing to DNS hijacking — a more persistent and infrastructure-level form of attack. Unlike spoofing, which typically targets a single query in transit, DNS hijacking compromises authoritative DNS records, registrar accounts, or name server settings, enabling long-term redirection of traffic at the global scale.

My recent research suggests that DNS hijacking is now the modern replacement for cache poisoning attacks. High-profile incidents like the 2022 Curve Finance hack⁵, where attackers modified DNS records to redirect users to a fake frontend and steal funds, highlight the ongoing relevance of DNS manipulation. Other similar cases have affected cryptocurrency platforms, telecoms, and even government domains.

These attacks often bypass traditional endpoint protections entirely, and they don’t require breaking into the target server. As long as attackers can modify how the domain resolves — either by compromising DNS infrastructure or account credentials — they can achieve devastating effects with minimal noise.