What is DNS cache poisoning? How to detect and prevent attacks

When you visit a website, your device relies on cached Domain Name System (DNS) records to quickly resolve the domain name to an IP address. These cached records are meant to reduce the time needed to reach known sites. However, if the cached data is altered, it can direct your browser to the wrong destination.

DNS cache poisoning is an attack that targets the stored records that link domain names to IP addresses, allowing malicious redirections to occur beneath the surface.

In this guide, we’ll break down what DNS cache poisoning is, how it works, and how to detect and prevent it. You’ll learn the methods attackers use, the signs of a compromised cache, and the practical steps to keep DNS resolution secure.

What is DNS cache poisoning, and why is it dangerous?

DNS cache poisoning is a type of DNS manipulation that corrupts stored DNS data. Instead of changing DNS settings directly, an attacker injects forged DNS information into the cache of a DNS resolver (the server that looks up domain names and returns their IP addresses). When that cache is later used to answer a query, it returns the forged address, sending users to the wrong destination.

Once an attacker controls where your DNS lookups send you, they can:

• Redirect you to fake login pages that collect credentials or multi-factor codes.
• Serve malware or malicious scripts from look-alike sites.

DNS cache poisoning is a quiet but effective way to manipulate how users are directed online, and it often goes unnoticed because the web address will appear to be correct.

How DNS caching works

Before looking at how attackers exploit DNS behavior, it’s worth reviewing how caching actually works.

What is DNS caching?

When you visit a website, your device needs to find the IP address linked to its domain name. Instead of performing this lookup from scratch every time, DNS caching stores the results of previous lookups for a set period. These temporary records can be stored in your browser, your operating system, your router (if it runs a caching DNS resolver), or a DNS resolver operated by your internet service provider (ISP) or a third party.

Each cache answers future requests for the same domain from its stored data. This process allows lookups to be completed more quickly and with less network overhead.

The role of TTL

Every DNS record includes a timer known as its time to live, or TTL. TTL tells caches how long a record should be considered valid. Once the timer runs out, the cache discards the record and performs a new lookup to refresh the data.

Short TTL values mean records are replaced frequently, which keeps information up-to-date but increases the number of DNS queries. Long TTL values reduce DNS query traffic but allow cached data to remain in use for longer periods.

Benefits and risks of DNS caching

DNS caching prevents repeated lookups for frequently visited domains, shortens response times, and reduces the workload on DNS servers. For organizations that operate their own resolvers, caching also saves bandwidth and improves network performance.

However, caching also introduces risk. DNS caches are built to store answers, not to confirm their authenticity. Unless a security feature such as Domain Name System Security Extensions (DNSSEC) is used, caches have no way to verify that the data they receive is genuine.

How DNS cache poisoning works

Most DNS resolvers use the User Datagram Protocol (UDP) for standard lookups because it handles requests quickly. With UDP, the resolver sends a small data packet and waits for a reply, but it doesn’t establish a confirmed connection or check whether the responder is genuine. This is the main difference between UDP and Transmission Control Protocol (TCP), which has a three-way handshake that ensures the request is actually coming from the source it claims.

Skipping those checks makes DNS lookups faster, but the tradeoff is that if a forged response that looks valid arrives before the real one, the resolver may accept and cache it.

DNS spoofing vs. DNS poisoning

The terms “DNS spoofing” and “DNS cache poisoning” are related but not identical.

• DNS spoofing is the act of creating or sending forged DNS responses that imitate legitimate ones.
• DNS cache poisoning is what happens when one of those forged responses is accepted and stored by a cache, corrupting its data.

DNS hijacking is a different threat that alters DNS settings on a router, device, or registrar account to redirect all future lookups to a malicious server.

Common DNS spoofing techniques

Attackers can use several techniques for DNS spoofing.

Transaction ID guessing

Each DNS query includes a 16-bit transaction ID that helps a resolver match replies to requests. Resolvers also use a UDP source port (the temporary port assigned to that specific query) as part of the matching process. If either of these identifiers is predictable (for example, if transaction IDs are assigned sequentially or generated with weak randomness), attackers can guess the correct values with far fewer attempts than should be possible.

In environments where attackers have some control over the network, such as shared or insecure local networks, an additional risk exists: they may be able to observe DNS requests and race to send a forged response before the legitimate one arrives, or they may intercept and modify the returning responses.

By flooding a resolver with forged responses that each use a different guessed ID, an attacker increases the chance that one will match the real query. If the forged reply arrives first, the resolver may accept it as legitimate and cache the false record.

Modern resolvers protect against this by randomizing transaction IDs and source ports, making successful guessing attacks far less likely. Outdated or poorly configured systems, however, can still be at risk.

Man-in-the-middle (MITM) attacks

In MITM attacks, an attacker intercepts DNS traffic as it moves across the network, for example, on an open Wi-Fi network or through a compromised router. By watching the queries and replying faster than the real DNS responder, the attacker can supply a forged answer that appears valid.

In this context, DNS spoofing is part of a broader interception attack rather than a separate technique. Note that these attacks are only possible when DNS data travels in plaintext; when DNS traffic is encrypted or responses are digitally verified, intercepting or forging them becomes far more difficult.

Cache injection through forged responses

Many large-scale cache poisoning attempts follow a simple sequence:

1. The attacker forces the resolver to make a fresh lookup by causing a client or the resolver itself to request a name it won’t already have, typically a random subdomain such as x7ytfj3.example.com. This can be done by embedding the name in a malicious webpage or ad the client loads, by having compromised devices on the network make the lookup, or by querying an open/misconfigured resolver directly.
2. While the resolver waits for the genuine response, the attacker floods it with forged replies containing a fake IP address.
3. If a forged reply matches all the expected details and reaches the resolver first, it’s accepted and cached.
4. Any user who later requests that domain receives the forged address until the record expires or the cache is cleared.

Because resolvers often serve many users, a single successful injection can affect large groups of people who rely on that DNS service.

Real-life examples of cache poisoning

DNS cache poisoning has appeared both in research demonstrations and in real-world cyber incidents. The following are some examples of how weaknesses in the DNS protocol have been discovered, demonstrated, or even exploited in recent years.

The Kaminsky attack (2008)

Security researcher Daniel Kaminsky demonstrated a practical, large-scale cache-poisoning technique. This was not an attack in the wild but a research finding showing that an attacker could force a resolver to make repeated lookups for random subdomains of a target domain and then race forged replies against legitimate ones.

His work revealed how limited entropy in DNS (16-bit transaction IDs and predictable resolver behavior at the time) made such attacks feasible. The disclosure prompted a coordinated, multivendor fix that improved source-port and transaction ID randomization.

SAD attack (2020)

Side-channel attacked DNS (SAD DNS) was another research discovery, not an observed real-world incident. Researchers from the University of California, Riverside, and Tsinghua University, Beijing, China, found a side channel in how operating systems rate-limit Internet Control Message Protocol (ICMP) “Port Unreachable” messages. By measuring these responses, an attacker could infer the UDP source port a resolver used, significantly reducing DNS query randomness and making spoofed responses more achievable.

The main mitigation for this threat involved OS patches that added randomness to ICMP rate-limiting behavior, closing the timing leak. Additional protections such as DNSSEC validation further reduce the risk.

Brazil ISP DNS poisoning attack (2011)

In contrast to the previous two research demonstrations, this was a real-world cyberattack. Millions of Brazilian internet users were redirected to phishing sites when multiple Brazilian ISPs suffered a major cache poisoning attack. The attackers injected forged DNS records so that popular banking domains resolved to malicious servers. The redirected sites harvested banking credentials and, in some cases, tried to install financial malware.

This attack exposed weak DNS protections at several ISPs and highlighted the need for stronger resolver security.

Symptoms of DNS cache poisoning

While DNS poisoning happens behind the scenes, its effects can show up in subtle ways. Recognizing those signs can help limit the impact on users or networks.

How to spot possible DNS poisoning

DNS cache poisoning often goes unnoticed; there’s no pop-up that says “your resolver has been compromised.” However, certain patterns, known as indicators of compromise (IOCs), can signal that your DNS data may have been tampered with, especially when multiple devices on the same network are affected.

Individual users should look for:

• Redirection to login pages that don’t match the usual design or URL.
• Browsers showing certificate warnings for sites that normally have valid HTTPS.
• Unexpected pop-ups, ads, or requests for login credentials.

Administrators should look for:

• A well-known website resolving to an IP address that doesn’t match results from trusted public DNS services.
• A device or router suddenly using a DNS server that looks unfamiliar or isn’t provided by your ISP, workplace, or usual DNS provider.
• Their resolver returning DNS answers that don’t match the authoritative records or trusted public DNS services.

Tools and techniques for detection

If you notice any of the above IOCs, these steps can help confirm whether DNS cache poisoning has occurred.

For individual users or small offices

1. See which DNS server your device is using: Open your device’s Wi-Fi or network settings and look under DNS or IP configuration. You should see familiar DNS addresses such as Google (8.8.8.8), Cloudflare (1.1.1.1), or your internet provider. If you notice an unfamiliar DNS address, especially one that doesn’t match your provider or what you configured, it may indicate a misconfiguration or unauthorized change.
2. Compare DNS results: Use a trusted lookup service like Google DNS or Cloudflare’s DNS checker and look up a well-known site. Then, verify the results from your own system. If your local resolver returns an unexpected or suspicious IP address that differs from the trusted lookup, it may indicate incorrect or tampered DNS data.

• On Windows or other systems that include nslookup, you can directly query a trusted DNS server by specifying it in the command: nslookup www.example.com 1.1.1.1.
  
• If you’re not on Windows, the most common tool is dig, which uses a slightly different syntax: dig A www.example.com @1.1.1.1 (“A” specifies the record type.).

3. Clear your DNS cache. This removes old or corrupted entries and forces your device to fetch fresh DNS data. If the issue disappears afterwards, it suggests the problem may have been local caching. If it returns, the problem could be with your router or DNS provider.

For administrators

These checks require more technical access and tools, but they can detect manipulation of DNS traffic that end users won’t notice.

1. Inspect DNS traffic with packet-capture tools: Packet analysis tools such as Wireshark or tcpdump can help reveal DNS replies arriving from unexpected IP addresses, unsolicited or unusually fast responses (often seen in spoofing attempts), mismatched transaction IDs, or DNS responses that appear before the device’s query was fully sent. These patterns can indicate manipulation of unencrypted DNS traffic.
2. Verify records directly with the authoritative servers: If you want to confirm whether a suspicious DNS result is coming from a cache or from the source, you can query the domain’s authoritative name servers (the servers that store the domain’s official DNS records). If the authoritative server gives one IP address but your resolver returns a different one, it suggests that something in the middle (such as a cached record or a misconfigured resolver) may be producing incorrect results.
3. Review resolver logs for unusual DNS behavior: Many DNS resolvers (including Windows Server DNS) can record details about the queries they process and the servers they contact. These logs can help administrators spot unusual behavior. For example, if the resolver suddenly begins sending queries to a DNS server that’s not part of your normal configuration, or if a domain that normally resolves without issues begins generating repeated failures, this may indicate a configuration problem or interference on the network.

How to prevent DNS cache poisoning

There is no single control that eliminates the risk of DNS cache poisoning; the most effective approach combines protocol-level protections, careful configuration, and network hygiene.

Use DNSSEC

DNS Security Extensions (DNSSEC) adds a layer of cryptographic verification to DNS responses. Zone operators (the administrators or hosting providers responsible for managing a domain’s DNS records) use private keys to digitally sign their DNS record sets, creating proofs that resolvers can verify with corresponding public keys published in the DNS system.

When DNSSEC is correctly deployed and validated, it becomes far harder for an attacker to inject forged responses. A validating resolver checks whether a domain’s DNS records include valid signatures. If a domain is configured for DNSSEC and a trusted chain of verification exists, the resolver rejects any data that fails validation, preventing tampered records from being cached.

The limitation is that DNSSEC only works when every part of the process (from the domain’s zone to the validating resolver) supports it. Many domains still lack DNSSEC, and some resolvers don’t perform validation, leaving gaps in protection. Even so, for critical domains and networks, enabling DNSSEC remains one of the most effective safeguards against forged DNS data.

Keep DNS software patched and updated

Many historical DNS poisoning attacks have exploited implementation bugs and predictable behavior in DNS software. Modern resolvers include mitigations such as randomizing source ports, using stronger transaction ID randomization, and applying additional checks before accepting responses.

To benefit from these improvements, administrators need to keep their DNS software updated. Regular patching reduces exposure to known DNS server vulnerabilities that make poisoning easier.

Enable secure configurations (DoT and DoH)

Encryption protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH) protect DNS queries in transit between clients and resolvers. They’re not replacements for DNSSEC, and they don’t prevent cache poisoning on their own. However, they help in two important ways.

First, they make it much harder for on-path attackers (such as those on public Wi-Fi) to see and tamper with DNS queries and responses. This reduces the feasibility of MITM attacks. Second, they help ensure that clients are communicating with the intended resolver, provided the client verifies the resolver’s digital certificate during the connection. From a configuration standpoint, enabling DoT or DoH on clients and resolvers is a practical way to reduce the opportunities for network-based spoofing and tampering.

Educate users on DNS risks

User behavior plays a role in the impact of DNS attacks. Cache poisoning often leads to phishing pages that rely on users entering credentials without noticing subtle warnings.

Useful user education tips include:

• Be cautious with links and URLs: Avoid clicking on unexpected links, and check for subtle typos, unusual subdomains, or inconsistencies in URLs.
• Treat certificate warnings seriously: Major browsers advise users not to continue past HTTPS warnings, because they indicate that the connection may be unsafe.
• Watch for suspicious login prompts: Prompts that appear in unusual contexts, such as links in messages or pop-ups, should be avoided.

Limit trust relationships in the DNS hierarchy

For organizations that run their own resolvers or authoritative name servers, architectural choices have a big influence on exposure. Good practices include:

• Keep DNS roles separate: Run resolvers and authoritative servers on different systems, so if one is compromised, it won’t immediately expose the other.
• Restrict access to internal resolvers: Only allow trusted devices inside your network to send queries. Place these servers behind a firewall instead of leaving them open to the public internet.
• Use randomization features: Configure resolvers to randomize the network port numbers they use and, where supported, apply “0x20 encoding,” which mixes uppercase and lowercase letters in domain queries. Both methods make it harder for attackers to predict how a resolver will send requests and spoof matching responses.
• Control DNS zone transfers: Zone transfers let secondary (backup) name servers copy DNS records from the primary server. Restrict this feature to authorized servers only, and use access control lists to prevent anyone else from downloading your DNS data.

Layer protection through VPN and private resolvers

For everyday users, one practical way to avoid DNS cache poisoning is to use DNS resolvers that are protected and isolated from public networks. Many reputable VPN services like ExpressVPN route DNS queries to their own private resolvers, keeping your lookups off local or ISP servers.

This setup can:

• Bypass compromised DNS servers on local networks.
• Reduce exposure on public Wi-Fi by keeping DNS traffic inside the VPN tunnel.
• Keep lookups consistent, avoiding leaks or unexpected resolution behavior.

It’s important to note that this approach doesn’t eliminate all risks: if the VPN’s resolver itself were compromised, DNS poisoning could still occur. Nevertheless, it’s a practical layer of protection against most network-based attacks.

DNS security in a broader cybersecurity context

To understand why cache poisoning matters, it helps to see how DNS fits into the larger security ecosystem.

Why DNS security is foundational

DNS is often called the internet’s phone book, but it does more than translate names into IP addresses. It underpins how browsers find websites, how email servers locate destinations, and how many cloud services route data. Because so many systems depend on it, any attack that changes DNS responses can redirect or intercept traffic before other protections (like HTTPS or firewalls) come into play.

Cache poisoning is one of several DNS-level threats. It doesn’t crash services or cause obvious errors, which makes it more dangerous: users believe they’ve reached the correct site even when they’ve been silently redirected elsewhere.

Emerging threats in DNS security

Attackers today use DNS in far more dynamic ways than before. Some use domain-generation algorithms (DGAs): programs that automatically create thousands of random domain names every day. This helps them evade blocking lists because the moment one domain is shut down, new ones appear. Others use a method called fast-flux, where a single domain rapidly switches between many IP addresses. This makes malicious sites harder to trace or take offline.

At the same time, many services now rely on cloud-based DNS platforms, and a simple misconfiguration there (such as leaving an old record active or pointing to the wrong IP) can expose users to hijacked traffic.

The rise of encrypted DNS protocols also changes how security teams work. These protocols protect user privacy by hiding DNS queries from network observers, but they can also make it harder for organizations to monitor DNS traffic for signs of attack.

All of these developments make DNS attacks more varied and complex. Defenders must now secure both the accuracy of DNS data and the systems that store and deliver it.

The importance of anti-spoofing controls (BCP 38)

BCP 38, defined in RFC 3704, is a network-level best practice that prevents service providers from routing packets that claim to originate from IP addresses outside their legitimate network range. It was created to reduce large-scale distributed denial-of-service (DDoS) attacks that rely on spoofed traffic, but it also indirectly strengthens DNS security.

By blocking forged packets, BCP 38 makes it harder for attackers to send spoofed DNS responses that impersonate a legitimate resolver, which is one of the techniques used in DNS cache poisoning. Although end users can’t enable BCP 38 themselves, organizations and ISPs that implement it contribute to a more trustworthy DNS ecosystem.