A technique that inserts forged DNS records into a resolver cache so future lookups return the wrong IP address. The attack works because clients often trust cached answers, making the malicious destination appear legitimate until the cache is flushed or corrected.
How DNS cache poisoning works
DNS cache poisoning inserts forged records into a recursive resolver’s cache so later lookups can be redirected without changing the client or the destination service. The attack succeeds because a poisoned cache can make an illegitimate address look authoritative until the bad entry expires, is evicted, or is corrected.
What makes this technique dangerous is that it abuses the normal trust model of DNS. Users and applications often rely on resolver answers as if they were fresh and verified, so a poisoned result can silently affect many connections at once, including web traffic, email routing, software updates, and internal service discovery.
Why DNS cache poisoning is effective
DNS is designed for speed and scale, which is why resolvers cache answers. That efficiency creates a trust boundary: once a record is cached, later requests may never reach the authoritative server during the cache lifetime. An attacker who can inject a forged response, race a legitimate one, or exploit weak validation can therefore influence many subsequent lookups with one successful event.
The technique is especially effective when the resolver or surrounding network path allows spoofed replies, when DNS transaction entropy is weak, or when upstream trust is extended too broadly. It is not only a redirection problem, it is a naming integrity problem, because the victim keeps asking for the right name while being sent to the wrong place.
Operational impact and blast radius
The immediate consequence is traffic diversion. Users may reach a malicious site, a lookalike login page, or an attacker-controlled service that intercepts credentials, sessions, or content. In other cases the damage is subtler: poisoned DNS can break availability, cause failed connections, or route internal systems to the wrong endpoint.
The blast radius depends on resolver scope. A poisoned cache on a shared enterprise resolver can affect many users and workloads at once, while poisoning a local resolver or stub resolver may still be enough to undermine a single host, application, or automation pipeline. Because DNS touches so many dependencies, the same technique can become both an access problem and a resilience problem.
How organisations detect and recover from poisoning
Detection usually starts with comparing resolver answers against expected authoritative records and checking whether the wrong destination is appearing consistently across clients. Resolver logs, packet captures, and DNS telemetry can help confirm whether the bad answer entered the cache, how long it persisted, and whether the same pattern affected multiple names or subdomains.
Recovery is usually a mix of cache flush, resolver restart if needed, and validation of the authoritative zone and recursive path. Organisations should also review whether the incident exposed credentials or redirected users to a malicious endpoint, because DNS poisoning often creates secondary compromise rather than stopping at the name resolution layer.
Risk and Threat Considerations
DNS cache poisoning is dangerous because it turns a single forged reply into a trusted, repeatable redirection path. That can support credential theft, session hijacking, malware delivery, or internal service disruption, especially when the poisoned resolver serves many users or applications.
Failure mechanism: An attacker succeeds when the resolver accepts a spoofed or forged answer and then serves that false record from cache before the legitimate response, correction, or expiry restores the right mapping.
Impact: Users and services are sent to the wrong IP address, which can expose secrets, break availability, or create a durable man-in-the-middle condition until the cache is cleared or overwritten.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-20 — Secure Name / Address Resolution Service (Authoritative Source) | DNS cache poisoning directly targets name resolution integrity. |
| SI-4 — System Monitoring | Resolver tampering is detected through telemetry, logs, and anomaly review. | |
| CM-6 — Configuration Settings | Resolver hardening and trust-path settings reduce cache poisoning exposure. | |
| Recommendation — Enforce secure name resolution controls and require validated recursive DNS paths for critical lookups. Monitor DNS resolver behavior and alert on unexpected destination changes or cache anomalies. Harden resolver configurations to reduce spoofing opportunities and limit unsafe trust relationships. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Resolver and DNS logs provide evidence for poisoning detection and review. |
| CIS-12 — Network Infrastructure Management | DNS resolvers are network infrastructure that must be hardened against spoofing and abuse. | |
| Recommendation — Centralize DNS logs and review them for forged responses, cache anomalies, and redirect patterns. Harden DNS infrastructure and restrict who can alter resolver behavior or upstream trust paths. | ||
| MITRE ATT&CK | T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay | DNS cache poisoning is a name-resolution poisoning technique used to redirect victims. |
| Recommendation — Map poisoned name-resolution events to T1557.001-style detection and hunt for redirection indicators. | ||
| OWASP ASVS | V12 — Secure Communication | Applications rely on trustworthy name resolution and transport to prevent redirection abuse. |
| Recommendation — Verify that application traffic depends on validated endpoints and resistant transport paths. | ||
Practitioner Guidance
Why practitioners should care: Treat resolver trust as part of your attack surface, not just a plumbing detail. If a poisoned cache can redirect many clients, DNS integrity becomes an enterprise control issue rather than a local networking nuisance.
What to watch for: Investigate unexplained destination changes, mismatches between authoritative and recursive answers, and bursts of cache-related anomalies around high-value names. The most useful operational habit is to correlate name resolution with endpoint and proxy telemetry so redirections are visible quickly.
Practitioner takeaway: Strong DNS hygiene means validating the resolver path, limiting who can influence it, and being able to prove whether a lookup was trustworthy after the fact.
Related resources from NHI Mgmt Group
- Guide: DNS Security Guide
- 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 poisoning work?
- Why does DNS cache poisoning matter for security teams?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org