Domain hijacking takes control of the registrar account or ownership record, which lets an attacker transfer the domain, change registrant details, or lock out the owner. DNS poisoning alters name resolution records so users are sent to malicious servers while ownership of the domain itself remains unchanged. Both are dangerous, but the control point is different.
Why the Difference Matters for Incident Response and Trust Boundaries
domain hijacking and DNS poisoning are often discussed together because both can divert traffic, but they fail at different trust points and therefore demand different response priorities. Domain hijacking is an ownership and registrar-control problem, while DNS poisoning is an integrity problem in name resolution. For teams, the practical difference is whether they must restore authoritative control of the domain itself or invalidate a compromised resolution path. That distinction affects evidence collection, stakeholder communication, and recovery sequencing.
For a useful control baseline, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because both scenarios depend on access control, change control, and monitoring over authoritative records. In practice, many security teams only discover the operational difference after users are already being redirected or the registrar record has already been altered.
How the Attack Surface Changes Between Registrar Control and Name Resolution
Domain hijacking targets the administrative layer that proves who controls the domain. If an attacker gets into the registrar account, abuses weak recovery processes, or exploits poor ownership governance, they can change nameservers, transfer the domain, or rewrite contact and lock settings. The attack is durable because it compromises the source of authority rather than only the traffic path. Recovery usually requires the registrar, registry, and sometimes legal or identity verification steps, which makes speed and evidence preservation important.
DNS poisoning targets the lookup process that converts a domain name into an IP address. The domain owner may still control the registrar, but users can be misled if a resolver cache, recursive infrastructure, or local network trust path is polluted with false records. That makes the attack more situational and often more time-bounded than hijacking, but it can still redirect traffic, harvest credentials, or stage malware delivery. The practical impact is that a domain can appear normal while some users resolve it incorrectly.
- Hijacking changes who can administer the domain.
- Poisoning changes where clients are sent when they look up the domain.
- Hijacking often persists until ownership is restored.
- Poisoning often persists until bad cached or trusted records expire or are flushed.
Where this guidance breaks down is in blended incidents, such as when compromised registrar access is used to alter DNS records after the domain itself is taken over.
Common Variations That Blur the Line
Tighter control over domain ownership and DNS records often reduces exposure, but it also increases administrative overhead, requiring organisations to balance resilience against operational friction.
One common source of confusion is that some incidents begin as DNS manipulation and end as effective domain takeover from the user’s perspective. For example, if an attacker changes authoritative nameservers through registrar access, the event is still domain hijacking even though the visible symptom is poisoned or redirected resolution. Another edge case is split-horizon or multi-provider DNS, where only a subset of users receives malicious answers. That is still a resolution integrity problem, but it can be mistaken for a broader takeover because the user impact may look identical.
The industry does not fully agree on whether every resolver-cache attack should be called poisoning, but the operational distinction is still useful: if the authority record is intact, treat it as a name-resolution compromise; if the registrar or ownership record is altered, treat it as a domain-control compromise. In practice, defenders should not rely on the label alone. They should verify which control plane changed first, because that determines whether to focus on DNS cleanup, registrar recovery, or both.
Risk and Threat Considerations
Both conditions create high trust-exploitation risk because they let an attacker impersonate a legitimate destination without necessarily breaking the domain itself. The risk is especially acute when users, certificate workflows, or application integrations assume that a familiar domain name still points to a trusted endpoint.
Failure mechanism: Domain hijacking usually succeeds through registrar credential compromise, account recovery abuse, or weak ownership controls; DNS poisoning succeeds when an attacker can corrupt resolution data in a resolver, cache, or trust path. In both cases, the defender’s control assumptions are bypassed rather than noisily broken.
Impact: Users can be redirected to credential-harvesting pages, malware delivery infrastructure, or false application endpoints, while the legitimate owner may lose mail flow, web traffic, or the ability to prove authoritative control quickly enough to contain the event.
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 | T1583 — Acquire Infrastructure | Attackers may acquire or repurpose infrastructure for redirection or impersonation. |
| Recommendation — Map hostile infrastructure changes to T1583 and monitor for takeover or staging indicators. | ||
| CIS Controls v8 | 5 — Account Management | Registrar and DNS administration depend on tightly governed privileged accounts. |
| 6 — Access Control Management | Prevent unauthorized changes to domain ownership and DNS delegation. | |
| 8 — Audit Log Management | Detection depends on logging changes to registrars, delegation, and authoritative records. | |
| Recommendation — Enforce account hygiene and restrict registrar and DNS admin access to approved operators. Apply access restrictions to registrar and DNS change paths and review them regularly. Log registrar and DNS changes so you can detect and investigate unauthorized edits quickly. | ||
| NIST CSF 2.0 | PR.AC-4 — Access permissions and authorizations are managed | Both attacks exploit weak control over who can change authoritative records. |
| DE.CM-1 — The network is monitored to detect potential events | Detection requires monitoring for unexpected DNS and registrar changes. | |
| RS.AN-1 — Notifications from detection systems are investigated | Confirmed redirection events require rapid investigation and triage. | |
| Recommendation — Manage permissions so only authorized staff can alter registrar and DNS authority records. Monitor delegation and resolution changes to catch unauthorized redirection early. Investigate abnormal DNS or registrar alerts as a potential domain integrity incident. | ||
Practitioner Guidance
What to verify: First confirm whether the registrar record, nameserver delegation, and authoritative DNS zone are all consistent with expected ownership. If only resolution is wrong, focus on recursive caches, resolver trust paths, and authoritative record integrity; if ownership changed, treat the incident as a registrar-control emergency.
What practitioners underestimate: The recovery path is different enough that misclassification slows containment. Teams often waste time flushing DNS when the real issue is registrar compromise, or they escalate ownership recovery when the real issue is a poisoned resolver path affecting only a subset of users.
Practitioner takeaway: The label matters less than the control plane that failed first, because that is what determines whether you are repairing name resolution or restoring authoritative ownership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
