Back to Blogs

What Is DNS Cache Poisoning?

DNS cache poisoning happens when false DNS information is stored by a resolver. Users who ask that resolver for a domain can then receive an attacker-controlled IP address instead of the legitimate address.

This guide explains DNS cache poisoning and DNS spoofing for beginners, including the attack race, effects, warning signs, and prevention methods.

DNS Cache PoisoningDNS SpoofingRecursive DNSDNSSECDNS Security

DNS Cache Poisoning Explained

Simple definition: an attacker causes a DNS resolver to remember a false answer. Until the bad DNS record expires or is removed, multiple users may be directed to the wrong server.

For example, the correct address for portal.example may be 198.51.100.24. A poisoned cache could instead store 203.0.113.66, an example address representing an attacker-controlled server. The real website and its real IP remain unchanged; the resolver is simply returning the wrong directions.

DNS cache poisoning attack flow showing a user query, recursive resolver cache miss, authoritative DNS server, forged replies racing the legitimate response, poisoned DNS record, redirected users, and defenses including DNSSEC
DNS spoofing creates the forged information; cache poisoning stores it for reuse. Original educational infographic by Networking Essentials.
Read the diagram from left to right: query → cache miss → response race → false record cached → later users redirected. The defense strip shows where the attack can be blocked or contained.

DNS Cache Poisoning vs DNS Spoofing

DNS spoofing

The attacker creates or sends forged DNS information while pretending it came from a legitimate source. It describes the deception technique.

DNS cache poisoning

A resolver stores false DNS data and reuses it for later queries. It describes the poisoned state and its wider effect.

The terms are often used as if they mean the same thing because a successful DNS spoofing attack can lead directly to cache poisoning. However, the distinction helps when troubleshooting: a forged reply is the input; the false cached record is the lasting result.

DNS hijacking is broader. It may involve changing a device's DNS settings, compromising a router, altering domain records, or taking control of a registrar account. Cache poisoning is one specific DNS attack technique.

How Normal DNS Caching Works

  1. A user asks a recursive DNS resolver for a domain's IP address.
  2. If the answer is not cached, the resolver follows the DNS hierarchy and asks the appropriate authoritative DNS server.
  3. The authoritative server returns the correct DNS record and its time to live (TTL).
  4. The resolver caches that answer for the permitted period.
  5. Later users receive the cached result quickly without a new authoritative lookup.

Caching improves performance and reduces DNS traffic. The danger appears when a malicious DNS response is accepted as genuine and stored. The TTL then determines how long the resolver may reuse that false record unless an administrator flushes it sooner.

How a DNS Cache Poisoning Attack Works

  1. Create a cache miss. The attacker causes the resolver to ask about a name that is not already cached.
  2. Trigger an authoritative query. The recursive resolver sends a DNS request toward the legitimate authoritative server.
  3. Send forged DNS responses. In a classic off-path attack, the attacker tries many replies that claim to answer the resolver's query.
  4. Match the active query. A response generally must match expected details such as the question, transaction ID, source, and destination port.
  5. Win the response race. If a matching forged response is accepted before the legitimate answer, the resolver may store the malicious record.
  6. Redirect later users. Clients asking for the same domain receive the false IP until the TTL expires, the record is replaced, or the cache is cleared.
Important modern context: UDP makes forged packets possible, but using UDP alone does not guarantee a successful attack. Random transaction IDs, randomized source ports, stricter response matching, patched resolver software, and DNSSEC validation make off-path poisoning substantially harder.

Attackers who compromise or administer the resolver may not need to win a race; they can sometimes modify DNS records or cache state directly. That is why access control, server hardening, and monitoring remain essential.

DNS Cache Poisoning Attack Example

StageWhat the user or resolver seesSecurity impact
Before attackbank.example resolves to the legitimate service IP.User reaches the intended server.
Poisoning attemptResolver receives a forged answer claiming bank.example uses a malicious IP.Resolver may accept false data if the response matches and is not validated.
Poisoned cacheThe false DNS record is stored with a TTL.One successful attack can affect many resolver users.
User connectionBrowser is directed toward the malicious IP.Possible phishing, malware, interception, or denial of access.
RecoveryBad entry expires or is flushed; resolver retrieves a correct answer.Correct routing returns, but exposed users may still need investigation.

Proper HTTPS certificate validation can stop or warn about an impersonating website, but HTTPS does not clean a poisoned DNS cache. DNS security and TLS are separate, complementary layers.

Effects of DNS Cache Poisoning

DNS poisoning in cybersecurity is especially serious because successful domain redirection can affect every client using the poisoned resolver.

Phishing and credential theft

Users may see a convincing fake login page even after typing the correct domain name.

Malware delivery

Redirected browsers or applications may contact infrastructure that distributes malicious content.

Man-in-the-middle risk

Traffic may be sent through an attacker-controlled system, although properly validated encryption limits what can be read or altered.

Service disruption

A false IP can point to an unavailable host, preventing users from reaching a legitimate service.

Email or application misrouting

Poisoned record types beyond A or AAAA records can affect other DNS-dependent services.

Broad blast radius

A shared poisoned resolver can return the same bad answer to many clients until remediation.

How to Prevent DNS Cache Poisoning

Validate DNSSEC

A validating resolver checks signatures and rejects forged signed data that fails the chain of trust.

Patch resolver software

Keep DNS implementations current so known poisoning and parsing vulnerabilities are fixed.

Use strong query randomization

Unpredictable transaction IDs and source ports make it harder for an off-path attacker to create a matching forged reply.

Restrict recursive service

Do not expose recursion to unauthorized internet clients. Separate recursive and authoritative roles where practical.

Harden DNS administration

Use least privilege, strong authentication, protected configuration, and change monitoring.

Monitor DNS behavior

Alert on unexpected answer changes, unusual TTLs, DNSSEC failures, or domains resolving to suspicious addresses.

Preserve HTTPS validation

Do not train users to bypass certificate warnings. TLS helps prevent a redirected user from trusting an impersonator.

Prepare cache-flush procedures

Document how to identify, remove, and investigate bad entries without unnecessarily disrupting service.

How DNSSEC Helps Prevent DNS Poisoning

Domain Name System Security Extensions (DNSSEC) let zone operators digitally sign DNS data. A validating recursive resolver checks the signature and chain of trust before accepting the answer. A forged record without a valid signature should fail validation instead of entering the cache.

DNSSEC providesDNSSEC does not provide
Origin authentication for signed DNS data.Encryption or privacy for DNS queries.
Integrity checking for signed records.Protection for unsigned zones beyond normal resolver defenses.
Authenticated denial of existence.Protection from every form of DNS hijacking or compromised administration.

DNSSEC must be correctly deployed by the zone and correctly validated by the resolver. It complements resolver hardening, monitoring, encrypted DNS transport, TLS, endpoint security, and phishing protection.

What to Do If You Suspect a Poisoned DNS Cache

  1. Compare answers from the affected resolver with trusted independent resolvers and authoritative data.
  2. Check DNSSEC validation status, TTL values, resolver logs, recent changes, and the time the bad answer first appeared.
  3. Isolate or stop using a compromised resolver if necessary, then flush the specific bad entry or cache according to the platform's procedure.
  4. Patch and harden the resolver, rotate exposed credentials, and correct unauthorized configuration changes.
  5. Identify affected users and destinations; investigate phishing, malware, credential exposure, and certificate warnings.
  6. Monitor for recurrence and document the root cause before returning the service to normal operation.
A cache flush treats the stored result, not necessarily the cause. If the resolver, router, endpoint settings, or domain account was compromised, the false answer may return until that access is removed.

DNS Cache Poisoning FAQs

What is DNS cache poisoning?

It occurs when false DNS information is stored in a resolver cache. Later queries can receive the wrong IP until the record expires or is removed.

What is DNS spoofing?

DNS spoofing is the creation or delivery of forged DNS information. If a resolver stores it, the result is cache poisoning.

What is DNS cache poisoning vs DNS spoofing?

Spoofing describes the forged response; cache poisoning describes the false information being stored and reused.

How does a DNS cache poisoning attack work?

In the classic off-path version, an attacker sends forged replies and tries to match an active query before the legitimate response arrives.

What are the effects of DNS cache poisoning?

Possible effects include phishing, malware delivery, traffic interception, service outages, and incorrect routing for DNS-dependent applications.

How does DNSSEC help?

DNSSEC allows a validating resolver to verify signed DNS data and reject a forged answer that fails validation.

Does HTTPS prevent DNS poisoning?

No. HTTPS does not protect the DNS cache, but valid certificate checking can block or warn about an impersonating destination.

How can organizations prevent cache poisoning?

Use patched and hardened resolvers, random ports and transaction IDs, DNSSEC validation, restricted recursion, monitoring, secure administration, and tested response procedures.

This is an original explanation developed from the supplied notes. The visual uses a new composition and example data rather than copying the referenced artwork.