What is DNS cache poisoning (DNS spoofing)?
DNS cache poisoning is the attack that makes a name server store and hand out a false answer, so that whoever types the right address is taken to the criminal's server. There is no suspicious link to click and no typo: the name is correct, what was wrong was the answer. It is the attack that DNS signing, DNSSEC, exists to make detectable, and the reason trusting DNS is not a technical footnote.
How a DNS cache is poisoned
Before any connection, a device asks a resolver for the number behind a name. That resolver keeps the answer for a while so it does not have to ask again. The attack targets precisely that stored copy.
The attacker triggers the question
The resolver is forced to look up a name of the attacker's choosing, for instance by requesting a subdomain not yet in the cache. That way the attacker controls the exact moment the window opens and no longer has to wait for the cache to expire: the specification itself calculates that with this technique and a single source port, the chance of success reaches 50% in 7 seconds.
Forged answers are flooded in
While the legitimate answer is still traveling, the resolver is flooded with forged ones, each guessing the query identifier. Only one has to land before the real one arrives.
The false answer is accepted and stored
The resolver had no way to tell: the answer looked like it came from the right place and arrived first. It hands it to whoever asked and keeps it cached for as long as the forged answer asked for, up to the ceiling the resolver itself imposes.
Everyone behind that resolver is affected
From then on it is not one victim, it is all of them: every person and every system using that resolver gets the wrong address, with nothing unusual on screen.
Source: RFC 5452, the IETF specification on measures for making DNS resilient against forged answers, which describes the attack, measures how feasible it is, and defines the countermeasures required of resolvers.
Why DNS allowed this for decades
- The answer was checked against a 16-bit number. That was the entire shared secret between question and answer, and the specification does the arithmetic itself: with that field properly randomized, roughly 32,000 attempts on average are enough to guess it.
- First to arrive wins. The resolver accepts the first answer that looks valid and discards the rest. The attacker does not need to stop the real answer, only to outrun it.
- The expiry comes inside the answer itself. The forged answer carries the time it asks to stay cached, and that is what decides how long the poisoning lasts. The ceiling belongs neither to the attacker nor to the victim: it is the cap each resolver imposes, and in the most common configurations that cap is 24 hours.
- The victim has no symptom. The address in the bar is right, the name is right, and nothing warns that the translation was tampered with. That is why this attack does not show up in awareness training: there is nothing a person could notice.
The ways of delivering the wrong answer
- Cache poisoning The classic form and the most valuable to the attacker, because it contaminates everyone using that resolver at once. It is the one RFC 5452 measures and the one DNSSEC makes detectable.
- A forged answer on the local network On an open or compromised network, the attacker answers the query before the legitimate server does, with no cache to poison. It reaches whoever is on that network, one at a time.
- A changed resolver on the device Instead of fooling the resolver, the attack changes which resolver the device uses, pointing it at a server of the criminal's. Here the problem is already inside the equipment.
- Hijacking the record at the registrar This is not forgery, it is takeover: with access to the domain account, the criminal changes the record at the source. The answer becomes officially wrong, and DNSSEC does not stop it, because whoever controls that account also controls the link that anchors the signature in the domain above: removing it, or swapping it for their own, is enough to leave the domain unsigned.
What changes when the translation cannot be trusted
DNS is the layer nobody sees and everything depends on. A poisoned address does not just affect reaching a website: it affects the application calling an interface, the server fetching an update, the system connecting to a database and, most relevant here, the server looking up where to deliver your domain's email. That is why this attack sits underneath a whole family of defenses: the record stating which servers may send in your name, the key that verifies your messages' signature, the policy requiring an encrypted channel, all of them are DNS answers. If the translation can be tampered with, each of those defenses answers exactly what the attacker wants it to answer. The 2008 fix, which made resolvers randomize the source port as well, raised the cost of the attack by orders of magnitude, but raising a cost is not preventing: it remains a race the faster party wins, rather than a check on who is speaking: the specification itself calculates that even with the recommended 64,000 ports, the 50% level is reached after around 116 hours. There is also the consequence that usually goes unnoticed at board level: a large share of digital certificates is issued against a proof published in DNS. Whoever controls the answer can obtain a valid certificate for your name and show the padlock on the fake site, and can redirect where your domain receives email, which is how a request to change bank details reaches your client looking convincing.
How to reduce exposure to poisoning
The defense splits between what you do as the one asking and what you do as the owner of a domain:
- Use resolvers that validate signaturesA resolver that checks DNSSEC refuses the tampered answer instead of passing it along. It is the only defense that attacks the cause rather than the cost of the attack.
- Sign your own domainSigning lets whoever looks up your name detect tampering, including the servers delivering your email. It is the half of the problem within your reach to solve on your own.
- Treat the registrar account as a critical accountTakeover at the source is not forgery: whoever holds the account can switch off the signature itself. Two-factor verification, a transfer lock and a review of who holds access are worth more here than any other measure.
- Keep internal resolvers currentThe specification's countermeasures, such as source port randomization, only count if the software is on a version that implements them. An old resolver on an internal network is the door the 2008 fix never reached.
- Log DNS queriesQuery history is what lets you reconstruct an incident and spot odd patterns. It is the same raw material DNS filtering uses to block malicious domains.
In practice
It is like tampering with the phone book rather than breaking into the house: you look up the right name, dial the number the book gave you, and someone else picks up. Nothing on your side looks wrong, because nothing on your side is wrong. That is why this attack is not solved by user attention, but by a DNS answer that can be checked.
How Zamak handles trust in DNS
Zamak Technologies treats DNS as a trust layer rather than a directory: resolvers that validate signatures, the client's domain signed, a registrar account with controlled access, and query history kept for investigation, working with whoever already answers for the client's network. The whole of email authentication rests on that layer, because SPF, DKIM and DMARC are all DNS answers. DNSSEC explains how that verification works, and DNS filtering handles the other side of the problem, the domain that is malicious from the start. This is part of Managed Cybersecurity in the Zamak Method.