How do you detect targeted DNS forgery?
A competent attacker rewrites one domain and leaves the rest alone. Here’s how to catch the single forged answer a fixed-domain canary walks right past.
You detect targeted DNS forgery by resolving each name two ways and comparing. Ask the system resolver — the path an on-path attacker rewrites — and ask DNS-over-HTTPS at a literal IP, which TLS authenticates so a port-53 attacker cannot forge it. A public domain the system resolves to a private address while DoH says it is public is a local redirect with zero benign cause.
Everything loads. Only the one that matters points at a box on your own network.
One domain, not the whole directory
Blanket DNS spoofing tampers broadly — easier to trip over. Targeted DNS forgery is the surgical version: the attacker gets on-path (typically via ARP spoofing) and rewrites the answer for a single high-value domain — a bank, a login, an update server — while forwarding everything else correctly.
That precision is exactly what makes it slip past coarse detection. A canary that spot-checks two or three fixed domains will resolve them cleanly, because the attacker never touched them, and cheerfully report all clear.
A public name that answers private
The tell you are looking for is narrow and unambiguous: a well-known public domain that comes back pointing at a private, LAN-local address — anything in 10.x.x.x, 172.16–31.x.x, or 192.168.x.x. Public services do not live on your home subnet. If your resolver claims one does, something between you and the internet is lying.
You cannot see this by watching the resolver’s own IP, because it never changes — the attacker leaves your DNS settings alone and simply rewrites the reply in flight. You have to inspect the answer itself, and you need a second answer you can trust to compare it against.
Two answers, one you can trust
Run the same lookup through the system resolver and through DNS-over-HTTPS pointed at a literal IP. The first is what the attacker rewrites; the second rides inside TLS, so an on-path attacker sitting on port 53 cannot forge it without breaking a certificate. On Windows you can do both by hand:
# 1) What the SYSTEM resolver says (the path that gets rewritten) Resolve-DnsName login.yourbank.example -Type A # 2) A second opinion over TLS-authenticated DoH (attacker can't forge this) curl.exe -s "https://1.1.1.1/dns-query?name=login.yourbank.example&type=A" -H "accept: application/dns-json" # Query a second provider so no single blackhole silences the check curl.exe -s "https://8.8.8.8/dns-query?name=login.yourbank.example&type=A" -H "accept: application/dns-json"
Compare the addresses. If the system answer is a private 192.168/10/172.16 address and DoH returns a public one, that is targeted forgery — no benign cause. If both are public but simply different, that is ordinary CDN geo-variance and means nothing. A conceptual view of the attacker side makes the asymmetry clear:
# conceptual attacker rule (real tool: bettercap dns.spoof) rewrite login.yourbank.example -> 192.168.1.66 # attacker's LAN box forward everything else -> untouched
Why the obvious checks miss it
Three things make targeted forgery slippery. It never changes your resolver, so a resolver-anomaly check stays silent. It only touches one domain, so a fixed-domain canary set almost certainly does not cover it. And a naive cross-check gets buried in false alarms from CDN geo-variance and from Pi-hole or AdGuard sinkholes, which legitimately answer some domains with local addresses.
A trustworthy detector threads all of that: it compares public-versus-public for the geo case (so normal CDN drift never fires), recognises a known sinkhole and suppresses it, and only raises the flag on the one pattern that has no innocent explanation — a public name resolving to a private address on the system path while DoH disagrees.
Catching it automatically
WifiThreatWatch resolves a curated set of stable public domains through both the system resolver and TLS-authenticated DNS-over-HTTPS to multiple literal IPs, and flags any public name the system redirects to a private address. CDN geo-variance never fires; a recognised sinkhole is suppressed. Detection is free.
Go deeper: how we detect targeted DNS forgery · detecting DNS spoofing · the threats library
Targeted DNS forgery: quick answers
What is targeted DNS forgery, and how is it different from DNS spoofing?
Targeted DNS forgery rewrites the DNS answer for one high-value domain — a bank, a login page, an update server — and forwards every other lookup untouched. Blanket DNS spoofing tampers broadly, which is easier to notice; the targeted version is surgical, so a canary that only checks a couple of fixed domains resolves them cleanly and reports all clear while the one domain that matters is quietly redirected.
How can I check whether a single domain is being forged?
Resolve the domain two ways and compare. Ask the system resolver with Resolve-DnsName, then ask DNS-over-HTTPS at a literal IP like 1.1.1.1 with curl. If the system hands back a private address (10.x, 172.16–31.x, or 192.168.x) while DoH returns a public one, that is a local redirect with no benign cause.
Why use DNS-over-HTTPS instead of a second normal DNS server?
An on-path attacker sits on port 53 and can forge or intercept any plaintext DNS query, including one aimed at a different server. DNS-over-HTTPS to a literal IP is authenticated by TLS, so the attacker cannot impersonate it or rewrite the answer without breaking the certificate. It is the one answer on the network you can still trust.
Will a Pi-hole or AdGuard sinkhole trigger a false alarm?
It should not, if the check is written carefully. A sinkhole deliberately answers certain domains with a local or null address, which looks superficially like a redirect. A good detector recognises a known sinkhole pattern and suppresses it, and it never flags CDN geo-variance because that is public-versus-public — both answers are routable, just different edges.
Can the attacker defeat the check by blocking the DoH lookup?
They can block it, but not forge it — TLS stops them from impersonating 1.1.1.1 or rewriting its answer. That is why you query more than one DoH IP. Blackholing a single provider is easy; blocking all of them at once is loud and itself a strong signal that something on the network is interfering with encrypted DNS.