What is DNS hijacking and how is it different from domain hijacking?

DNS hijacking is an attack that changes how a domain name resolves, so users are sent to an attacker's server, usually by tampering with the resolver a device uses, the router that hands out DNS settings, or the DNS records at the domain's provider. Domain hijacking is different: the attacker takes control of the domain registration itself, typically by transferring it to another registrar or changing the registrant details, which gives them full and lasting ownership of the name. DNS hijacking changes the answers; domain hijacking changes who owns the question.

Both attacks end with visitors reaching the wrong server, which is why they're often confused. But they happen at different layers, need different defences, and have very different recovery paths. In this article you'll learn the main types of DNS hijacking, how domain hijacking works, how to check whether a device or a domain has been tampered with, and the practical steps that protect your users and your domains.

Where Each Attack Happens

A DNS lookup passes through several systems, and each one can be attacked. It helps to map them out:

Layer	Who controls it	Attack	Effect
Device settings	The user or IT department	Local DNS hijacking	One device uses a malicious resolver
Home or office router	The network owner	Router hijacking	Every device on the network is redirected
Recursive resolver	ISP, company or public service	Rogue or compromised resolver	All users of that resolver get altered answers
DNS provider account	The domain owner	Record tampering	Everyone who looks up the domain is redirected
Registrar and registry	The domain owner	Domain hijacking	Ownership and nameservers change

The first four are forms of DNS hijacking. The last is domain hijacking. Record tampering at the DNS provider sits close to the boundary, because the attacker often gets in through the same kind of stolen credentials, but the domain stays registered to the rightful owner.

Types of DNS Hijacking

Local Hijacking

Malware on a device changes its DNS settings to point at a resolver the attacker runs. Every lookup from that device then goes through the attacker, who can return fake answers for banking sites, inject adverts, or simply log browsing activity. Some malware also edits the hosts file, which overrides DNS for specific names.

Router Hijacking

Home and small office routers hand out DNS server addresses to every device through DHCP. If an attacker gets into a router, often through a default password or an unpatched vulnerability in the admin interface, they can change those addresses. Every phone, laptop and smart device on the network then uses a malicious resolver, even though none of them are infected.

Large campaigns have done exactly this, compromising hundreds of thousands of consumer routers to redirect traffic.

Rogue or Compromised Resolvers

A recursive resolver itself can be malicious or compromised. That might be a fake "free DNS" service, a compromised corporate resolver, or an ISP resolver that has been tampered with. Some ISPs have also redirected lookups for non-existent domains to their own search or advertising pages. That's a milder form of hijacking, but it shows how much control the resolver has over what users see.

Record Tampering at the DNS Provider

This is the most damaging form for a business, because it affects everyone who looks up the domain, wherever they are. An attacker who logs in to the DNS provider or registrar account, or who abuses an exposed API token, can change A, MX or NS records directly.

The DNSpionage and Sea Turtle campaigns, documented by security researchers in 2018 and 2019, used this approach against government and infrastructure organisations. The attackers changed DNS records for mail and VPN servers, obtained valid certificates for the redirected names, and intercepted traffic, sometimes for only a short window to avoid detection.

What Is Domain Hijacking?

Domain hijacking means taking control of the domain registration. An attacker who succeeds can:

• Transfer the domain to a registrar account they control.
• Change the registrant contact details, making it harder for you to prove ownership.
• Change the nameservers at the registry, so they control all DNS for the domain.
• Sell or hold the domain for ransom.

Common routes into domain hijacking include:

1. Compromised registrar accounts, through phishing, password reuse or a lack of two-factor authentication.
2. Compromised email. If the registrant email address is taken over, or the email domain has expired, the attacker can reset the registrar password or approve a transfer.
3. Social engineering of registrar support staff into making changes.
4. Expired domains that the owner forgot to renew, which can be registered by anyone once they're released.

Recovery from domain hijacking can take weeks and may involve the registrar, the registry and sometimes legal or ICANN dispute processes. That's why prevention matters so much.

DNS Hijacking vs Domain Hijacking at a Glance

	DNS hijacking	Domain hijacking
What changes	DNS answers or the resolver used	Ownership and control of the registration
Typical target	Devices, routers, resolvers, DNS accounts	Registrar accounts and registrant email
Scope	One device, one network, or all users	Everyone, permanently until reversed
Main defences	Secure devices and routers, DNSSEC, encrypted DNS, account security	Registrar lock, registry lock, two-factor authentication, renewal management
Recovery	Fix settings or records, flush caches	Dispute and transfer back, which can be slow

How to Check a Device for DNS Hijacking

If you suspect a device or network is using a malicious resolver, start by checking which DNS servers it's configured to use.

Linux

resolvectl status | grep -E 'DNS Servers|Current DNS'
cat /etc/resolv.conf

macOS

scutil --dns | grep nameserver | sort -u

Windows

Get-DnsClientServerAddress -AddressFamily IPv4 |
  Where-Object ServerAddresses |
  Select-Object InterfaceAlias, ServerAddresses

Compare the addresses with what you expect: your router, your company's resolvers, or a known public resolver. An unfamiliar IP address, especially one in a foreign network, is a red flag.

Check the Hosts File

grep -vE '^\s*(#|$)' /etc/hosts

On Windows, the file is at C:\Windows\System32\drivers\etc\hosts:

Get-Content C:\Windows\System32\drivers\etc\hosts |
  Where-Object { $_ -notmatch '^\s*(#|$)' }

Entries for banks, email providers or software update sites that you didn't add yourself suggest tampering.

Compare Answers With a Trusted Resolver

Ask your configured resolver and a known public resolver the same question. If they disagree for a major site, investigate further:

dig www.example.com A +short
dig @1.1.1.1 www.example.com A +short

Some differences are normal, because CDNs return different IPs in different places. A real red flag is an answer from your resolver that points to a completely unrelated network, or one that changes for a site that should be signed with DNSSEC.

Check Whether Your Queries Are Being Intercepted

Some networks transparently redirect all traffic on port 53 to their own resolver, even if you've configured a different one. Several public resolvers offer a way to see which resolver actually received your query. For example, Cloudflare publishes a debug name under the CHAOS class:

dig @1.1.1.1 id.server CH TXT +short

"dac05"

A short identifier like this comes from Cloudflare's own servers, so you know your query really reached them. If you get no answer, or something that looks like a different resolver's software or hostname, something in the path may be intercepting your DNS traffic. Encrypted DNS prevents this kind of interception.

How to Protect Devices and Networks

1. Secure routers: Change default admin passwords, disable remote administration, and install firmware updates. Replace routers that no longer receive updates.
2. Lock down DNS settings: On managed devices, enforce resolver settings through group policy or mobile device management, and block outbound DNS to anything except your approved resolvers.
3. Use encrypted DNS: DNS over HTTPS or DNS over TLS to a trusted resolver prevents on-path interception and redirection.
4. Use DNSSEC-validating resolvers: Forged answers for signed zones are rejected.
5. Keep endpoint protection up to date, so malware that changes DNS settings is detected.

How to Protect Your Domains

Secure Registrar and DNS Accounts

• Turn on two-factor authentication, preferably with security keys or an authenticator app rather than SMS.
• Use unique, strong passwords stored in a password manager.
• Limit who has access, and give each person their own login.
• Use scoped API tokens with the minimum permissions needed, and rotate them.
• Make sure the registrant and account email addresses are on a domain you control and that won't expire.

Use Registrar and Registry Locks

A registrar lock sets status codes such as clientTransferProhibited on the domain, which blocks transfers until you remove the lock. Most registrars enable it by default, but check.

A registry lock, offered for many TLDs through some registrars, sets server status codes such as serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited. These can only be removed through a manual, verified process with the registry, so even someone with full access to your registrar account can't change nameservers or transfer the domain quickly. It usually costs extra, and it's well worth it for high-value domains.

You can check a domain's status codes with RDAP:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.status'

[
  "client delete prohibited",
  "client transfer prohibited",
  "client update prohibited"
]

The endpoint above covers .com. For other TLDs, find the right RDAP server in IANA's bootstrap file, or use whois and look for the Domain Status lines.

Sign Your Zone With DNSSEC

DNSSEC doesn't stop someone with access to your DNS account from changing records, because the provider will happily sign the attacker's changes. But it does stop attackers who try to forge answers on the network or through a compromised resolver that doesn't control your zone's keys. It's an important layer against several forms of DNS hijacking.

Add CAA Records

A CAA record lists which certificate authorities may issue certificates for your domain:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

This doesn't stop an attacker who can edit your DNS, because they could change the CAA record too, but it does make mis-issuance through other CAs harder and adds another record worth monitoring.

Monitoring for Hijacking

Because record tampering and domain hijacking can be short-lived, quick detection matters. Watch for:

• Nameserver changes at the registry.
• Changes to critical records such as A, MX and NS.
• New certificates issued for your domain, using Certificate Transparency logs.
• Status code changes, such as a lock being removed.

A simple script run from cron can check the delegation and key records against known values:

#!/usr/bin/env bash
# Alert if the delegation or key records for a domain change.
domain="example.com"
expected_ns="ns1.example.net. ns2.example.net."
expected_mx="10 mx1.mailprovider.example."

actual_ns=$(dig "$domain" NS @a.gtld-servers.net +norecurse +noall +authority |
  awk '{print $5}' | sort | xargs)
actual_mx=$(dig @1.1.1.1 "$domain" MX +short | sort | xargs)

alert=""
[ "$actual_ns" = "$expected_ns" ] || alert+="NS changed: $actual_ns\n"
[ "$actual_mx" = "$expected_mx" ] || alert+="MX changed: $actual_mx\n"

if [ -n "$alert" ]; then
  printf "DNS change detected for %s\n%b" "$domain" "$alert" |
    mail -s "DNS alert: $domain" security@example.com
fi

The NS check asks a .com registry server directly, so it detects changes at the registry level even if your own nameservers are still answering with the old data. For other TLDs, replace a.gtld-servers.net with one of that TLD's nameservers.

For certificates, Certificate Transparency monitoring services and search tools such as crt.sh let you see every publicly logged certificate for your domain. A certificate you didn't request is a strong sign that someone controlled your DNS, even briefly.

What to Do If You've Been Hijacked

If records were changed at your DNS provider:

1. Regain control of the account, reset passwords and revoke API tokens and sessions.
2. Restore the correct records from your latest export.
3. Revoke any certificates issued to the attacker, which you can find through Certificate Transparency logs.
4. Reset credentials that may have been captured while traffic was redirected, such as email or VPN passwords.

If the domain itself was hijacked, contact your registrar immediately with proof of ownership, such as invoices and account history. The registrar can work with the gaining registrar and the registry to reverse an unauthorised transfer. For generic TLDs, ICANN's transfer dispute policies provide a formal route if the registrars can't resolve it between them.

---

FAQ: DNS Hijacking

---

Conclusion

DNS hijacking and domain hijacking both send your users to the wrong place, but they attack different layers. DNS hijacking tampers with the resolution process, from malware on a single laptop to a compromised router or a changed record at your DNS provider. Domain hijacking goes further and takes the registration itself, which makes it slower and harder to recover from.

Protect users by securing devices and routers, using validating resolvers and encrypted DNS. Protect domains by locking down registrar and DNS accounts with two-factor authentication, enabling registrar and registry locks, signing your zone and monitoring nameservers, critical records and certificates. Those layers together make both kinds of hijacking far harder to pull off and much quicker to spot.