What is DNS cache poisoning, and how is it prevented?
An attacker tricks a resolver into caching a forged answer, such as a bank's name mapped to the attacker's IP. Later users of that resolver are sent to the fake site. Defences include random source ports and query IDs, and DNSSEC, which signs records.
Explain it simply
Imagine someone slips a fake entry into the town's directory, so everyone looking up "State Bank" is sent to a lookalike counter. The damage lasts until the directory entry expires.
Example
1. Victim's resolver asks the authoritative server: "bank.example?"
2. Attacker floods the resolver with forged replies:
"bank.example = 198.51.100.66" (matching the query ID by luck)
3. A forged reply arrives first and matches -> the resolver caches it
4. For the whole TTL, users of that resolver reach 198.51.100.66Early DNS used a 16-bit query ID and a fixed source port, so guessing was feasible. Modern resolvers randomise the source port too, which multiplies the guessing work by roughly 60,000.
DNSSEC adds digital signatures to records, so the resolver can verify an answer really came from the zone's owner. Even so, HTTPS adds a second line of defence: the fake site cannot present a valid certificate for the bank's name, so the browser warns the user.
What to say in the interview
"Poisoning inserts a false record into a resolver's cache. Randomising source ports and IDs makes forgery hard, DNSSEC authenticates the data, and TLS certificate checks stop a fake site from looking genuine."
Common mistakes
- Saying HTTPS alone fixes DNS poisoning. It stops impersonation but not the redirection.