DNS Hijacking - How Domains Get Taken Over and How to Prevent It
Learn how DNS hijacking works at the registrar, nameserver, account, and resolver layers, plus the controls that prevent domain takeover.
TL;DR
DNS hijacking is unauthorized control over where a domain resolves. The attacker usually does not need to compromise your web server; they change registrar delegation, nameserver data, DNS-provider account settings, or resolver answers. The highest-leverage controls are registrar lock, MFA on registrar and DNS-provider accounts, least-privilege API keys, DNSSEC, CAA records, monitoring for NS/DS/MX changes, and an incident runbook that can restore delegation quickly.
What you'll learn
- Understand the main DNS hijacking paths
- Harden registrar, DNS-provider, and API access
- Use DNSSEC and monitoring to reduce impact
- Prepare a recovery runbook for unauthorized delegation changes
DNS hijacking is what happens when an attacker gains unauthorized control over where your domain resolves. They may never touch your application servers. If they can change your nameservers, records, or resolver path, they can redirect web traffic, intercept email, break certificate issuance, or make your domain disappear.
This guide focuses on authoritative DNS and domain-management risk: the controls that stop hijacking, the monitoring that detects it, and the runbook that gets you back in control.
Where DNS Hijacking Happens
| Layer | Attack | Impact |
|---|---|---|
| Registrar | Attacker changes NS records or transfers the domain | Full domain takeover |
| Registry/DS | Attacker removes or changes DS records | DNSSEC validation gap or outage |
| DNS provider | Attacker changes zone records | Web/email/API redirection |
| API/IaC | Leaked token applies malicious DNS changes | Fast automated takeover |
| Resolver/network | User receives forged answers | Local or ISP-scale redirection |
The registrar layer is the most dangerous because it controls delegation. If the registrar points your domain at attacker-controlled nameservers, your DNS provider can still serve the correct zone and users will not query it.
Common Hijacking Paths
Registrar Account Compromise
The attacker logs in to the registrar and changes nameservers, disables DNSSEC, or transfers the domain. This is often caused by reused passwords, weak MFA, mailbox compromise, or social engineering.
Controls:
- Hardware security key MFA
- Registrar lock or registry lock
- Separate registrar admin accounts from daily email accounts
- Out-of-band approval for NS, DS, and transfer changes
- Monitoring of parent-zone NS and DS records
DNS Provider Account Compromise
The attacker changes records inside the authoritative zone: A, AAAA, CNAME, MX, TXT, or CAA.
Controls:
- MFA for all DNS users
- Role-based access by zone
- Zone-scoped API keys
- Audit logs and change alerts
- Separate production and test zones
Leaked Automation Credentials
Infrastructure-as-code and CI/CD pipelines often have DNS API tokens. A leaked token can change records faster than a human attacker.
Controls:
- Zone-scoped tokens
- Short-lived credentials where possible
- CI secret scanning
- Separate read-only and write tokens
- Approval gates for production DNS changes
Resolver or Network Manipulation
Attackers can try to alter answers between users and resolvers, especially on hostile networks. DNSSEC validation is the primary defense here.
Controls:
- DNSSEC
- Valid DS records at the registrar
- Monitoring for validation failures
- HTTPS/HSTS at the application layer
Hardening Checklist
- Enable registrar lock or registry lock.
- Require phishing-resistant MFA on registrar and DNS-provider accounts.
- Limit DNS-provider users to the zones they need.
- Use zone-scoped API keys for automation.
- Enable DNSSEC and keep DS records correct.
- Publish CAA records to constrain certificate issuance.
- Monitor NS, DS, SOA, MX, CAA, A, and AAAA answers externally.
- Alert on DS removal and NS changes at the parent zone.
- Keep a documented recovery contact at the registrar.
- Test your recovery runbook before an incident.
Detection Queries
Check parent delegation:
dig NS example.com +trace
dig DS example.com +traceCheck authoritative data:
dig @ns1.dnscale.eu example.com SOA
dig @ns1.dnscale.eu www.example.com A
dig @ns1.dnscale.eu example.com MXCompare public resolvers:
dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 www.example.com A +short
dig @9.9.9.9 www.example.com A +shortIf the parent zone points at unexpected nameservers, treat it as a registrar/delegation incident. If parent delegation is correct but authoritative answers changed, treat it as a DNS-provider or automation incident.
Incident Response Runbook
- Confirm the current parent NS and DS records.
- Freeze domain changes at the registrar.
- Restore correct nameservers and DS records.
- Revoke suspicious registrar sessions and rotate credentials.
- Revoke DNS-provider API tokens and user sessions.
- Restore the expected zone from version control or backup.
- Check MX and TXT records for email interception.
- Check CAA records and certificate transparency logs.
- Preserve audit logs before cleanup.
- Publish customer guidance if traffic or email was exposed.
Related Guides
Frequently asked questions
- Is DNS hijacking the same as cache poisoning?
- No. DNS hijacking is broader: unauthorized control over DNS resolution at the registrar, provider, account, or resolver layer. Cache poisoning is one technical method that corrupts recursive resolver answers. Registrar compromise and provider-account compromise are more common hijacking paths for managed domains.
- What is the most important DNS hijacking control?
- Registrar lock plus strong registrar account security. If an attacker can change your NS records at the registrar, they can move the whole domain away from your authoritative DNS provider. Use registrar lock, hardware-key MFA, restricted account access, and out-of-band approval for delegation changes.
- Does DNSSEC prevent DNS hijacking?
- DNSSEC prevents forged DNS answers when the chain of trust remains intact. It does not stop an attacker who controls your registrar account from changing NS and DS records. DNSSEC is necessary, but it must be paired with registrar controls and monitoring.
- How do I detect DNS hijacking quickly?
- Monitor NS, DS, SOA, MX, A/AAAA, and CAA records from multiple external resolvers. Alert on registrar delegation changes, DS removal, unexpected MX changes, and authoritative answers that differ from your expected zone state.
- What should I do first during a hijack?
- Freeze changes at the registrar, restore the correct NS and DS records, rotate compromised credentials/API keys, lower TTLs only after control is restored if needed, and notify affected customers or users based on impact. Preserve logs before making broad cleanup changes.
Related guides
What is DNSSEC? A Plain-Language Guide to DNS Security
DNSSEC explained from first principles ā what it is, why it exists, how it works at a high level, and when you should turn it on for your domain.
How DNSSEC Works ā KSK, ZSK, DS, DNSKEY, RRSIG, NSEC Explained
A walkthrough of the DNSSEC chain of trust: how KSK and ZSK signing keys, DS records, DNSKEY records, RRSIG signatures, and NSEC/NSEC3 work together to authenticate DNS answers.
DNSSEC Setup Guide for DNScale ā Step-by-Step Walkthrough
Enable DNSSEC on a DNScale zone in under 10 minutes ā generate keys, copy the DS to your registrar, verify, and avoid the most common rollover mistakes.
DNS over HTTPS (DoH) Explained ā Encrypted DNS for Resolver-Client Privacy
DNS over HTTPS explained ā what RFC 8484 actually does, how it differs from plain DNS and DoT, browser/OS support, deployment patterns, and where DoH ends and DNSSEC begins.
Ready to manage your DNS with confidence?
DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.
Start free