Fixing a hijacked or poisoned DNS record at its source does not stop hosts from using the bad answer: every resolver and client that cached it keeps sending traffic to the attacker until the entry expires or is flushed. MITRE D3FEND names this countermeasure DNS Cache Eviction (D3-DNSCE), synonym "Flush DNS Cache", and defines it as "Flushing DNS to clear any IP addresses or other DNS records from the cache." It sits under the Evict tactic as a child of Object Eviction (D3-OE). This card explains where DNS caches live in an enterprise, how to flush each layer with the commands the vendors document, how to prove the bad record is gone, and what flushing cannot do. It is written for incident responders and DNS and network engineers handling DNS hijacking, cache poisoning or malicious records during eviction.
Key takeaways
- Fix the source, then flush. Flushing before the authoritative record, the forwarder setting or the hosts file is corrected simply lets the bad answer be fetched and cached again.
- Caches are layered. Recursive resolvers, forwarders, operating system stub resolvers and applications each hold their own copy. Flush from the top of the chain down to the clients.
- Targeted beats total. BIND, Unbound and Windows DNS Server can flush one name or one subtree. A full flush on a busy resolver causes a burst of upstream queries and loses evidence.
- D3FEND lists no ATT&CK mapping. D3FEND 1.6.0 records only that the technique deletes DNS Record and gives no ATT&CK relations, so the threat context on this page is NHI Mgmt Group's view and is labelled as such.
- Dump before you flush. Cache contents show which clients received which poisoned answers. Every major resolver can dump its cache; do it first.
D3-DNSCE at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DNSCE (d3f:DNSCacheEviction) |
| Synonym | Flush DNS Cache |
| Tactic | Evict |
| Parent technique | Object Eviction (D3-OE) |
| Digital artefact | DNS Record (the D3FEND ontology states the technique deletes DNS Record; the website's artefact diagram for the technique is empty) |
| D3FEND reference | CISA, Eviction Guidance for Networks Affected by the SolarWinds and Active Directory/M365 Compromise (AR21-134A) |
| Effort | Low per cache; the work is in finding every cache that holds the record |
| Main limitation | Removes only cached copies; does nothing if the source of the bad record is still in place |
How it works
D3FEND's description is that flushing the cache clears recently resolved addresses and can help remediate DNS cache poisoning, where corrupted DNS data inserted into a cache redirects users to malicious sites, and it gives the Windows client command ipconfig /flushdns as the example. In practice a DNS answer is cached for its time to live at every hop that resolved it. When the answer was malicious, each hop keeps redirecting until the TTL runs out. Attackers who control a record can also set a long TTL to extend that window. Eviction shortens it to now.
D3FEND's reference for the technique is CISA's eviction guidance written after the SolarWinds supply chain compromise. The placement makes the point: a cache flush is one step inside a wider eviction, done after the bad records and the access that created them are removed, not a remedy on its own.
Where poisoned or malicious records sit
| Cache layer | Examples | Typical cause of a bad entry |
|---|---|---|
| Recursive resolvers and forwarders | BIND, Unbound, Windows DNS Server, cloud and protective DNS resolvers | Poisoned responses, hijacked authoritative records, a malicious forwarder or conditional forwarder |
| Operating system stub resolver | Windows DNS Client service, systemd-resolved on Linux | Answers received from a compromised resolver, or a rogue resolver set on the host |
| Applications | Browsers, language runtimes and long-running services that cache lookups themselves | The same bad answer, held for the application's own cache period |
| Static overrides | The hosts file, which the operating system consults before DNS | Attacker edits on the host; flushing alone will not clear this |
ATT&CK context
Relationship type: none in D3FEND. D3FEND 1.6.0 lists no ATT&CK relations, direct or inferred, for D3-DNSCE (checked November 2026). The table below is NHI Mgmt Group's view of the ATT&CK techniques after which a DNS cache flush is commonly part of clean-up. It is not a D3FEND mapping. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Why caches need flushing afterwards (our view) |
|---|---|---|
| T1584.002 | Compromise Infrastructure: DNS Server | Records changed on a compromised DNS server propagate into every cache that queried it |
| T1557 | Adversary-in-the-Middle | Spoofed DNS answers on a local network leave bad entries in client caches |
| T1565.002 | Transmitted Data Manipulation | Altered responses in transit are cached as if genuine |
Response to registrar or authoritative DNS hijacking is covered end to end in the DNS Hijack Playbook; this card covers only the cache step.
Where it is implemented
Platforms are listed alphabetically.
| Platform | Whole cache | Targeted flush | Inspect first |
|---|---|---|---|
| BIND 9 (rndc) | rndc flush flushes the server's cache | rndc flushname removes a name from the view's cache (and related nameserver address, bad-server and SERVFAIL entries); rndc flushtree removes a name and all its subdomains | rndc dumpdb -cache writes the cache to the dump file |
| systemd-resolved (resolvectl) | resolvectl flush-caches flushes all locally maintained resource record caches | Not offered per name in the command reference; flush the whole local cache | resolvectl show-cache (version 254 and later) shows cache contents by scope |
| Unbound (unbound-control) | Restart, or flush_zone . for everything below the root | flush removes a name for common record types; flush_type one name and type; flush_zone everything at or below a name; flush_negative and flush_bogus remove negative and bogus data | dump_cache prints cache contents; lookup shows which name servers would be used for a name |
| Windows DNS Client | Clear-DnsClientCache, documented as equivalent to ipconfig /flushdns | Whole cache only | Get-DnsClientCache |
| Windows DNS Server | Clear-DnsServerCache clears resource records from the server cache | -CacheScope clears a named cache scope | Show-DnsServerCache, Get-DnsServerCache |
Two Unbound details matter during an incident. flush_zone walks the whole cache and is slow on large caches, and with serve-expired enabled Unbound can keep answering with the old data while it fetches new data, so confirm the setting before relying on a flush. Server hardening for these resolvers is in the BIND DNS Server Hardening and CoreDNS Security guides.
Implementation steps
- Scope the bad records. List the names and record types affected and the correct values. Use resolver query logs to find which resolvers and clients asked for those names during the exposure window. See the DNS Logging and Detection Guide.
- Preserve evidence. Dump the cache on each affected resolver (
rndc dumpdb -cache,unbound-control dump_cache,Show-DnsServerCache) and captureGet-DnsClientCacheorresolvectl show-cacheoutput from a sample of clients. - Correct the source. Restore the authoritative record, remove a rogue forwarder or conditional forwarder, revert hosts file edits and revoke the access the attacker used to make the change. Registrar and DNS provider access is often a non-human credential such as an API token; rotate it as part of this step.
- Flush top down. Flush forwarders and recursive resolvers first, using targeted commands for the affected names, then client caches through endpoint management. If clients are flushed first they simply re-cache the bad answer from an unflushed resolver.
- Handle what you cannot flush. External resolvers and partners' caches are outside your control. Their entries expire when the TTL set on the bad record runs out, so record that TTL and tell affected parties when the window closes.
- Rollback. Flushing is low risk and has nothing to roll back. The risk is load: a full flush on a large resolver produces a spike of upstream queries, so prefer per-name flushes during business hours.
How to verify it works
- Query each resolver directly for the affected names and check that the answer is the corrected value and that the returned TTL is fresh, not the remainder of the old one. The DNS Investigation with dig and nslookup Guide covers the queries.
- Re-dump the cache and confirm the bad entries are absent.
- Sample clients: confirm the bad value is no longer in the client cache and that the hosts file holds no override for the name.
- Watch traffic: connections to the attacker's IP addresses from internal hosts should stop after the flush; any that continue point to a cache or override you missed.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internal resolvers returning the corrected answer after eviction | 100% | Proves no resolver still holds the bad record |
| Internal connections to attacker IPs after the flush | Zero, with each exception traced | Finds application caches and hosts file overrides |
| Resolvers with query logging enabled | All internal resolvers | Without logs you cannot scope who received the bad answer |
| Time from source correction to completed resolver flush | Tracked per incident | The gap is the time clients keep being misdirected |
Limits, bypasses and failure patterns
- Flushing before fixing: the most common mistake. The cache refills with the same bad answer within seconds.
- Missing a layer: flushing the resolver but not forwarders, or the client but not the application, leaves the old answer in use.
- Hosts file overrides: the operating system answers from the hosts file before DNS, and no cache flush touches it.
- Serve-stale behaviour: resolvers configured to serve expired data can keep handing out old answers after a flush while refresh is pending, as Unbound documents for
flush_zonewithserve-expired. - Losing the evidence: a flush without a prior dump destroys the record of which resolvers held which poisoned entries.
- No prevention: flushing is reactive. DNSSEC validation on resolvers and secure resolver architecture reduce the chance of poisoning in the first place; see the DNSSEC Deployment Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) | Integrity of the answers caching resolvers hold and return |
| NIST SP 800-53 Rev 5 | SC-20 Secure Name/Address Resolution Service (Authoritative Source) | The source record that must be corrected before flushing |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Eradication activities in the incident process |
| NIST CSF 2.0 | RS.MI-02, DE.CM-01 | Incidents are eradicated; network services are monitored |
| MITRE D3FEND | D3-OE, D3-DNSCE | Parent and technique |
Related countermeasures
- DNS Denylisting (D3-DNSDL) and Forward Resolution Domain Denylisting (D3-FRDDL): block the malicious names at the resolver so a flushed entry cannot be fetched again.
- DNS Traffic Analysis (D3-DNSTA): finds the clients that resolved the bad names.
- Domain Registration Takedown (D3-DRT): removes the attacker's domain at the registrar. See D3-DRT Domain Registration Takedown.
- Authentication Cache Invalidation (D3-ANCI): the same eviction logic applied to cached credentials. See D3-ANCI Authentication Cache Invalidation.
- Object Eviction (D3-OE) is the parent class; the wider model is in the MITRE D3FEND Guide.
Practitioner checklist
- Correct the authoritative record, forwarder or hosts file before any flush.
- Revoke and rotate the credential or token used to change DNS.
- Dump resolver caches and sample client caches as evidence first.
- Flush resolvers and forwarders before clients, using per-name commands where available.
- Check for serve-stale settings that keep old answers alive.
- Check hosts files on affected endpoints.
- Verify each resolver returns the corrected answer with a fresh TTL.
- Record the bad record's TTL and tell external parties when their caches will expire.
- Keep query logging on all internal resolvers so future scoping is possible.
Standards and references
- MITRE D3FEND: DNS Cache Eviction (D3-DNSCE)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-20, SC-21)
- ISC: BIND 9 manual pages (rndc)
- freedesktop.org: resolvectl
- NLnet Labs: unbound-control
- Microsoft Learn: Clear-DnsClientCache
- Microsoft Learn: Clear-DnsServerCache
Related NHI Mgmt Group resources: DNS Hijack Playbook · DNS Security Guide · DNS Logging and Detection Guide · Protective DNS Guide · MITRE D3FEND Guide