How does DNS cache poisoning work?

How a resolver ends up serving the wrong answer

dns cache poisoning is fundamentally a resolver trust problem. The attacker does not need to control the authoritative zone if they can cause the recursive resolver to store a forged reply first, or to accept a reply that appears more credible than the real one. Once cached, that answer can influence many downstream users until it expires or is evicted.

That makes the attack especially effective against shared resolvers, forwarders, and any environment where clients rely on a small number of DNS servers. A poisoned cache can redirect traffic, break service reachability, or quietly support phishing and man-in-the-middle style outcomes by steering users to attacker-controlled infrastructure.

Resolvers are most exposed when they accept unsolicited or poorly validated responses, when query patterns are predictable, or when defensive controls such as DNSSEC validation are absent. For broader DNS hardening, the DNS Security Guide covers the adjacent controls that reduce poisoning risk, including DNSSEC, logging, and defensive filtering.

Why poisoning succeeds in practice

Classic poisoning depends on a race or a trust gap. The attacker tries to get a false answer accepted before the legitimate response arrives, or to exploit a resolver weakness that makes a forged reply look valid. If the resolver cannot strongly bind the response to the original query, the wrong record can be cached as though it were legitimate.

Modern defences raise the cost of that race. Randomising transaction identifiers, source ports, and related resolver behaviour makes spoofed responses harder to guess, while DNSSEC adds cryptographic validation for data that is signed end to end. On the application side, DNS failures can resemble other injection and poisoning patterns, so it is worth comparing the attack path with web cache poisoning and related infrastructure abuse. The Web Application Attacks Guide is useful background when you want to contrast poisoning at the DNS layer with poisoning in HTTP and application caches.

When a resolver is compromised or misconfigured, the issue is not just one bad lookup. The poisoned record can propagate to multiple clients and services, which is why cache poisoning is often treated as a resilience and trust-boundary problem, not just a single lookup anomaly.

What defenders should verify and monitor

The first question is whether the resolver path is actually protected. That means checking whether the environment validates DNSSEC where available, whether resolver software is current, and whether caches are being monitored for unexpected record changes, suspicious TTLs, or sudden shifts in destination IPs. A poisoned answer often looks normal in isolation, but it stands out when compared against expected record history and authoritative data.

It also helps to treat DNS configuration as part of a wider access and control surface. In environments with GitOps or CI/CD managed infrastructure, poisoned or stale DNS data can be amplified by deployment mistakes, cache poisoning, or secret leakage elsewhere in the toolchain. The GitHub and GitHub Actions Security Guide is relevant when DNS records, infrastructure files, or deployment workflows are managed through automation that could spread bad configuration quickly.

Operationally, defenders should watch for anomalous authoritative lookups, repeated cache misses followed by abrupt cache fills, and any mismatch between expected and observed resolution paths. If a critical domain resolves to a new address without a planned change, assume a trust problem until proven otherwise.

Risk and Threat Considerations

DNS cache poisoning is risky because it turns the resolver into a distribution point for deception. A single successful poison can affect many users and services, and the impact can persist until the bad record ages out or the cache is cleared.

Failure mechanism: The attacker forges or wins a race for a DNS response, then relies on weak validation, predictable query behaviour, or absent DNSSEC support so the resolver stores the false answer.

Impact: Traffic can be redirected to attacker-controlled hosts, legitimate services can become unreachable, and downstream users may be exposed to phishing, credential capture, malware delivery, or interception of sensitive sessions.

Practitioner Guidance

What to prioritise: Protect the resolver path first, not just the zone. If you only harden authoritative DNS while leaving recursive resolvers weak, the poisoning risk remains at the point where most users actually consume DNS data.

What to verify: Confirm that your resolvers validate DNSSEC where the domain supports it, that cache lifetimes are sensible, and that abnormal record changes trigger review. In incident response, compare current answers with authoritative lookups before trusting local cache state.

What good looks like: Good DNS hygiene means the organisation can explain why a resolver accepted a record, detect when the answer changed unexpectedly, and quickly flush or replace poisoned data without guessing which service was first affected.

Practitioner takeaway: Cache poisoning is best treated as a resolver integrity problem, because once the cache is trusted, the attacker does not need to keep exploiting the path, only preserve the bad answer long enough to matter.

Related resources from NHI Mgmt Group

• Why does DNSSEC reduce the risk of spoofing and cache poisoning in real-world DNS environments?
• Why do DNS hijacking and cache poisoning create such high risk for login and mail flows?
• How does DNS Cache Eviction work?
• DNS cache poisoning