Later clients can receive the false mapping from the cache, redirecting traffic or causing failures until the entry expires, is replaced, or is removed. The attack corrupts cached resolution data; it does not require control of the domain’s registration or authoritative zone.
False data may arrive in a forged response or through a compromised resolution path. Strong matching makes off-path forgery harder. DNS Security Extensions (DNSSEC) validation rejects altered signed data when a trust chain exists, but does not authenticate unsigned zones or every client-to-resolver hop.
Key points
ScopeIdentify affected resolvers, names and record types, when the record entered the cache, its remaining lifetime, and which clients or services received it.
EvidenceCompare cache contents with authoritative data and validating resolvers, then review response logs, forwarding paths, changes, validation results, and redirected activity.
Risk reductionMaintain resolver software, use strong response matching and source-port entropy, restrict recursion and administration, validate DNSSEC where appropriate, protect resolver channels, and monitor unexpected changes.
Important limitationA surprising answer is not automatically poisoning. Caching, split DNS, forwarding, local overrides, load balancing, and configuration mistakes can produce answers that differ from public data; signing errors can also cause DNSSEC validation failures.