DNS hijacking: how it works and how to detect it

DNS hijacking means an attacker makes the DNS for your domain answer with values they control, so that visitors, API clients, or email end up on infrastructure that isn't yours. The attack can happen at three levels: your registrar account, your DNS zone, or the resolver used by the victim. The first two change public DNS records, which means anyone watching those records from the outside can spot the hijack. The third leaves your domain untouched and is invisible to external monitoring. This article walks through each level, the signal it leaves, and the checks that catch it.

The three levels of DNS hijacking

Each level attacks a different link in the resolution chain, and each one leaves a different trace.

Compromised registrar account

The attacker takes over your registrar account, usually through a phished password or a hijacked email inbox, and replaces the domain's nameservers with servers they run. From that point they answer every DNS query for the domain and can point web and mail traffic anywhere.

The signal is public: the NS records of the domain no longer match your DNS provider. The Sea Turtle campaign of 2018 and 2019 worked exactly this way, compromising registrars and DNS providers to swap nameservers on government and telecom domains, then harvesting credentials on fake login pages. Watching NS records is the single most valuable check here; the guide on monitoring nameserver changes covers it in depth.

Compromised DNS zone

Here the attacker gets into your DNS provider account rather than your registrar. The nameservers stay the same, so the domain looks normal at first glance, but individual records change: an A record pointed at the attacker's server, an MX record rerouting your inbound mail, a CNAME swapped on a subdomain.

The signal is subtler but still public. NS records are intact while A, AAAA, MX, CNAME, or TXT records differ from what you configured. Anyone comparing today's records against yesterday's sees the edit.

Compromised resolver or router

Malware on a laptop or a hacked home router can rewrite DNS answers for whoever sits behind it. Your registrar account, your zone, and your public records are all untouched. Only the victims behind that resolver get wrong answers.

No external monitoring can see this level, and any vendor claiming otherwise is overselling. The defenses live on the client side: a trusted public resolver, DNS over HTTPS, and clean router firmware.

Attack level	What changes	Visible from outside?
Registrar account	NS records	Yes
DNS zone	A, AAAA, MX, CNAME, TXT	Yes
Resolver or router	Nothing on the domain	No

DNS hijacking, DNS spoofing, domain hijacking: not the same thing

The three terms get mixed up constantly, and the defenses differ.

• DNS spoofing (or cache poisoning) tricks a resolver into caching forged answers. Your domain and its records are never touched. DNSSEC is the defense, because signed answers fail validation when forged.
• Domain hijacking is the theft of the domain itself, typically through a fraudulent transfer to another registrar. The defense is a transfer lock; the article on domain status codes explains clientTransferProhibited and its siblings.
• DNS hijacking, the subject here, changes what your domain's DNS answers while you still own the domain.

How to detect a hijack

Ranked from most to least reliable, the signals are:

• A record changes that you didn't make. This is the core signal for the two externally visible levels. Detection works by snapshot and diff: record what the domain answers today, compare tomorrow, alert on any difference. Domain Sentinel runs this check once a day on every watchlist domain, covering A, AAAA, MX, TXT, NS, and CAA at the apex plus A, AAAA, CNAME, MX, and TXT on www and on the extra names you add, and emails you when anything differs. It also snapshots the RDAP registration data in parallel, so a nameserver swap at the registrar shows up on the next daily check.
• NS records that no longer match your DNS provider. Even without history, you know which provider you pay.
• A TLS certificate you never requested. Attackers often obtain a certificate for the hijacked domain, and Certificate Transparency logs record every issuance publicly.
• User reports of redirects, certificate warnings, or missing email. The worst signal, because damage is already done by the time it arrives.

For an immediate check, ask two independent resolvers and compare:

dig @1.1.1.1 example.com NS +short
dig @8.8.8.8 example.com NS +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

Matching answers that also match your own configuration are a good sign. You can run the same check without a terminal using the DNS lookup tool.

How to protect yourself

In order of effectiveness:

1. MFA and a registrar lock on the registrar account. This blocks the nameserver swap and the fraudulent transfer at the source.
2. MFA on the DNS provider account, which closes the zone-level path.
3. DNSSEC, so that forged answers fail validation on resolvers that check signatures.
4. External record monitoring. Be clear about what it does: it cannot block an attack, but it shrinks the time to detection from weeks, the typical delay when hijacks are found through user complaints, to at most a day with a daily check. DNS monitoring exists for exactly this.
5. Reasonable TTLs, so that a fixed record propagates quickly once you recover control.

Start with what takes five minutes: look up the NS and A records of your main domain with the DNS lookup tool and confirm they match what you configured. Then check that your registrar lock is active, and put the domains you can't afford to lose under daily monitoring. The broader practice of watching DNS records over time is covered in the guide on what DNS monitoring is.