What is DNS Cache Poisoning?
Learn what DNS cache poisoning is, how the attack works, its impact, and how DNSSEC defends against it — with interview Q&A.
Expected Interview Answer
DNS cache poisoning (also called DNS spoofing) is an attack where an attacker injects a forged DNS response into a resolver’s cache, tricking it into associating a legitimate domain name with an attacker-controlled IP address so subsequent lookups silently redirect victims to malicious servers.
The classic attack exploits the fact that DNS mostly runs over UDP and a resolver accepts the first response matching a query ID, source port, and question name as valid — an off-path attacker races to guess or predict those values and spoof a reply before the real authoritative server’s response arrives. If the forged answer wins the race, the resolver caches it for the record’s TTL, and every client using that resolver is silently redirected to the attacker’s IP for that domain until the cache entry expires. This can be used for phishing, credential theft, or malware delivery, all while the URL in the victim’s browser still looks correct. Defenses include randomizing query IDs and source ports to make guessing harder, and deploying DNSSEC so a resolver cryptographically rejects any response that is not properly signed by the legitimate zone, regardless of how convincing it looks otherwise.
- Explains a core motivation for DNSSEC deployment
- Highlights why UDP-based DNS needs randomization defenses
- Clarifies the difference between poisoning and simple misconfiguration
- Connects to real-world phishing and credential-theft risk
AI Mentor Explanation
DNS cache poisoning is like an impostor sprinting to hand a scoreboard operator a fake result sheet for match 4021 before the real official arrives with the genuine one — if the operator accepts whichever sheet shows up first, everyone reading that scoreboard for the rest of the day sees the fake score as if it were real. The operator has no way to tell the sheets apart unless someone thought to add a verifiable seal in advance. This race-to-arrive-first trick is exactly how an attacker poisons a DNS cache with a forged answer. Once accepted, the wrong result sticks around until the scoreboard is refreshed.
Step-by-Step Explanation
Step 1
Query observed or predicted
The attacker anticipates or observes a client’s DNS query for a target domain.
Step 2
Race the real response
The attacker sends a forged reply matching the query ID/port before the real authoritative answer arrives.
Step 3
Cache acceptance
If the forged reply is accepted first, the resolver caches the malicious IP for the record’s TTL.
Step 4
Silent redirection
Every client using that resolver is redirected to the attacker’s server until the cache entry expires.
What Interviewer Expects
- Explains that UDP + guessable query ID/port enables the race condition
- Understands the impact is silent redirection for the TTL duration
- Names DNSSEC as the cryptographic defense, and randomization as a mitigation
- Distinguishes cache poisoning from a simple misconfigured DNS record
Common Mistakes
- Confusing DNS cache poisoning with a phishing email attack
- Thinking HTTPS alone prevents cache poisoning (it does not stop the redirect)
- Not knowing the attack relies on winning a race against the legitimate response
- Assuming the effect is permanent rather than bounded by the record’s TTL
Best Answer (HR Friendly)
“DNS cache poisoning is when an attacker tricks a DNS server into storing a fake address for a real website, so anyone using that server gets silently redirected to a malicious site even though the web address in their browser looks completely normal. It is like someone swapping the listing in a directory so every call meant for a real business quietly rings a scammer instead.”
Code Example
# Query a resolver and inspect the returned TTL (seconds remaining in cache)
dig example.com
# ANSWER SECTION:
# example.com. 86400 IN A 93.184.216.34
# Flush the local resolver cache after suspecting poisoning (Linux, systemd-resolved)
sudo resolvectl flush-caches
# Validate with DNSSEC to reject unsigned/forged answers
dig example.com +dnssecFollow-up Questions
- How does DNSSEC prevent DNS cache poisoning?
- Why does DNS query ID and source port randomization make poisoning harder?
- What is the Kaminsky attack and why was it significant?
- How does DNS over HTTPS relate to protecting against poisoning?
MCQ Practice
1. What does DNS cache poisoning ultimately achieve for an attacker?
A poisoned cache entry maps a legitimate domain to an attacker IP, silently redirecting traffic.
2. Why is DNS over UDP especially vulnerable to this attack?
Without strong validation, whichever response with a matching ID/port arrives first is accepted.
3. What is the strongest technical defense against DNS cache poisoning?
DNSSEC cryptographically rejects forged responses regardless of how well the race is won.
Flash Cards
What is DNS cache poisoning? — Injecting a forged DNS response into a resolver’s cache to redirect victims.
Why does it work over UDP? — A resolver accepts the first reply matching the query ID/port, enabling a race.
How long does poisoning last? — Until the poisoned record’s TTL expires from the cache.
Primary defense? — DNSSEC signature validation, plus query ID/port randomization.