How do you detect DNS spoofing?
This one hides where a resolver check can’t see it — in the answer, not the address. Here’s how to catch a tampered lookup.
You detect DNS spoofing by checking the answer, not the resolver. Resolve a name whose correct IP you already know — a stable, well-known address — and compare. If the answer comes back different, your lookups are being tampered with, even when the resolver’s own IP never changed. That’s the whole trick: spoofing rewrites the answer, so a check that only watches for a resolver change never fires.
You typed the name correctly. The answer sent you somewhere else.
The answer, not the resolver
Where a DNS anomaly is a change to which resolver you’re using, DNS spoofing is the resolver you already trust — or something silently intercepting it — handing back the wrong address. On a network they control, an attacker intercepts DNS queries and answers them directly, or runs a transparent proxy that forwards most lookups untouched but rewrites the ones they care about.
The resolver’s IP can look exactly the same as always. That’s what makes it dangerous: everything looks normal, right up until the one lookup that matters is quietly redirected to a server the attacker owns.
Resolve a name you already know the answer to
The practical check is a canary: ask your network’s resolver for a name whose correct IP is fixed and well-known — a stable anycast address that shouldn’t vary from network to network — and compare the answer to the known-good value. On Windows you can spot-check one by hand with nslookup.
If the answer differs from known-good, the lookups are being tampered with. Empty or blocked resolutions — a captive portal, a down link — are never treated as an attack, and a good check pauses during a network’s own reset windows so it doesn’t misread itself.
Resolve out of reach
A tampered answer is a strong signal the network is actively hostile, not just misconfigured. The durable fix is to resolve DNS inside an encrypted tunnel: the same canary that came back wrong on the local network resolves correctly through the tunnel, because whatever was rewriting answers never touches the query.
Catching it automatically
WifiThreatWatch periodically resolves canary names with known-good fixed IPs and flags any tampered answer as DNS spoofing — catching transparent DNS interception even when the resolver’s own IP is unchanged. Detection is free.
Go deeper: how we detect DNS spoofing · detecting DNS hijacking · the threats library
DNS spoofing: quick answers
How do I know if my DNS answers are being spoofed?
Resolve a name whose correct IP you already know — a stable, well-known address — and compare the answer. If it comes back different from the known-good IP, the answers are being tampered with, even if your resolver’s own address looks completely unchanged. That last part is the key: DNS spoofing rewrites the answer, not the resolver, so a check that only watches for a resolver change never fires.
What is the difference between DNS spoofing and DNS hijacking?
DNS hijacking (a DNS anomaly) changes which resolver you’re using — a different server address. DNS spoofing keeps the resolver you already trust, or something silently intercepting it, and hands back the wrong answer. One swaps the directory; the other tampers with what the directory says. Spoofing is stealthier because nothing about your configuration appears to change.
Can DNS spoofing happen even with a normal-looking DNS server?
Yes — that’s what makes it dangerous. On a network they control, an attacker can intercept DNS queries and answer them directly, or run a transparent proxy that forwards most lookups untouched but rewrites the ones they care about. The resolver’s IP can look exactly the same as always, right up until the one lookup that matters is quietly redirected.
How can I protect my DNS lookups on public WiFi?
Resolve DNS through an encrypted tunnel so the lookups leave the local network before anyone can tamper with them. On a hostile network, a canary that came back wrong locally resolves correctly through the tunnel, because the rewriter never touches the query. Encrypted DNS and a trustworthy resolver you control are the durable fix.