BIND’s October Fixes Reach Signed DNS and Resolver Policy
Signing a DNS message does not make every later use of that message safe. ISC’s October BIND advisories describe a replay route involving previously authenticated traffic, alongside two separate ways that particular resolver configurations can stop the service. The common update does not make their exposure conditions interchangeable.
ISC publicly disclosed the three High-rated issues on 21 October, following early notification on 14 October. The useful question for an operator is which serving instances combine an affected release with the relevant traffic or policy settings, and which supported correction will actually reach them.
The signed-message path needs captured traffic
CVE-2026-94300 concerns GSS-TSIG-signed messages sent over UDP. An attacker must be able to capture an earlier signed message and replay it while its negotiated TSIG key remains valid. ISC says that combining this with crafted queries involving a zone controlled by the attacker may permit remote code execution. Memory corruption can also abort named, the BIND server process. ISC assigns a CVSS 3.1 score of 8.1.
Those prerequisites matter when investigating a deployment. An unauthenticated network severity metric does not erase the need for captured signed traffic and the still-valid key. Equally, a service crash does not itself demonstrate that code ran. Review the relevant message paths and evidence before deciding which outcome occurred.
Two resolver settings create different failure paths
CVE-2026-96888 affects a resolver configured with both a redirect zone and qname-minimization strict. Processing a redirect can trigger an assertion failure and terminate the process, potentially denying DNS service. ISC rates this issue 7.5, High. Finding either setting alone does not establish the documented combination.
CVE-2026-97313 also has a 7.5 High rating, but concerns response-policy zones, or RPZs. The server must permit recursive queries and have at least two such zones: one using the default recursive-only yes, another using recursive-only no. A query requesting recursion, RD=1, followed by a non-recursive query, RD=0, can cause an assertion failure and unexpected exit.
An inventory entry saying “DNS server” will not resolve either question. Check the running instance’s actual role, configuration and permitted clients. Do not treat every authoritative server as a recursive resolver, or every resolver as having these policy combinations.
An affected older branch still needs a supported route
For the signed-message issue, ISC lists ordinary BIND versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.29 and 9.21.0 through 9.21.26. The two resolver issues start their ordinary affected history at 9.16.0 and share the same upper boundaries. The Supported Preview Edition ranges differ too: the redirect issue starts at 9.16.8-S1, while the other two start at 9.11.3-S1; all extend through 9.18.50-S1 and also cover 9.20.9-S1 through 9.20.29-S1.
All three advisories list 9.20.30 and 9.21.27 as corrected releases, plus 9.20.30-S1 for the Supported Preview Edition available to eligible ISC support customers. They do not name a corrected 9.18 release. An affected-version table can include older software without promising a new upstream patch for its branch.
Match that information to the software actually supplied to the asset. A distribution can provide a backported fix under its own package revision, so use that supplier’s security notice and package evidence. Neither an upstream fix announcement nor a downloaded package proves that every serving process has changed.
Keep recovery and investigation separate
Each advisory says no workaround is known and that ISC is not aware of active exploits. These are the vendor’s stated limits, not proof that exploitation is impossible or that a particular installation is clean. Do not substitute an improvised configuration change for the supported fix on the strength of this report.
Plan authorised maintenance around the affected service and retain a recoverable configuration. After updating, verify the running build on each instance, including standby systems, and exercise its legitimate DNS functions and relevant policy paths. Keep the GSS-TSIG controls intact; weakening authentication to avoid a signed-message problem would create another exposure.
Record the correction, the configuration conditions found and any remaining unsupported systems. Investigate earlier unexplained crashes independently of the upgrade result. A successful service restart is evidence of availability at that moment, rather than a conclusion about earlier access.
Primary sources: ISC’s advisories for signed-message replay, redirect processing and response-policy query handling.
