DNS cache poisoning
In network security, DNS cache poisoning is the insertion of a forged answer into a resolver’s cache, so everyone who asks that resolver for a name is sent to an address the attacker chose. The domain’s own records are untouched and so is its registrar account: what is corrupted is the copy of the answer the resolver keeps and serves.
How it works
A resolver does not ask the authoritative servers every time. It caches each answer for the lifetime the record declares and serves that copy to every client behind it. Cache poisoning targets that copy: the attacker gets the resolver to accept a forged answer and store it, and from that moment every user of the resolver is sent to the attacker’s address for as long as the entry lives, without a single machine belonging to the victim being touched.
Getting the forgery accepted is a race. When the resolver queries the authoritative server, the attacker tries to deliver a reply that arrives first and looks legitimate, which means matching the question, the transaction identifier and the port the resolver used. The defences that make this hard are the ones that make those values unpredictable, and above them validation with DNSSEC, which lets a resolver reject an answer whose signature does not check out.
A single poisoned entry is enough to be worth the effort: the domain where people type their credentials, the endpoint software updates are pulled from, or a mail record. The classic case is banking. The user types their bank’s real address, their resolver hands back the attacker’s IP, and they land on a copy of the site built to collect credentials, which is phishing delivered without anyone having to click a link in an email.
What goes wrong
The blast radius is the resolver, not the victim. One corporate resolver serves a whole office and one operator’s resolver serves a large population, so a single accepted forgery redirects everybody behind it. The organisation whose name was forged has nothing to find in its own logs, because nothing of its own was touched, and it almost always hears about the problem from its users.
It gets confused with DNS hijacking, and the two need different fixes. Hijacking takes control of the resolution itself, at the registrar, in the zone records or over the resolver’s configuration, so the wrong answer is the authentic answer and it is served correctly. Poisoning leaves control where it was and corrupts a cached copy, so the wrong answer is a forgery the resolver believed. Multi-factor authentication on the registrar account and monitoring of records stop the first and do nothing about the second; unpredictable query parameters and DNSSEC validation stop the second and do nothing about the first.
Once it is in, the forged entry stays until it expires or until someone flushes the cache. How long that is gets decided by the attacker, because the lifetime travels inside the very answer they fabricated.
Where this shows up in an audit
On the perimeter we look at the resolvers a client actually uses and at the ones they expose. We check whether a resolver answers recursive queries for anyone on the internet, because an open resolver is both a target and a tool for attacking someone else; whether its query parameters are properly randomised; and whether it validates DNSSEC, which is the control that turns a forged answer into a rejected one. On the client side we look at where queries travel and whether an encrypted transport such as DNS over HTTPS is in use. Findings are written against the resolver and the control that was missing, with the redirection demonstrated where scope allows. This is part of how we check DNS integrity on the perimeter.