DNS hijacking is the manipulation of DNS records, resolution paths, or upstream infrastructure so traffic is sent to an unintended destination. It can be used for fraud, malware delivery, or service disruption, and it is especially damaging when it affects domains that users already trust.
Expanded Definition
DNS hijacking is not just a DNS problem; it is an integrity failure in the path that maps a trusted name to a destination. In NHI environments, that path often supports API endpoints, agent callbacks, service discovery, and token exchange flows, so a poisoned lookup can redirect both human and machine traffic. Definitions vary across vendors when the attack occurs at the registrar, recursive resolver, authoritative nameserver, or local endpoint, but the security outcome is the same: an identity or workload is sent to the wrong place. The distinction matters because defenders need to know whether they are protecting zone data, resolver trust, upstream routing, or endpoint configuration. The most useful baseline is to treat DNS as part of the trust boundary, not merely as plumbing, which aligns with the NIST Cybersecurity Framework 2.0 emphasis on resilient communications and asset protection. The most common misapplication is calling any redirect or phishing page a DNS hijack, which occurs when the destination changed without evidence that DNS resolution itself was altered.
Examples and Use Cases
Implementing DNS defenses rigorously often introduces operational friction, requiring organisations to weigh rapid change management against tighter validation, logging, and approval controls.
- A compromised registrar account changes NS records, sending a corporate domain to attacker-controlled infrastructure until the zone is restored.
- A malicious insider edits an authoritative A record so an internal API hostname resolves to a lookalike service that harvests tokens.
- A home router or endpoint modifies resolver settings, causing developer tools to query a rogue DNS server that serves poisoned answers.
- A supply chain attack targets a delegated subdomain used for agent callbacks, disrupting Ultimate Guide to NHIs-style service account workflows and credential exchange paths.
- A recursive resolver is manipulated to return counterfeit records for an automation domain, diverting jobs, webhooks, or secret retrieval traffic.
For teams building identity-aware infrastructure, DNS controls should be reviewed alongside NIST Cybersecurity Framework 2.0 practices for monitoring, recovery, and protective technology, because the attack surface spans both configuration and dependency chains. NHIs outnumber human identities by 25x to 50x in modern enterprises, which means a single poisoned hostname can affect many automated workflows at once, as highlighted in Ultimate Guide to NHIs.
Why It Matters in NHI Security
DNS hijacking is especially dangerous in NHI security because machines trust names repeatedly and automatically. When a service account, API key, certificate, or agent is pointed at the wrong host, the failure can become a credential theft event, a data exfiltration path, or a silent outage that looks like normal automation. This is why DNS integrity belongs in NHI governance, not only in network operations. NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes DNS manipulation a practical route to high-impact compromise, especially when the hijack captures secrets in transit or redirects credential refresh traffic. The control problem is broader than record protection: organisations also need registrar locking, resolver hygiene, zone-change auditing, and validation of endpoint identity before automation proceeds. That is consistent with the risk perspective in the Ultimate Guide to NHIs and the resilience objectives in NIST Cybersecurity Framework 2.0. Organisations typically encounter this consequence only after a domain begins resolving correctly to the wrong place, at which point DNS hijacking 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 hijacking often exposes or redirects NHI secrets and service endpoints. |
| NIST CSF 2.0 | PR.DS | DNS integrity supports secure data flow and protection of communications. |
| NIST Zero Trust (SP 800-207) | Zero trust requires validating the destination before any workload trusts a host. |
Protect NHI dependencies with DNS change controls, zone monitoring, and strict resolver trust.
