How to detect DNS hijacking

DNS hijacking is the attack where the name resolves, the page loads, and everything looks fine, except the IP behind the name belongs to someone else. Users type the correct URL and still land on a phishing clone. There's no error to screenshot, no outage to page on. That's exactly what makes it dangerous, and exactly why detection has to be deliberate.

Hijacking happens at several layers: a compromised registrar account changing your NS records, a poisoned resolver cache, malware rewriting a machine's hosts file, or a home router silently pointed at a rogue DNS server. The detection workflow below catches all four, because they all produce the same observable symptom: DNS answers that don't match your known-good baseline.

Step 1. Baseline your normal DNS responses

You can't spot a wrong answer if you don't know the right one. Record the authoritative answers for the hostnames that matter: apex, www, mail, API.

dig +short example.com A
dig +short example.com NS
dig +short example.com MX
dig +short www.example.com CNAME

Save the output somewhere versioned (a git repo is perfect; you get a change history for free). This is your reference set. Every detection step that follows is a comparison against it.

If you want the same data without a terminal, the DNS Lookup tool returns all record types for a hostname in one query, and this walkthrough covers how to read the output.

Step 2. Cross-check answers from multiple resolvers

A hijack rarely compromises every resolver on the internet at once. Querying the same name through several independent resolvers and comparing answers is the single highest-signal detection test:

dig @8.8.8.8 +short example.com A        # Google
dig @1.1.1.1 +short example.com A        # Cloudflare
dig @9.9.9.9 +short example.com A        # Quad9
dig +short example.com A                  # your local resolver

Interpreting the results:

• All four agree, and match your baseline: healthy.
• Public resolvers agree, your local resolver disagrees: your local resolver (or the router providing it) is the problem. Classic router-level hijack.
• One public resolver disagrees: likely cache poisoning at that resolver, or you're mid-propagation after a legitimate change.
• All four agree, but none match your baseline: the change happened upstream, at the zone or registrar level. Go straight to step 3.

Note the legitimate exceptions: CDN-fronted hostnames and geo-DNS setups return different A records by design. For those, compare the CNAME chain rather than the raw IPs.

Step 3. Verify who actually controls the zone

If the answers changed at the source, check whether the delegation changed. Run a WHOIS lookup on the domain and look at three things:

• Name servers. Do they match the NS records in your baseline? Unexpected nameservers are the strongest hijack indicator there is.
• Updated date. A registrar-level change you didn't make will usually bump this.
• Registrar lock status. clientTransferProhibited should be present. If it's gone and you didn't remove it, treat the account as compromised.

Then validate the suspicious IP itself. A reverse DNS lookup on the answer IP tells you what hostname the IP's owner claims for it; your real server usually has sensible PTR data, while a phishing box often doesn't. IP geolocation adds the where: if your origin lives in us-east-1 and the answer suddenly resolves to a hosting provider on another continent, you have your confirmation.

Step 4. Check for local tampering

If only specific machines see wrong answers, the hijack is local, not in DNS proper. Check the hosts file; it overrides DNS entirely and is a favourite target of malware:

# macOS / Linux
cat /etc/hosts

# Windows (elevated prompt)
type C:\Windows\System32\drivers\etc\hosts

Anything beyond localhost entries that you didn't put there is a finding. While you're on the machine, confirm which resolver it's actually using:

# macOS
scutil --dns | grep nameserver

# Linux (systemd-resolved)
resolvectl status

# Windows
ipconfig /all | findstr "DNS Servers"

If the configured resolver is an IP you don't recognise (especially on a machine that should be getting DNS from DHCP), check the router next. Router-level DNS hijacks (changed WAN DNS settings via default credentials or a CSRF exploit) are among the most common forms of pharming, and they poison every device on the network at once.

Step 5. Validate with DNSSEC

If your zone is DNSSEC-signed, forged answers fail validation. Test it:

dig +dnssec example.com A @8.8.8.8

Look for the ad (authenticated data) flag in the response header. Present means the validating resolver verified the signature chain; absent on a signed zone means validation failed or the resolver doesn't validate. For a full chain-of-trust trace, delv example.com A shows exactly where validation breaks.

DNSSEC won't stop a registrar-account takeover (the attacker can re-sign or strip the DS record), but it shuts down cache poisoning and on-path forgery, and a sudden validation failure is itself a detection signal.

Step 6. Make detection continuous

Everything above is a point-in-time check, and hijacks don't schedule themselves for when you're looking. Two things close the gap:

Query logging. Enable logging on your resolver (querylog yes; in BIND, or your DNS provider's analytics). Spikes of NXDOMAIN responses, queries to lookalike domains, or resolution patterns that shift suddenly are early indicators worth alerting on.

Automated drift detection. A DNS record drift monitor does step 1 and step 2 for you on a schedule: it captures your record set as a baseline, re-resolves every 15 minutes, and alerts with a diff the moment an answer changes. NS, MX, and TXT records almost never change legitimately, so an alert on those is nearly always worth investigating. The drift-monitoring guide covers which record types to watch and how to triage an alert.

What to do when you confirm a hijack

Detection without response is just bad news earlier. In order:

1. Lock the domain at the registrar and rotate registrar credentials (enable MFA if it wasn't already).
2. Revert the records from your baseline; this is where that git-versioned baseline pays for itself.
3. Flush caches on resolvers you control, and expect public resolvers to serve the bad answer until TTL expiry.
4. Audit the blast radius. If MX records were touched, assume mail was intercepted. If the hijacked site presented a login form, force password resets.

TL;DR

1. Record baseline answers for A, NS, MX, and CNAME with dig +short, and keep them in version control.
2. Cross-check the same names against 8.8.8.8, 1.1.1.1, 9.9.9.9, and your local resolver; disagreement localises the hijack.
3. Verify delegation with WHOIS; validate suspect IPs with reverse DNS and geolocation.
4. Check hosts files and configured resolvers on affected machines; check the router.
5. Use dig +dnssec and look for the ad flag on signed zones.
6. Put a drift monitor on the records that should never change.

Related

• How to monitor DNS records for drift: the continuous version of this guide
• How to perform a DNS lookup: reading record types and TTLs
• DNS Lookup tool: on-demand resolution checks