What is DNS cache poisoning?

DNS cache poisoning occurs when a resolver accepts and stores a forged DNS answer. The false record may point a hostname at an address controlled by an attacker. While that poisoned answer remains cached, users who depend on that resolver may be sent to the wrong destination for a domain.

The impact depends on the domain and the false answer. A poisoned cache can make a site unreachable, direct users to an attacker-controlled host, interfere with email delivery, break certificate validation workflows, or disrupt internal service discovery. It is not only a theoretical DNS problem. It can become a web security, fraud, availability, and incident response problem very quickly.

This article focuses on defensive understanding: how to recognize the risk, how to reduce exposure, and how to respond if DNS answers appear to be wrong. It does not require or provide attack instructions.

See RFC 5452 for the query-matching and response checks used to resist forged DNS answers.

Why cached DNS answers can be risky

Recursive resolvers cache DNS responses so that every lookup does not need to start at the root of the DNS hierarchy. Caching improves speed and reduces load, but it also means that one bad answer can be reused many times until it expires or is cleared.

A resolver normally relies on the structure of DNS responses, query matching, source validation, and other protections to decide whether an answer belongs to a request. If those protections fail, the resolver may store a malicious or incorrect response. Once cached, the bad answer can affect many clients behind the resolver, even though the authoritative DNS zone itself has not changed.

From a user perspective, the symptom may look like a normal site visit. The browser requested the expected domain, but DNS supplied an unexpected address. If the wrong destination can also present a plausible page, redirect users, or interfere with a login journey, the security impact can extend beyond simple downtime.

Indicators defenders should look for

Cache poisoning is not the only explanation for wrong DNS answers. Misconfigured records, expired domains, resolver outages, CDN changes, propagation delays, and local network interception can all create confusing symptoms. Good triage compares evidence from several vantage points before declaring poisoning.

Useful indicators include:

• Affected users receive a different A, AAAA, MX, or CNAME answer than unaffected users.
• The wrong answer appears from one recursive resolver but not from authoritative nameservers.
• The answer has an unexpected TTL, address range, autonomous system, or CNAME target.
• TLS certificates, HTTP redirects, or page content do not match the expected service.
• Email authentication, certificate issuance, or account recovery flows start failing unexpectedly.
• The problem disappears after flushing or bypassing a particular resolver cache.

Authoritative DNS is the reference point. If the authoritative nameserver returns the expected answer but a recursive resolver returns something else, focus on resolver cache state, resolver configuration, local network controls, or interception between client and resolver.

Prevention and hardening

DNSSEC is the strongest widely deployed control for validating that DNS answers have not been altered for signed zones. With DNSSEC, resolvers can verify cryptographic signatures across the DNS chain. It does not encrypt DNS queries, and it does not solve every operational issue, but it can prevent accepting forged answers for properly signed and validated records.

Resolver hardening also matters. Recursive resolvers should be maintained, patched, and configured to reject malformed or unrelated responses. They should use modern source-port and transaction matching behavior, limit cache pollution, and avoid accepting additional record data that is not relevant to the query. Open recursive resolvers should not be exposed to the public internet unless they are intentionally operated as a public service with appropriate abuse controls.

For organizations running their own resolvers, configuration review is important. Limit who can query internal resolvers. Monitor unusual cache entries. Separate internal and external resolution where appropriate. Avoid forwarding chains that no one owns or audits. Keep resolver software current because DNS implementation bugs can become cache integrity problems.

For domain owners, maintain clean authoritative DNS. Use DNSSEC where operationally feasible, monitor delegation records, protect registrar accounts, and keep a reliable inventory of expected answers for important hostnames. Cache poisoning response is harder when the team does not know what the right answer should be.

Operational blast radius

The affected resolver population determines the blast radius. A poisoned enterprise resolver may affect employees, branch offices, or internal services. A poisoned ISP resolver may affect customers in a region. A poisoned local router may affect a single office or household. A poisoned public resolver would have broader implications, though large public resolvers usually have strong controls and monitoring.

The record type also changes the impact. A poisoned A or AAAA record can redirect web traffic. A poisoned MX record can affect mail routing. A poisoned CNAME can send users through an unexpected chain. A poisoned TXT record can affect validation for email authentication, certificate issuance, or service ownership checks.

TTL affects how long a bad answer can persist, but it is not the whole story. Some resolvers apply minimum or maximum cache values, and some clients maintain their own caches. Incident plans should assume that cleanup can take longer than simply fixing an authoritative record.

Response steps for suspected poisoning

Start by preserving evidence. Capture the exact hostname, record type, resolver used, returned answer, TTL, timestamp, source network, and command output. Compare results from the authoritative nameserver, the organization's resolver, a trusted external resolver, and affected client networks.

Then isolate scope. Determine whether the issue is tied to one resolver, one network, one geography, one device class, or one domain. Check whether DNSSEC validation is enabled and whether validation failures are being reported. Review recent DNS changes, registrar activity, delegation updates, resolver configuration changes, and network security events.

If the bad answer is confirmed in a resolver cache, flush or restart the affected cache according to the resolver's documented procedure. If an upstream forwarder is supplying the bad answer, bypass it or escalate to the operator. For high-risk domains, notify security, support, and communications teams so they can watch for account compromise reports, phishing reports, certificate anomalies, and traffic shifts.

Do not rely only on DNS correction. Verify the web or mail path after cleanup. Confirm TLS certificates, redirects, content, email delivery, and security logs. If users may have submitted credentials or sensitive data to a wrong destination, treat the event as a potential account security incident and follow the organization's incident response process.

Rollout checks for safer DNS operations

Before changing critical DNS records, document the expected answers, TTLs, authoritative nameservers, and rollback values. After changes, query from multiple networks and resolvers. Keep monitoring that can distinguish authoritative DNS health, recursive resolver behavior, and application availability.

For critical zones, periodically test DNSSEC validation, resolver configuration, registrar security, and alert coverage. DNS cache poisoning is best handled before an incident: reduce the chance of accepting bad answers, know what good answers look like, and make resolver-level evidence easy to collect when users report something strange.

Related learning

• What is DNS over TLS (DoT)?
• What is a DNS NS record?
• Common DNS issues and how to diagnose them