DNS cache poisoning

Expanded Definition

DNS cache poisoning is a cache integrity attack that causes a resolver to store forged name-to-address mappings, so later requests are redirected without the client seeing an obvious warning. In NHI environments, the impact is broader than website redirection because service-to-service calls, API endpoints, and automation jobs may trust DNS as part of their control path.

Definitions vary across vendors on whether the term should include spoofed responses, resolver compromise, or downstream poisoning through malicious delegation, but the core issue is consistent: a trusted lookup result is replaced before it expires. The operational concern is not just a wrong address, but the false confidence created by a cached answer that looks legitimate to applications and agents. For governance context, the NIST Cybersecurity Framework 2.0 treats resilient name resolution as part of broader protective and detective controls, even if it does not use this exact attack label. The most common misapplication is treating it as only a web browsing issue, which occurs when teams overlook internal resolvers used by NHIs, agents, and CI/CD workloads.

Examples and Use Cases

Implementing DNS controls rigorously often introduces latency, monitoring overhead, and operational tuning, requiring organisations to weigh stronger validation against the cost of more complex resolver management.

• A service account in a deployment pipeline resolves an internal package repository to an attacker-controlled host after a forged cache entry is accepted.
• An AI agent with tool access reaches a fake API endpoint because its resolver returns a poisoned address for a dependency or webhook target.
• A cloud workload continues using a malicious IP after the original spoofing event, because the poisoned answer remains cached until TTL expiration.
• A red-team exercise shows that insecure recursive resolvers can reroute internal service traffic even when application-layer authentication is still intact.
• Operational teams validate resolver behavior against guidance in Ultimate Guide to NHIs while comparing DNS hardening practices to the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

DNS cache poisoning matters in NHI security because non-human identities often authenticate to the right endpoint only after DNS has already been trusted. When the resolver is manipulated, secrets, tokens, certificates, and machine-to-machine sessions may be handed to the wrong destination before access controls can help. That makes DNS integrity a prerequisite for safe automation, not just a network hygiene issue.

The risk is amplified by the scale of NHI exposure. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 92% of organisations expose NHIs to third parties, widening the blast radius when resolution is subverted. DNS failures are especially dangerous in environments that rely on ephemeral workloads and external dependencies, where a poisoned lookup can persist long enough to intercept secrets or alter automation outcomes. For deeper NHI governance context, the Ultimate Guide to NHIs is the relevant reference point. Organisations typically encounter this consequence only after a service starts sending credentials to an unexpected host, at which point DNS cache poisoning becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What should operations teams document for DNS cache handling?
• How should security teams distinguish DNS cache problems from identity access failures?
• When should teams clear DNS cache during incident response?
• DNS Cache Refresh