DNS spoofing is the manipulation of name resolution so a victim is sent to a fake destination instead of the intended service. In identity security, it matters because users may trust the right brand while unknowingly sending credentials or tokens to an attacker-controlled endpoint.
Expanded Definition
DNS spoofing is a name-resolution attack that diverts a request to an attacker-chosen endpoint by corrupting DNS records, responses, or client trust in the resolver path. In NHI security, the danger is not just redirection; it is credential capture, token theft, and API abuse against a lookalike service.
The term is often used loosely, and definitions vary across vendors. Some teams use it to describe cache poisoning at the resolver, while others include local hosts-file tampering, rogue DHCP, or compromised internal DNS infrastructure. No single standard governs this yet, so practitioners should distinguish DNS spoofing from broader phishing or brand impersonation. The operational concern is that identity-aware systems frequently assume the destination is authentic once the name resolves, which makes DNS integrity part of the trust boundary. Guidance from NIST Cybersecurity Framework 2.0 reinforces that identity, infrastructure, and monitoring controls must work together rather than as separate silos. The most common misapplication is treating DNS spoofing as a pure network issue, which occurs when teams ignore how resolver compromise can expose service credentials and session material.
Examples and Use Cases
Implementing DNS defenses rigorously often introduces latency, operational overhead, and change-management friction, requiring organisations to weigh stronger trust validation against simpler legacy connectivity.
- A user reaches a fake login page after a poisoned resolver returns an attacker-controlled IP, and the attacker harvests tokens that later unlock downstream SaaS and IAM integrations.
- An internal service account calls a spoofed API hostname during automation, allowing the adversary to intercept signed requests and pivot into privileged workflows.
- A misconfigured recursive resolver in a branch network serves altered answers, showing why source validation and resolver hardening belong in the same control set as NHI lifecycle management. NHI governance guidance in the Ultimate Guide to NHIs is useful here because service identities often remain valid long after the initial compromise.
- A Zero Trust deployment still fails because endpoint and identity checks are strong, but the application trusts DNS alone to locate its peer; the name resolves correctly-looking to a malicious endpoint. That is why NIST Cybersecurity Framework 2.0 is best applied alongside resolver hardening, not in place of it.
In practice, DNS spoofing is also relevant when agents or automated workloads follow hostnames embedded in configuration, because one compromised resolution event can redirect an entire machine-to-machine transaction chain.
Why It Matters in NHI Security
DNS spoofing becomes especially dangerous in environments where secrets, API keys, and service credentials are reused across many systems. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that makes deceptive name resolution a high-impact path into automation-heavy estates. The Ultimate Guide to NHIs also reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, which increases the chance that a spoofed endpoint will receive reusable credentials.
From a governance perspective, the issue is not merely whether DNS is secure, but whether identity systems verify the destination independently of the name. That includes certificate validation, resolver trust, JIT credential limits, and rapid revocation when compromise is suspected. The strongest programs align this work with NIST Cybersecurity Framework 2.0 for identification, protection, detection, and response. Organisations typically encounter the real cost only after a token replay, API abuse, or failed fraud investigation, at which point DNS spoofing becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | DNS spoofing can expose secrets and service accounts through fake endpoints. |
| NIST CSF 2.0 | PR.AC-5 | Name-resolution attacks undermine trust in remote communications and access paths. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero Trust requires continuous verification rather than trusting DNS outcomes alone. |
Validate destination trust and reduce secret exposure paths that make spoofed DNS high impact.
