title: How to recover from DNS poisoning description: A DNS cache poisoning recovery playbook: confirm the attack, flush every cache layer, patch the resolver, and harden with DNSSEC so it can't recur. heroImageAlt: "Green line-art faucet pouring water through a cylindrical cache being flushed clean, with sparkles below on a dark grid" date: 2026-06-10 tags: [dns, security] author: Trace Warrior Team
DNS cache poisoning is a corruption problem, not an outage problem. An attacker has planted a forged answer in a resolver's cache, and now every client that asks that resolver gets sent to the attacker's IP, for as long as the forged record's TTL says so, or until you flush it out. Your zone file is fine. Your authoritative servers are fine. The lie lives in a cache somewhere between your users and the truth.
That shapes the whole recovery: you're not restoring data, you're hunting down every cache holding the forged answer and evicting it, then closing the door the forgery came through. Here's the playbook, in order.
Step 1. Confirm it's actually poisoning
Symptoms of DNS poisoning overlap with a registrar hijack, a hosts-file rewrite, and an honest fat-fingered zone change, and the recovery for each is different. Two minutes of triage saves an hour of flushing the wrong things.
Query the suspect name through several independent resolvers and compare:
dig @8.8.8.8 +short example.com A dig @1.1.1.1 +short example.com A dig +short example.com A # the suspect local/corporate resolver
Then query your authoritative nameserver directly, bypassing every cache:
dig @ns1.your-dns-provider.com +short example.com A
Read it like this:
- Authoritative answer is correct, one resolver disagrees: that resolver's cache is poisoned. This guide applies; scope is that resolver and everything downstream of it.
- Authoritative answer is wrong: your zone or registrar was compromised. Stop here and follow the hijack detection guide instead; flushing caches won't help.
- Only one machine sees the wrong answer: check its hosts file before blaming DNS.
Validate the bogus IP while you're at it. A reverse DNS lookup on the forged answer and a WHOIS lookup on its netblock usually make the malice obvious; phishing infrastructure rarely bothers with clean PTR records. Capture this evidence (dig outputs, timestamps, the bogus IP) before you flush anything; it disappears the moment recovery succeeds.
Step 2. Flush every cache layer, inside out
A forged answer replicates down the chain: resolver cache → OS stub cache → browser cache. Flush in that order, or clean clients will just re-poison themselves from the still-dirty resolver above them.
Recursive resolvers you operate:
# BIND rndc flush # Unbound - surgical, just the affected zone unbound-control flush_zone example.com # dnsmasq sudo systemctl restart dnsmasq
Operating systems:
# macOS sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Linux (systemd-resolved) resolvectl flush-caches
Browsers: Chrome and Edge keep their own DNS cache; clear it at chrome://net-internals/#dns (and clear the socket pools, since open connections to the bad IP survive a DNS flush).
Caches you don't control: public resolvers and ISP resolvers will hold the forged record until its TTL expires. You can't force-flush them, but Google (https://dns.google/cache) and Cloudflare (https://one.one.one.one/purge-cache/) both offer public purge forms; use them if the poisoning reached those resolvers.
Verify after each layer: re-run the dig from step 1 and confirm the answer now matches authoritative.
Step 3. Patch and reconfigure the resolver that got poisoned
A poisoned cache means the resolver accepted a forged response. If you only flush, you'll be doing this again next week. On the affected resolver:
- Update the software. Classic poisoning techniques exploit weak transaction-ID randomisation and related flaws that have been patched for years, but only if you're running a patched version. Update BIND/Unbound/dnsmasq to current.
- Confirm source-port randomisation is on (default in all modern resolvers; legacy configs sometimes pin the port).
- Restrict recursion. An open resolver gives attackers unlimited tries. In BIND:
allow-recursion { trusted-nets; }; - Check for the deeper compromise. If the resolver box itself was breached (rather than tricked over the network), poisoning is the symptom, not the disease. Audit logins and processes before trusting it again.
Step 4. Implement DNSSEC so forgeries stop validating
DNSSEC is the structural fix: signed answers mean a validating resolver rejects forged records instead of caching them.
On the zone side, enable signing at your DNS provider (most managed providers make this a toggle) and publish the DS record at your registrar. On the resolver side, turn on validation: dnssec-validation auto; in BIND, on by default in Unbound. Then verify the chain end to end:
dig +dnssec example.com A @8.8.8.8 # look for the 'ad' flag delv example.com A # full chain-of-trust validation
The ad flag confirms a validating resolver authenticated the answer. With that in place, the poisoning vector you just recovered from is closed for every validating resolver on the path.
Step 5. Monitor so the next incident is minutes, not days
Most poisoning incidents are discovered by a user reporting "the site looks weird", which means the forged record had been serving for hours. Close that gap:
- Resolver query logging. Turn it on (
querylog yes;in BIND). After an incident, logs tell you how long the bad record served and what queried it. - Continuous record monitoring. A DNS record drift monitor baselines your records and re-checks every 15 minutes through a real public resolver, alerting with a diff when an answer changes. That's the difference between detecting poisoning at TTL-scale and detecting it at help-desk-scale. The setup guide covers picking record types that alert on signal, not noise.
- Spot-check after the dust settles. Run the affected names through the DNS Lookup tool from a network outside your own a day later, confirming public resolvers all converged back to truth after TTL expiry.
Step 6. Handle the blast radius
The DNS layer being clean doesn't mean the incident is over. While the forged record served:
- Credentials may be stolen. If the bogus IP hosted a clone with a login form, force resets for users who authenticated during the window.
- Mail may have been intercepted if MX answers were forged; check whether sensitive threads happened during the window.
- Sessions to the bad IP may persist. Long-lived connections established during the poisoning survive the flush. Bounce anything suspicious.
- Tell your users. A short, factual notice ("between X and Y, some visitors may have been redirected; here's what to do") beats them finding out from a password-reuse breach later.
Common recovery mistakes
Flushing client caches before the resolver. Clients re-query and re-poison themselves instantly. Always resolver first, then OS, then browser.
Forgetting the browser layer. Chrome's internal DNS cache and open socket pools outlive an OS-level flush. chrome://net-internals/#dns, both buttons.
Treating the flush as the fix. The flush removes the symptom. The patched, recursion-restricted, DNSSEC-validating resolver removes the vulnerability.
Skipping the evidence capture. Once caches are flushed, the forged record is gone. Save dig output and timestamps first; you'll want them for the post-incident review.
TL;DR
- Confirm with
digagainst multiple resolvers plus your authoritative server; poisoned cache vs hijacked zone changes everything. - Flush inside out: resolver (
rndc flush/unbound-control flush_zone) → OS (ipconfig /flushdns,dscacheutil -flushcache,resolvectl flush-caches) → browser. - Purge Google/Cloudflare public caches if affected; everything else waits for TTL.
- Patch the resolver, restrict recursion, confirm port randomisation.
- Sign the zone and validate with DNSSEC; check for the
adflag. - Add query logging and a drift monitor; then deal with stolen credentials and intercepted traffic.
Related
- How to detect DNS hijacking: the triage that tells you which incident you actually have
- How to monitor DNS records for drift: continuous detection setup
- DNS Lookup tool: verify recovery from an outside network