What Is DNS Hijacking, and How Can You Detect It?

DNS hijacking is one of the quietest ways to take over someone's traffic. Instead of breaking encryption or compromising a server, the attacker changes where DNS sends people — by altering a device's resolver setting, reconfiguring a home router, tampering with a resolver, or editing a domain's records at its DNS provider. The victim types the right address and lands on the wrong server, often with no visible sign that anything is off. Unlike cache poisoning, which forges answers in flight, hijacking changes the configuration that produces the answers in the first place.

This article breaks down the different kinds of DNS hijacking by where they happen, then focuses on detection: concrete checks you can run on your own devices and network, and the monitoring a domain owner should have in place to spot unauthorized changes to their DNS within minutes.

The Four Places DNS Can Be Hijacked

It helps to follow a lookup from your device outward. Each layer it passes through can be tampered with, and each has a different detection method.

1. Local hijacking (the device)

Malware on a computer or phone changes the system's DNS server settings to point at an attacker-run resolver, or adds entries to the hosts file for specific domains like banking or email sites. The resolver then returns attacker IPs for selected domains while answering everything else normally, so browsing seems fine. Some malicious browser extensions achieve the same effect inside the browser by setting a custom DNS over HTTPS provider.

2. Router hijacking (the local network)

Home and small-office routers hand out DNS server addresses to every device via DHCP. If an attacker gets into the router's admin interface — through default passwords, an exposed management port, or an unpatched firmware vulnerability — they can change its DNS setting, and every device on the network inherits the malicious resolver. The DNSChanger malware operation, dismantled by the FBI in 2011, infected millions of computers and routers this way. Router-targeting campaigns have recurred regularly since.

3. Resolver-level hijacking (the ISP or resolver operator)

Here the resolver itself returns answers that don't match the authoritative data. Sometimes it's a compromised resolver; often it's deliberate policy. Some ISPs practice NXDOMAIN redirection — instead of telling you a name doesn't exist, the resolver returns the IP of an ad-filled search page. Governments and networks also use resolver-level redirection for censorship. Not all of this is malicious, but it is still the resolver lying about DNS.

4. Authoritative hijacking (the domain's DNS itself)

This is the most damaging form because it affects every user worldwide, regardless of what resolver they use. The attacker changes the domain's records or nameservers at the source, typically by:

• Compromising the DNS provider account (stolen password, no MFA) and editing A, MX, or NS records.
• Compromising the registrar account and changing the domain's nameservers to attacker-controlled ones — effectively seizing the whole domain. This overlaps with domain hijacking, which focuses on taking ownership of the registration itself.
• Abusing a registrar or registry through social engineering or a breach.

The 2018–2019 "Sea Turtle" and "DNSpionage" campaigns used exactly this approach against government and infrastructure organizations: attackers changed nameserver and record data, obtained valid TLS certificates for the hijacked names, and intercepted email and VPN logins. The activity led CISA to issue Emergency Directive 19-01 in January 2019, ordering US federal agencies to audit their DNS records and enable MFA on DNS accounts.

A close cousin worth knowing about is the dangling record, where a record still points at a cloud resource you no longer own, letting someone else claim it. It isn't hijacking in the strict sense, but the outcome is similar — see dangling DNS records and subdomain takeover.

Detecting Hijacking on Your Device and Network

Check which resolver you're actually using

Start by confirming the DNS servers your device is configured to use, and make sure you recognize them.

# Windows
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object { $_.ServerAddresses } |
  Select-Object InterfaceAlias, ServerAddresses

# macOS
scutil --dns | grep "nameserver\[[0-9]*\]" | sort -u

# Linux with systemd-resolved
resolvectl status | grep -E "Current DNS Server|DNS Servers"

Expected values are your router's LAN address, your ISP's resolvers, or a public resolver you chose deliberately. An unfamiliar public IP is a red flag — look it up with whois to see who operates it.

Find out which resolver is really answering

The configured server isn't always the one doing the work: a router may forward to a different upstream, and some networks transparently intercept port 53. Akamai runs a special name that reports the IP address of the resolver that queried it:

dig whoami.akamai.net A +short

The answer is the egress IP of the resolver that ultimately contacted Akamai's authoritative servers. If you configured 1.1.1.1 and this returns an address belonging to your ISP or an unknown network, your DNS traffic is being redirected somewhere along the way. Running whois on the returned IP shows who owns it.

Test for NXDOMAIN redirection

A properly behaving resolver returns NXDOMAIN for a name that can't exist. A hijacking or ad-injecting resolver returns an IP address instead:

NAME="nonexistent-$(date +%s)-check.example.com"
dig "$NAME" A +noall +comments +answer | grep -E "status:|IN[[:space:]]+A"

This builds a unique, guaranteed-nonexistent name and prints the status line and any A records. status: NXDOMAIN with no records is correct. status: NOERROR with an IP address means your resolver is rewriting failed lookups.

Compare answers with a trusted source

For domains you care about — your bank, your email provider, your own sites — compare your resolver's answer with what the domain's authoritative server says:

DOMAIN="example.com"
echo "Local resolver:"
dig "$DOMAIN" A +short | sort
echo "Authoritative:"
dig @"$(dig "$DOMAIN" NS +short | head -n 1)" "$DOMAIN" A +norecurse +short | sort

The first query goes through whatever resolver your device uses; the second asks the domain's own nameserver directly. Large CDNs can legitimately return different IPs, so a mismatch isn't proof on its own — but if your resolver returns an IP that belongs to a completely unrelated network, treat it seriously.

Check the router

Log in to your router's admin interface and look at the WAN or DHCP DNS settings. If they've changed from what you set (or from "automatic/ISP"), reset them, change the admin password, disable remote administration, and update the firmware. The guide on changing DNS servers on your router shows where these settings typically live. If you find unexpected DNS settings, a factory reset followed by a firmware update is the safest path, since the attacker may have left other changes.

Use encrypted DNS as a tripwire and a shield

Configuring DNS over HTTPS or DNS over TLS to a resolver you trust, with strict certificate validation, defeats router and network-level hijacking: a malicious resolver can't present a valid certificate for cloudflare-dns.com or dns.google. If strict encrypted DNS suddenly fails on a particular network, that itself tells you something is interfering.

Detecting Hijacking of Your Own Domain

If you own a domain, the threat that matters most is authoritative hijacking, and it's detectable if you watch the right things.

Monitor the delegation at the parent

An attacker who controls your registrar account will change your nameservers. That change is visible at the TLD within minutes. Check it directly against a TLD server so caches can't mislead you:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority | awk '{print $5}' | sort

This prints the nameservers the .com registry currently delegates your domain to. Schedule this, compare against a known-good list, and alert on any difference. For other TLDs, query one of that TLD's own servers.

Monitor critical record values

Changes to A, AAAA, CNAME, MX, and NS records are the payload of an authoritative hijack. This script compares live authoritative answers against a baseline and reports drift; run it from cron or a CI scheduler and route the output to your alerting:

import sys

import dns.resolver

BASELINE = {
    ("example.com", "NS"): {"ns1.example-dns-host.net.", "ns2.example-dns-host.net."},
    ("example.com", "A"): {"203.0.113.10"},
    ("www.example.com", "CNAME"): {"example.com."},
    ("example.com", "MX"): {"10 mail.example.com."},
}

resolver = dns.resolver.Resolver(configure=False)
resolver.nameservers = ["1.1.1.1", "8.8.8.8"]
resolver.cache = None

drift = []
for (name, rtype), expected in BASELINE.items():
    try:
        answer = resolver.resolve(name, rtype)
        actual = {r.to_text() for r in answer}
    except dns.resolver.NXDOMAIN:
        actual = {"NXDOMAIN"}
    except dns.resolver.NoAnswer:
        actual = set()
    if actual != expected:
        drift.append(f"{name} {rtype}: expected {sorted(expected)}, got {sorted(actual)}")

if drift:
    print("DNS DRIFT DETECTED")
    print("\n".join(drift))
    sys.exit(1)
print("All monitored records match baseline")

The script resolves each monitored name and type through public resolvers, compares the full set of values against the baseline, and exits with an error listing every difference. Keep the baseline in version control so legitimate changes update it through review — then any drift is, by definition, unauthorized or a mistake. If you set up broader checks as described in how to monitor DNS uptime and performance, fold this into the same alerting.

Watch Certificate Transparency logs

Attackers who hijack DNS usually want a valid TLS certificate for the hijacked name so victims don't see browser warnings. Every publicly trusted certificate is recorded in Certificate Transparency logs, so you can see certificates issued for your domain. Search on crt.sh from the command line:

curl -s "https://crt.sh/?q=example.com&output=json" \
  | python3 -c 'import json,sys; [print(c["not_before"], c["issuer_name"].split("O=")[-1].split(",")[0], c["name_value"].replace("\n"," ")) for c in json.load(sys.stdin)[:20]]'

This fetches recent certificates for the domain and prints the issue date, issuing organization, and names covered. A certificate from a CA you don't use, or for a hostname you didn't request, deserves immediate investigation. Publishing a CAA record that limits which CAs may issue for your domain narrows the window further.

Lock down the accounts

Detection matters, but prevention at the account level stops most authoritative hijacks before they start:

1. Enable MFA on your registrar and DNS provider accounts, preferably with security keys.
2. Turn on registrar lock and, for high-value domains, registry lock, which requires out-of-band verification for nameserver changes.
3. Limit who has access and use role-based permissions and API tokens scoped to specific zones.
4. Enable change notifications from your provider so every edit generates an email or webhook.
5. Sign the zone with DNSSEC. It won't stop an attacker who controls your registrar account (they can remove the DS record), but it does stop hijacks at the resolver and network layers for validating users.

The wider set of preventive controls is covered in how to secure DNS against attacks.

If You Find Evidence of Hijacking

• On a device: disconnect it from the network, run a reputable malware scan, reset DNS settings to automatic or a trusted resolver, check the hosts file, and change passwords from a clean device.
• On a router: factory reset, update firmware, set a strong admin password, and disable remote management and UPnP if you don't need them.
• On your domain: regain account control (contact the registrar's security team immediately if you're locked out), restore the correct records and nameservers, revoke any certificates issued during the incident, rotate credentials and API tokens, and review audit logs to determine what was changed and when. Assume email sent during the window may have been intercepted.

---

DNS Hijacking FAQ

Conclusion

DNS hijacking works because so much trust rests on a few configuration settings: the resolver address on a device, the DNS setting on a router, the policy of a resolver operator, and the records in a DNS provider account. Change any one of them and traffic quietly flows somewhere else. The local and network-level forms are best countered with good device hygiene, secured routers, and strict encrypted DNS to a trusted resolver, and they're easy to check for with a handful of commands.

For domain owners, the stakes are higher because an authoritative hijack affects everyone. The defenses are well understood — MFA, registrar and registry locks, scoped access, and DNSSEC — and detection is straightforward once you decide to do it: watch your delegation at the TLD, compare your critical records against a baseline, and keep an eye on Certificate Transparency logs. With those in place, an unauthorized change becomes an alert within minutes rather than a discovery weeks later.

These references provide more detail on DNS hijacking and how to defend against it:

1. CISA: Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering — the US government directive issued in response to large-scale DNS hijacking campaigns.
2. Cloudflare Learning Center: What is DNS security? — an overview of DNS threats, including hijacking, and common defenses.
3. RFC 6962: Certificate Transparency — the specification behind the public logs used to spot unauthorized certificates.
4. crt.sh: Certificate Transparency search — a free tool for finding certificates issued for any domain.
5. ICANN: EPP Status Codes — explains lock statuses such as clientTransferProhibited and serverUpdateProhibited.