How do you detect DNS hijacking?
The directory your device trusts to find websites can be quietly swapped. Here’s how to see which resolver you’re really using — and tell a hijack from your own VPN.
DNS hijacking shows up as one thing: a resolver you didn’t set. Your device uses a DNS resolver to turn a name like your-bank.com into an address. If that resolver changes to a server you didn’t choose — on a network you didn’t reconfigure — your lookups may be going through someone else’s hands. On Windows, ipconfig /all shows exactly which resolver you’re trusting right now.
The directory your device trusts to find websites has been quietly swapped.
A resolver you didn’t choose
A DNS anomaly is an unexpected change to which resolver your device trusts. Because a resolver change is one of the clearer fingerprints of an evil-twin or man-in-the-middle setup, it’s worth knowing your normal resolver so a swap stands out. These are the signs:
- An unfamiliar DNS server in
ipconfig /allthat you or your router didn’t set. - Correctly-typed sites going wrong — the right name, the wrong destination.
- New certificate warnings on sites that were always fine before.
- A resolver that changed when nothing else did — no new network, no VPN toggled.
Checking your resolver — and the false-alarm trap
Reading the resolver is the easy half. The hard half is not crying wolf at yourself: bringing a VPN tunnel up or down legitimately changes your DNS. So the trick is to remember a per-network baseline and flag a resolver change only when it isn’t explained by your own actions — suppressing the change your own VPN causes within a short window around its transitions.
That’s the difference between a detector you trust and one that flags its own protection. A change you caused isn’t an attack; a change you didn’t is exactly the signal — flagged once per unique value, then re-baselined. DNS is also a useful third corroborating signal alongside BSSID and gateway MAC in evil-twin detection.
Keep lookups out of reach
On its own, a DNS-only change is treated as “soft” — worth a warning, not a full alarm, since it isn’t reliable enough to act on alone. The durable fix is to stop trusting the local resolver entirely: route your DNS through an encrypted tunnel, so lookups resolve out of the attacker’s reach even on a hostile network.
Catching it automatically
WifiThreatWatch reads your system resolver, remembers a per-network baseline, and flags a change it didn’t cause as a high-severity DNS anomaly — while suppressing the resolver change its own VPN creates, so it never trips its own detector. Detection is free.
Go deeper: how we detect DNS anomalies · detecting DNS spoofing · the threats library
DNS hijacking: quick answers
How do I know if my DNS has been hijacked?
The clearest sign is your DNS resolver changing to a server you didn’t set, on a network you didn’t reconfigure. On Windows, “ipconfig /all” prints the DNS Servers your device is using; if that address isn’t the one you or your router chose, your name lookups may be going through someone else’s server. Sudden certificate warnings or being sent to the wrong site for a correctly typed address are corroborating signs.
What is DNS hijacking?
DNS hijacking is redirecting the name-resolution your device relies on, so lookups are answered by a server the attacker controls. On a network they control, an attacker can hand out their own DNS server via DHCP or intercept DNS traffic and answer it themselves — quietly sending you to servers they own, even for sites you typed correctly.
How do I check which DNS server I’m using on Windows?
Open Command Prompt and run “ipconfig /all”. Find your active adapter and read the “DNS Servers” line — that’s the resolver your device is currently trusting. Note what it normally is on your own network, so a change on a network you didn’t reconfigure stands out. “nslookup” also shows which server answered a given lookup.
Can a VPN change my DNS?
Yes — legitimately. Bringing a VPN tunnel up or down changes your DNS resolver on purpose, routing lookups through the tunnel. That’s why good detection suppresses the resolver change it causes itself around its own VPN transitions: otherwise the tool would flag its own protection as an attack. A change the software didn’t cause is the one worth flagging.