Introduction — What is DNS cache poisoning
Grasp the picture that when a shared resolver memorizes a forged RRset, every user sees the same bad answer.
First diagram to have in mind
| Actor | Role |
|---|---|
| User / browser | The side that looks up names. Trusts the resolver's answer. |
| shared recursive resolver | The cache lives here. Shared by many users. |
| authoritative servers | Hold the canonical data for each zone. |
If a bad RRset ends up in the cache of the shared recursive resolver, the same bad answer gets served to every user of that resolver.
DNS cache poisoning is "tampering with shared memory"
What is dangerous in DNS is not a single user's device being temporarily confused — it is a shared recursive resolver memorizing a forged RRset and reusing it over and over. From the user's perspective, the resolver looks like "the entity that knows the answer," and they cannot tell whether that answer is real or cached.
So in troubleshooting you have to separate "the answer I am seeing now: is it authoritative, is it cached, or is it in the middle of a referral?" up front.
Practice 1-1 — Put the shared cache at center stage first
A compromise of an authoritative server and poisoning of a shared recursive resolver can look similar. But the place you should follow first for defense and observation is different.
Q1. Which condition is the central problem in DNS cache poisoning?
The core of the problem is "what did the shared resolver end up memorizing?"
In DNS cache poisoning, the central problem is that a recursive resolver accepts a forged RRset, keeps it in its cache, and redistributes it to its users. This is distinct from tampering with the authoritative zone itself.
Q2. When a single shared recursive resolver is poisoned, what is the main reason the impact spreads so easily?
Think about "how many people does one resolver answer?"
A shared recursive resolver returns the same cached result to many users. As a result, a single false acceptance propagates to everyone who uses that resolver.
Because of TTL, a bad answer "sticks around for a while"
A poisoned RRset is not made permanent the moment it is accepted — it lives in the shared cache only for the duration of its TTL. So even after you patch, until the existing cache entry's lifetime runs out, you can still see the same bad answer.
In observation, looking at "are the remaining TTLs similar?" and "do multiple users of the same resolver see the same value?" makes it easier to separate it from an individual browser problem.
Practice 1-2 — A bad answer lives only for its TTL
A poisoned RRset lives in the shared cache only for the length of its TTL. Being able to follow the remaining seconds makes observation and triage easier.
Q3. A shared resolver accepted a forged answer with a TTL of 300 seconds at 09:00:00. How many seconds of TTL remain at 09:03:00?
From 09:00:00 to 09:03:00 is 180 seconds elapsed.
Subtracting the elapsed 180 seconds from 300 seconds gives 120 seconds remaining. Whether it is poisoning or just a stale cache, being able to follow the remaining TTL in numbers is the first step of observation.
Do not conflate phenomena that look similar
Internal DNS, split-horizon, negative caching, and the browser's HTTP cache can all look like "name resolution is broken" from a user's perspective. That is exactly why you should fix "which layer's cache" first, and then compare the authoritative path with what the affected resolver is returning.
What is split-horizon: A DNS operational design where the same name intentionally returns different answers from internal-facing resolvers and external (public) resolvers. A typical configuration is to return an internal IP from inside the office and a public IP from the outside. The details are covered in Chapter 6, but when reading the choices in Q4, keep in mind that this kind of "intentional design difference" can exist.
Practice 1-3 — Do not confuse lookalike phenomena
Internal DNS, split-horizon, negative caching, and the browser's HTTP cache can all look similar. Fix "which layer's cache" first.
Q4. Which is the most likely explanation for "the same internal name looks different from the internal resolver and from a public resolver"?
Just seeing a difference does not immediately make it an attack.
Returning different answers for inside vs. outside views — split-horizon / internal DNS — is perfectly normal. When you see a difference, first decide whether it is an intentional design difference or an actual anomaly.
Q5. Which is the correct way to avoid confusing DNS cache poisoning with HTTP caching?
DNS TTL and HTTP cache-control are at different layers.
DNS cache poisoning is about the shared cache of name-resolution results. You need to think of it separately from HTTP or CDN caches. Changing the DNS TTL does not automatically clear the browser's HTTP cache.
Key takeaways from this chapter
- DNS cache poisoning's main battlefield is the memory of a shared recursive resolver
- A forged answer sticks around for its TTL, so treat the patch and the cache lifetime as separate things
- Do not conflate lookalike phenomena such as split-horizon or the HTTP cache