Lessons from 2008 — Parallel queries and short-term mitigations
Understand the widely known 2008 issue as a high-level attack idea and as a set of short-term mitigations.
Recap of the previous chapter: In Chapter 3 we organized response acceptance conditions (question / ID / address / port), the race window, and the relationship between entropy and number of attempts. In this chapter we use that framework to confirm "why the issue widely known in 2008 was so serious," and the combination of short-term mitigations that has continued from then on.
Note: This chapter covers the historical lessons and the intent of defenses. It does not cover attack procedures against real environments or exploit code.
What was so serious about 2008
DNS cache poisoning itself had been known for a long time, but the issue that Dan Kaminsky brought to wide attention in 2008 (commonly referred to as the "Kaminsky attack") sharpened the point that "if uncached query opportunities can be created repeatedly, even a short race window lets you pile up more attempts." The detailed attack procedure is out of scope here, but at a high level, the idea is "issue queries one after another to non-existent labels such as random123.example.com, creating a fresh miss each time and trying the race many times."
Even if one race is short, repeated fresh misses raise the cumulative risk. RFC 5452 describes attempts and outstanding queries separately precisely to help you grasp this picture.
Practice 4-1 — Why growing attempts is a serious problem
Even if one race is short, repeated fresh misses raise the cumulative risk.
Q1. Which statement best captures the lesson from the DNS cache poisoning issue that became widely known in 2008?
The key is what increased the "number of attempts."
The lesson of the widely known 2008 issue is that repeatedly creating uncached query opportunities raises the number of race attempts against forged responses, so the risk rises. Here we only go as far as understanding the mechanism.
Q2. With everything else held constant, if the number of identical outstanding queries D grows over a small range from 1 to 2, how does the per-window spoof success probability roughly change?
RFC 5452 says the relation is roughly proportional for small D.
With everything else equal, more identical outstanding queries D means a higher chance that one of them is hit within the same window. Over a small D range you can treat it as roughly proportional, so going from 1 to 2 is roughly a doubling.
Open recursion and monitoring
As we saw in Practice 4-1, the largest factor that increases risk is "attempts" (the number of fresh misses generated). So who can grow that attempts count? One answer is open recursion. When the resolver is usable by anyone, a third party can freely issue queries from outside, which makes it easy for them to deliberately drive up fresh misses and attempts. In other words, open recursion is a configuration that "widens the entry point through which an attacker can inflate attempts."
In terms of load, observational noise, and race opportunity, this expands exposure. In operations, it helps to keep monitoring signals such as "sudden spikes of queries to random labels," "a lopsided miss pattern against specific zones," and "port entropy degradation caused by NAT." They make it easier to notice behavioral changes.
Practice 4-2 — Open recursion and short-term mitigations
A resolver that anyone can query expands exposure. Short-term mitigations from a single angle are not enough.
Q3. Which statement best explains why open recursion tends to raise risk from a cache poisoning perspective?
Consider how wide the "entrance" is for triggering queries.
Under open recursion, anyone can cause the resolver to issue queries. This makes it easy to increase cache misses and load, which in turn creates more race attempts, so exposure grows.
Q4. Which of the following does not belong among the short-term mitigations?
Think about which option has heavy side effects and is insufficient as a defense.
Appropriate short-term mitigations combine patch / update, randomness of source port and transaction ID, recursion limited to trusted clients, and monitoring of query bursts and random-label spikes. Pinning the TTL at infinity has heavy operational side effects and is insufficient as a defense, so it should not be included among short-term mitigations.
Q5. Which of the following is incorrect?
Recall that DNSSEC provides "signature-based verification," not confidentiality.
The third choice is incorrect. DNSSEC does not provide confidentiality of query names or response bodies. The other three are accurate; in particular, stale or wrong answers can remain visible after a patch while existing cache TTLs are still counting down.
Chapter 4 summary
- Even a short race window accumulates risk when fresh misses and attempts grow.
- Open recursion expands exposure, so restricting to trusted clients is the baseline.
- Patch / entropy / recursion control / monitoring form the base of short-term hardening.