DNS hijacking is a class of attacks where an adversary takes control of how a domain name resolves, redirecting traffic to infrastructure they control. Unlike cache poisoning (which targets resolver caches and is temporary), DNS hijacking typically targets the authoritative side of DNS — registrar accounts, nameserver configurations, or the network paths between resolvers and nameservers. The result is that every user querying the domain, from any resolver, is directed to the attacker's server.
This is one of the most serious DNS attacks because it is comprehensive (affecting all users, not just those using a specific resolver) and can be invisible to the domain owner until significant damage is done.
Types of DNS Hijacking
1. Registrar Account Compromise
The attacker gains access to your domain registrar account — through credential theft, phishing, social engineering of registrar support, or exploiting registrar vulnerabilities — and changes the nameserver delegation to point to servers they control.
Before: example.com NS → ns1.your-provider.com
After: example.com NS → ns1.attacker-controlled.com
Once the NS records are changed at the registrar, all DNS resolution for the domain flows through the attacker's nameservers. They can return any IP address they want for any record.
This is the most complete form of hijacking because it affects the domain's delegation at the TLD level, meaning every resolver in the world will follow the new delegation.
2. Rogue DNS Server
The attacker configures victim devices to use a malicious DNS resolver instead of their normal one. This can happen through:
- Malware that modifies the device's DNS settings
- DHCP hijacking on a local network (the attacker runs a rogue DHCP server that assigns their DNS resolver)
- Router compromise where the attacker changes the router's DNS settings, affecting all devices on the network
The victim's queries go to the attacker's resolver, which returns malicious answers for targeted domains while forwarding other queries normally to avoid detection.
3. Man-in-the-Middle Hijacking
The attacker intercepts DNS traffic between a resolver and upstream servers. Because traditional DNS uses unencrypted UDP, anyone in the network path can observe queries and inject forged responses.
This requires the attacker to have a network position between the resolver and the authoritative server — achievable through ARP spoofing on a local network, compromised network equipment, or ISP-level access.
4. BGP Hijacking of DNS
The attacker uses BGP (Border Gateway Protocol) announcements to claim the IP address ranges of legitimate nameservers. Traffic destined for your nameserver's IP is instead routed to the attacker's infrastructure.
This is a sophisticated attack that operates at the internet routing layer. When the attacker announces your nameserver's IP prefix via BGP, routers across the internet update their routing tables, and DNS queries that should reach your nameserver are instead delivered to the attacker.
Real-World Incidents
Sea Turtle Campaign (2018-2019)
One of the most significant DNS hijacking campaigns targeted government organizations and critical infrastructure in the Middle East and North Africa. The attackers compromised DNS registrars and registry operators directly, modifying NS records to redirect traffic through their infrastructure. They intercepted email and VPN credentials by redirecting MX and VPN-related DNS records. The campaign demonstrated that even organizations with strong internal security could be compromised through their DNS supply chain.
DNSpionage (2018-2019)
A campaign targeting government and private organizations in Lebanon and the UAE. Attackers compromised DNS records to redirect web and email traffic to attacker-controlled servers. They obtained legitimate TLS certificates for the hijacked domains using domain validation, making the interception transparent to users.
Brazilian Bank Heist (2016)
Attackers hijacked the DNS of a major Brazilian bank for approximately five hours by compromising the bank's DNS provider. All web traffic, email, and even ATM DNS resolution was redirected to the attacker's infrastructure, where they served convincing phishing pages and captured credentials.
How Attackers Discover This Weakness
The attacker evaluates potential DNS hijacking vectors by checking:
Registrar security:
- Is two-factor authentication enabled on the registrar account?
- Does the registrar support and enforce domain lock?
- How does the registrar handle support requests (phone-based identity verification is often weak)?
DNS infrastructure:
# Check nameservers and their IPs
dig NS example.com +short
# Check if nameservers have proper security
# (DNSSEC, registry lock, etc.)
dig example.com +dnssec
Network security:
- Are DNS queries encrypted (DoH/DoT)?
- Is the resolver on a secure network, or could traffic be intercepted?
How to Test Your Own Domain
Verify Nameserver Configuration
# Check your current NS records from multiple sources
dig NS example.com @8.8.8.8 +short
dig NS example.com @1.1.1.1 +short
If these return different nameservers, or nameservers you do not recognize, investigate immediately.
Monitor NS Record Changes
Use the Propagation Checker to verify that your NS records are consistent from nameservers worldwide. Set up external monitoring that alerts you if NS records change unexpectedly.
Verify DNSSEC Chain
dig example.com +dnssec +cd
If your domain is DNSSEC-signed and a hijacker changes the nameservers without updating the DS records at the registry, DNSSEC validation will fail — providing an early warning signal.
Check Registrar Security
Log into your registrar account and verify:
- Two-factor authentication is enabled
- Domain lock is active
- Contact email is correct and accessible
- Authorization codes are not exposed
How to Defend Against It
Secure Your Registrar Account
This is the single most important defense against DNS hijacking:
- Enable two-factor authentication — use hardware tokens (FIDO2/WebAuthn) when available, not SMS
- Use a strong, unique password for your registrar account
- Enable domain lock (also called transfer lock or registrar lock) to prevent unauthorized transfers and NS changes
- Keep contact information current so you receive notifications of changes
Enable Registry Lock
For high-value domains, enable Registry Lock (sometimes called Server Lock). This adds a manual verification step at the registry level before any changes can be made to the domain's delegation. Changes require direct contact with the registrar, typically with out-of-band identity verification.
Registry Lock is the strongest protection against registrar-level hijacking because even a compromised registrar account cannot modify the domain without the additional verification step.
Deploy DNSSEC
DNSSEC provides cryptographic verification of DNS responses. If an attacker hijacks your nameservers but does not have your DNSSEC signing keys, validating resolvers will detect the tampered responses and refuse to accept them.
For a full guide on DNSSEC implementation, see What Is DNSSEC and Why Should You Enable It.
Monitor DNS From External Vantage Points
Set up monitoring that queries your domain from multiple geographic locations and alerts on:
- NS record changes
- A/AAAA record changes for critical services
- MX record changes
- DNSSEC validation failures
- TTL changes (hijackers often lower TTLs before an attack)
Use Encrypted DNS Transport
DNS over TLS (DoT) or DNS over HTTPS (DoH) between your resolvers and upstream servers prevents man-in-the-middle hijacking of DNS traffic on the network.
Mitigation Checklist
- Two-factor authentication enabled on registrar account (hardware token preferred)
- Domain lock enabled at the registrar level
- Registry Lock enabled for critical domains
- DNSSEC deployed and DS records registered at the TLD
- External monitoring of NS, A, MX records from multiple locations
- Registrar contact email is valid and monitored
- Resolver-to-upstream traffic encrypted (DoT/DoH)
- DNSSEC validation enabled on all resolvers
- Incident response plan covers DNS hijacking scenarios
Common Misconfigurations
- No two-factor authentication on the registrar account — the number one enabler of registrar-level hijacking
- Domain lock not enabled — allowing NS changes without additional verification
- No external monitoring of NS records — changes go undetected until users report problems
- DNSSEC not deployed — removing the cryptographic safety net that would detect tampering
- Using the same password across the registrar and other services — credential stuffing gives the attacker access
- Not using Registry Lock for critical domains — relying solely on registrar-level security, which may have support-desk bypass vulnerabilities
Ethical Note
DNS hijacking is illegal and constitutes unauthorized access to computer systems. Testing should only be performed against your own domains in controlled environments. To verify your hijacking defenses, simulate NS record changes in a test environment and verify your monitoring detects them. Never attempt to compromise registrar accounts, nameservers, or routing infrastructure that you do not own.
This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Cache Poisoning, Subdomain Takeover.