DNS poisoning is an attack that corrupts or alters DNS records so users are sent to malicious destinations. The attacker does not need to own the domain, only to manipulate name resolution. This can support phishing, malware delivery, or data theft while the legitimate domain remains technically intact.
Expanded Definition
DNS poisoning is a name-resolution integrity attack, not a domain-ownership attack. The core failure is that a resolver, cache, recursive lookup path, or dependent network component returns the wrong address for a legitimate name, so the user is silently redirected to a destination chosen by the attacker. That can happen through cache corruption, spoofed responses, compromised infrastructure, or weak validation in the resolution chain.
The important boundary is that the domain itself may remain registered and technically intact while trust in the lookup process is broken. That distinction matters because defenders sometimes focus on the visible website and miss the resolution layer that steers traffic before the browser ever connects. In practice, the term is often confused with simple website compromise, but DNS poisoning changes where the user is sent, which is a different control problem entirely.
For readers who want the protocol context, RFC 1034’s definition of the Domain Name System is useful because it clarifies why resolution integrity is central to DNS trust.
Examples and Use Cases
DNS poisoning appears in several operational settings, usually where trust in name resolution is assumed rather than verified:
- A compromised recursive resolver returns a malicious IP for a banking domain, sending users to a phishing site that looks legitimate.
- An on-path attacker injects forged responses into a weakly protected network segment, causing selected users to resolve a software-update hostname to malware hosting.
- A poisoned cache inside an enterprise resolver affects many internal users at once, creating a broad redirection event even though the origin service was never breached.
- A rogue or compromised upstream dependency alters resolution for a third-party domain, which can disrupt SaaS login flows or vendor integrations.
- A misconfigured split-horizon DNS environment returns the wrong internal address, which can look like an attack even when the root cause is operational error.
The tradeoff practitioners face is speed versus assurance: caching improves performance, but every cached answer is also a trust decision that must be protected and validated.
Security Implications
When DNS poisoning succeeds, the first consequence is trust inversion. Users believe they are reaching a legitimate service, but the connection is redirected before application-layer controls can help. That makes phishing, malware delivery, session theft, and credential capture easier because the attacker controls the destination while preserving the appearance of normal navigation.
The blast radius can be larger than a single endpoint. If a shared resolver, ISP path, branch office cache, or enterprise DNS service is affected, many users can be redirected simultaneously. Symptoms often include inconsistent destination IPs, certificate warnings after redirection, unexpected login failures, and access to legitimate services appearing intermittently broken. Those symptoms are especially dangerous because they can be mistaken for ordinary outage noise.
For NHIMG readers, the key practitioner observation is that resolution-layer compromise often precedes visible compromise. By the time users notice a fake page or failed authentication, the attacker may already have captured traffic or harvested credentials through a trusted-looking path.
Domain and Governance Relevance
DNS poisoning sits in the broader cybersecurity domain because it is fundamentally a control and trust integrity problem. It matters wherever an organisation depends on DNS for customer access, employee access, software distribution, or service discovery, because the name-to-address mapping becomes part of the security boundary. If that boundary is weak, the organisation can lose confidence in where users are being sent even when the original service and domain registration remain unchanged.
There is also a material identity and access angle when DNS is used to deliver login portals, federated authentication endpoints, API gateways, or management consoles. In those cases, poisoned resolution can redirect users and systems toward credential capture or malicious intermediaries. The NHI connection is therefore indirect but real: service endpoints, automation clients, and machine-to-machine trust paths can all be steered through DNS, so resolution integrity becomes part of how non-human access is safely reached and validated.
That is why DNS security should be treated as governance over trust routing, not just infrastructure hygiene. The central question is whether the organisation can prove that names resolve to the intended destinations under failure and attack conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1584.008 — Server | DNS poisoning often redirects victims to attacker-controlled infrastructure. |
| Recommendation — Map redirect infrastructure to T1584.008 and investigate malicious hosting tied to poisoned answers. | ||
| CIS Controls v8 | 8.2 — Audit Log Management | Resolver and DNS logs are needed to detect cache poisoning and abnormal resolution. |
| 13.3 — Data Protection | DNSSEC and related protections support integrity of resolution data in transit. | |
| Recommendation — Correlate DNS and resolver logs under 8.2 to spot suspicious answer changes and redirection patterns. Implement 13.3 protections to reduce tampering with DNS answers and related lookup paths. | ||
| NIST CSF 2.0 | PR.DS-6 — Data-at-rest integrity | DNS poisoning is an integrity failure in the data used for name resolution. |
| DE.CM-1 — Monitoring of networks | Detection depends on monitoring resolution behavior and related network telemetry. | |
| Recommendation — Apply PR.DS-6 to protect the integrity of DNS data and trust anchors used in resolution. Use DE.CM-1 to monitor DNS traffic for anomalous responses, spikes, and resolver anomalies. | ||
