From Predictable Outputs to a Poisoned Cache
This chapter follows BIND 9 from a recovered PRNG state to the point where a recursive resolver might accept a forged answer. The focus is the chain of conditions between prediction and impact: a query must be the right one, the forged response must match what the resolver is waiting for, and it must arrive and pass the relevant checks before the genuine answer wins. That chain also explains why the published study describes several different attack variants rather than one universal procedure, and why features such as QNAME minimization, DNS cookies, and prefetching change the conditions without repairing the weak shared generator.
A predicted query is only the beginning
State recovery gives an observer a model of future PRNG outputs. It does not yet change BIND, inject a packet, or place a false record in the cache. To become a poisoning attempt, the model must be aligned with a later outbound query from the relevant resolver or worker. The predicted values include the transaction ID and UDP source port that the resolver will use for that query. The forged response must also describe the right query context and appear to come from the expected authoritative source.
The final network condition is a race. BIND sends a legitimate query toward the authoritative server. An off-path party tries to deliver a response that looks like the answer to that query before the genuine response returns. If the forged response arrives too late, a matching prediction has no practical effect. If it arrives first but fails the resolver’s response checks, it is rejected. Prediction improves the odds of passing the query-matching hurdle; it does not remove timing, routing, or acceptance from the lifecycle.
The USENIX paper describes the payload as a modern version of the Kaminsky pattern. Rather than trying to replace only the address record the victim wants, the forged response supplies a false name-server delegation, with supporting glue information that tells the resolver where that authority can be reached. The target name and its descendants can then be resolved through the malicious name server. This is more consequential than a single incorrect answer because it changes the resolver’s view of who is authoritative for a part of the namespace.
That distinction is about persistence and scope. A narrowly wrong record may affect one lookup or remain confined to one cache entry. A poisoned delegation can influence subsequent lookups below the delegated name and can continue to matter when the resolver refreshes records. The cache turns a momentary race into a stored routing decision. The ISC advisory for CVE-2025-40780 summarizes the impact at the appropriate level: if spoofing succeeds, BIND can be tricked into caching attacker responses.
The lifecycle is therefore conditional at every transition:
The diagram separates three ideas that are often compressed into the word “exploit.” Inference is learning enough about the generator. Prediction is using that knowledge to forecast a later query. Poisoning is the successful acceptance and persistence of false authority data. A deployment can block the chain at any of those boundaries. It can make observations difficult, send the genuine answer first, reject an invalid response, or prevent the resulting data from being trusted. The paper’s contribution is that the first boundary is unexpectedly weak in the tested BIND configurations; it does not claim that the later boundaries disappear.
The network path also explains why timing depends on location. The forged response must reach the resolver before the legitimate authoritative response. The relative round-trip time between the injection point and the resolver, compared with the resolver’s path to the genuine authority, affects the size of that window. A prediction that is exact but arrives outside the window is still a failed poisoning attempt. This is one reason that high prediction accuracy and high cache-poisoning success should be reported as related but separate measurements.
Different BIND branches expose different paths
The research distinguishes variants by what the observer can see and which DNS role participates. RRset and RRset-ANY are client-side approaches reported for BIND 9.20 and 9.21 resolvers. They use randomized ordering in cached record sets as the observation channel. The RRset-ANY form can retrieve several cached sets in one response, making multiple PRNG outputs available in a tightly grouped operation. That atomicity reduces the chance that unrelated resolver work will advance the relevant state between observations.
The “Living off the Land” version changes the infrastructure requirement rather than the root mechanism. The study reports using large record sets already served by third-party authoritative servers, so the observer does not need to upload records to an authoritative server or operate an attacker-owned domain for that observation step. The authors still directed the poisoning target to infrastructure they controlled in the experiment. The lesson is about the availability of an observation channel, not permission to use unrelated systems as test targets.
RR-QMA is a server-side technique. Here, the useful observation is a sequence of transaction IDs on queries that BIND sends to an authoritative server under the observer’s control. The paper reports that this path applies to BIND 9.18 as well as the later tested branches, including the older branch for which the client-side RRset methods are not shown as compatible. The server-side label describes where the observation is made; it does not mean the authoritative server itself is the vulnerable component. BIND’s recursive process remains the component whose PRNG state is being modeled.
The forwarder case makes the role boundary especially important. A forwarder does not need to query an attacker-controlled authoritative server directly in order to be exposed. It still performs resolution work and consumes the relevant resolver behavior. The paper reports an RRset-ANY evaluation against BIND 9.20 configured as a forwarder to Google Public DNS. That result supports a narrower conclusion: forwarding can preserve the attack surface in the tested configuration. It does not establish that every forwarder, upstream service, or network topology behaves the same way.
The paper’s compatibility picture is best read as a map of observation paths, not as a ranking of “safe” and “unsafe” releases. In its table, the client-side zone and client-side LotL approaches are marked for the 9.20/9.21 resolver branches and their forwarder setting, but not for the 9.18 resolver. The server-side authoritative-server approach is marked for the resolver branches, including 9.18, but not for the forwarder column. Those marks tell us which combination the authors analyzed and tested. They do not prove that a cross-marked configuration is immune; they show that the particular observation route depends on where BIND sends queries, how it exposes outputs, and which role is present. An operator therefore needs a version-and-role assessment rather than a product-name conclusion.
This distinction also prevents a common analytical shortcut. If a client-side observation is unavailable in one branch, that does not mean the underlying PRNG issue has vanished. It may mean that the branch’s behavior does not expose the same output in the same way, while another observation path remains relevant. Conversely, an observation path demonstrated in a lab does not establish that the required state alignment exists in every deployment. Compatibility is evidence about a mechanism under conditions; it is not a substitute for local configuration and version verification.
QNAME minimization helps explain why these variants can behave differently. QNAME minimization is a privacy-oriented resolver behavior: when following the DNS hierarchy, a recursive service sends only the name information needed to obtain the next step rather than exposing the full original name at every stage. The NIST deployment guide presents it as a way to limit what upstream servers learn, with a possible small query cost as caches fill.
In the BIND attack analysis, the same behavior also affects scheduling. When a minimizing query is outstanding, dependent queries can be held temporarily and then released together after the intermediate response arrives. That creates near-atomicity: a group of operations that might otherwise be interleaved with unrelated resolver activity is produced in a tighter sequence. For RR-QMA, this makes the transaction-ID observations easier to associate with successive steps of one PRNG instance. The privacy feature is not thereby “bad.” It is doing its intended job for name exposure while also changing the timing and batching properties relevant to a different threat.
This is a broader systems lesson about security features. A feature’s effect cannot be summarized by its design goal alone. QNAME minimization reduces one kind of information disclosure, but it may alter the order in which a particular implementation performs work. The right question is always property-specific: does it protect the original name, prevent state inference, reduce response acceptance, or merely change the observation window? In this case, the paper reports that qname minimization does not block the methods it studies and can improve certain variants’ reliability.
Why cookies and prefetching do not close the chain
DNS cookies add another response check. A resolver can remember that an authoritative server supports cookies and then reject responses that lack the expected cookie information. That raises the bar for a forged answer, because predicting the transaction ID and port is no longer the only concern. The BIND behavior examined in the paper, however, stores cookie-compliance information for a limited period. When that state expires, there can be a window before a new compliant response re-establishes it in which a response without a valid cookie is accepted.
The important claim is conditional, not absolute. The paper reports that spoofed responses issued while the resolver still enforced the remembered cookie requirement failed in its tests. After the relevant compliance state expired, the same general technique succeeded in the tested setup across the reported iterations. That does not mean cookies never help. They introduce a real validation condition and can prevent the attempt during part of the lifecycle. It means the paper did not find them to be a durable defense against the underlying predictable generator in the BIND configurations it tested.
Prefetching changes a different part of resolver behavior. A resolver may refresh a frequently used record before its time-to-live expires so that clients receive a warm answer. This can complicate attacks that depend on predicting exactly when a particular record will be queried again. The study’s attack targets the name-server delegation instead. Once that delegation is poisoned, later refreshes for records below it are directed to the malicious authority. Prefetching therefore continues to operate, but it operates along the poisoned path. A performance feature can preserve freshness without restoring the correctness of the authority from which the answer is refreshed.
Neither example should be reduced to “defenses failed.” Cookies and prefetching address legitimate concerns at different layers. Cookies can add a server-specific check when an authoritative server is known to be compliant; prefetching can reduce latency and avoid expiration stalls. Their limits arise because neither replaces the resolver’s source of unpredictable query parameters, and neither independently guarantees that every authoritative server participates or that every later lookup follows an unpoisoned delegation. The patch must address the shared generator; the other features should be assessed for the separate conditions they improve.
The version matrix and these feature interactions also explain why a single headline can mislead. “BIND is vulnerable” identifies the affected product family and the advisory’s scope, but it does not tell an operator which observation path is relevant, whether the deployment uses a forwarder, how its threading and port behavior align with the paper’s model, or which response checks apply. Conversely, “the network uses QNAME minimization” or “the resolver supports cookies” is not enough to conclude that the vulnerable implementation is protected. Security comes from the whole transition chain, not from the presence of one feature name.
The practical conclusion is consequently disciplined. State inference supplies foresight; a prediction must be aligned with a pending query; a forged response must win a race and pass the resolver’s checks; and only then can a false delegation persist in the cache. BIND 9.18, 9.20, 9.21, and forwarder deployments expose different observation paths because their roles and internal scheduling differ. The next task is to judge the evidence behind these claims: which results were measured, under what conditions, and where the authors deliberately stopped short of claiming universal compromise.