A Patch Is the First Layer, Not the Whole Model

For BIND 9 operators, the immediate question is which release contains the fix for CVE-2025-40780. The broader question is what should surround that fix once the weak PRNG is no longer the only concern. This chapter separates root-cause remediation from independent DNS controls: the ISC patch changes the resolver’s source of unpredictable values, while DNSSEC, encrypted transport, access restrictions, protective DNS, logging, role separation, and resilience address different properties. That distinction supports a practical response without pretending that one security feature can compensate for every other failure.

The ISC fix addresses the shared generator first

The ISC advisory classifies CVE-2025-40780 as a high-severity, remotely exploitable BIND 9 cache-poisoning vulnerability caused by a weakness in the pseudo-random number generator. It says that an attacker may predict the source port and query ID BIND will use and that a successful spoof can make BIND cache attacker responses. The advisory assigns a CVSS score of 8.6 and says that no workaround is known.

That combination determines the order of action. An operator should first establish which BIND role is running, inventory the actual package and branch, and move an affected recursive or forwarding service to a release listed as fixed by ISC. A firewall rule, a DNS cookie, or an encrypted client connection may change exposure or make one step harder, but none of those is the vendor’s replacement for the vulnerable generator. If the root dependency remains predictable, the organization is still relying on a mechanism that the advisory has identified as unsafe.

ISC’s affected ranges in the advisory include BIND 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, and 9.21.0 through 9.21.12, along with corresponding Supported Preview Edition ranges. The same advisory lists 9.18.41, 9.20.15, and 9.21.14 as patched releases, plus preview builds for the supported preview branches. These numbers belong to the advisory’s publication and release context. Operators should use the current ISC release information and their distribution’s security notices when making a live upgrade decision, rather than assuming that a branch label alone proves safety.

The research paper explains what changed under coordinated disclosure. ISC replaced Xoshiro128** with a more cryptographically secure alternative: arc4random() where available and uv_random() elsewhere. That is a root-cause fix because it changes the source from which BIND derives the security-relevant outputs. It is not merely a change to how the transaction ID is formatted or how a port is selected. The point is to remove the predictable shared state that allowed different observations to become evidence about future query parameters.

A separate change concerns RRset ordering. The paper says ISC acknowledged that rrset-order random was never intended to guarantee a uniform distribution, updated the documentation in later releases, and removed the random option beginning with BIND 9.21.14. This is related to the case because RRset ordering supplied an observation channel, but it is not the same remediation fact as replacing the weak PRNG. One change addresses predictability of shared security-relevant outputs; the other addresses the meaning and lifecycle of a configuration mode that did not promise uniform randomness.

Keeping those changes separate is more than editorial tidiness. It prevents two opposite mistakes. An operator might believe that removing or changing RRset ordering alone fixes the CVE, even though transaction IDs and source ports still need a safe generator. Or they might assume that a new generator makes every use of an ordering mode semantically uniform, which the paper does not establish.