ISC's BIND 9.20.29 patches 14 flaws, crash bugs included

ISC has published BIND 9.20.29 and 9.21.26 with 14 security fixes between them, a batch that lands heavily on DNSSEC validation and on remotely reachable crash paths in the resolver that runs a large share of the public DNS. The release notes for the extended-support 9.20 branch list 14 separate CVEs; the 9.21.26 changelog published on the same day lists 13 of the same set.

The validation flaws are the ones to watch

Six of the fixes harden DNSSEC validation. In CVE-2026-19668, a malicious authoritative server could publish a securely delegated zone whose DS and DNSKEY records carried many distinct key tags but no valid match, pushing a validating resolver into endless key-tag matching. That work is now bounded by the per-query max-validations-per-fetch limit. CVE-2026-77119 describes a downgrade: a resolver could be tricked into treating a secure delegation as unsigned and accepting forged answers beneath it, if an attacker could inject responses to its queries.

CVE-2026-19941 is the same family of problem in a different place. A signed NSEC record from an unrelated zone could be accepted as proof that a wildcard did not exist, letting an on-path attacker or a malicious forwarder forge an authenticated NXDOMAIN for a name that should have resolved. ISC now requires the wildcard-denial and name-nonexistence proofs to be signed by the same zone. A further crash, CVE-2026-19662, came from cached NOQNAME proof data being replaced while concurrent queries were still using it, and CVE-2026-80274 covers wildcard answers that arrived carrying both NSEC and NSEC3 proofs, where the resolver could cache one record and serve another.

Remote crashes, including an unauthenticated one

CVE-2026-77692 is the one to patch first if you are triaging by exposure: a crafted HTTPS query using SIG(0) as authentication could crash named if the client closed the connection before the signature was actually verified. No credentials, no prior access, just a query and a hang-up. CVE-2026-76163 is close behind, terminating named when a remote client sent a TKEY query and the configuration carried no global options statement. Packet abuse is covered too: CVE-2026-75029 fixes memory amplification from DNS messages that repeated the same SOA, CNAME or DNAME record, where name compression made the internal copies far larger than the wire data.

Cache exhaustion and authoritative answers

Two fixes deal with a resolver's cache as a weapon. CVE-2026-81736: a client allowed to recurse, paired with an attacker-controlled zone used to plant interlinked HTTPS or SVCB alias records, could force a resolver to assemble enormous additional sections and burn enough CPU to deny service to everyone else. CVE-2026-81563 leaked cache memory instead, pinning alias target records permanently once a target passed 13 records, letting a remote party grow the cache past max-cache-size until unrelated names stopped resolving.

On the authoritative side, CVE-2026-19033 closes a gap in zone transfers: named used to accept TSIG-signed AXFR or IXFR transfers in which individual messages were unsigned, and processed those messages before the next signature could vouch for them. Every message of an incoming transfer now needs its own TSIG, which ISC notes all modern nameservers already do. CVE-2026-78301 fixes a stranger problem, where a zone database holding records for names outside the zone, typically left behind by a secondary that accepted out-of-zone data from its primary, could have those records served as authoritative for names inside the zone.

ISC credits a long list of external researchers, including Zuyao Xu and Xiang Li of the All-in-One Security and Privacy Laboratory at Nankai University, Rintaro Kawasugi, Samy Medjahed (Ap4sh), Vitaly Simonovich, Henrique Pereira, Owais Lone (thesecguy) and hythyt. Two of the highest-value finds, the HTTPS alias CPU exhaustion and the out-of-zone authoritative answer, came from the same reporter.

Our opinion

A 14-CVE release is no longer a surprise from ISC. The organisation blogged in May about preparing users for more frequent BIND security updates, and this is what that policy looks like in practice: a quarterly-style batch where the interesting work sits in the validation logic rather than in the packet parser. Anyone still treating BIND patch days as a low-priority chore is one DNS outage away from learning the difference. The unauthenticated SIG(0) crash deserves attention on its own, because a resolver that dies and restarts is a resolver that briefly stops answering for everything downstream of it.

The DNSSEC fixes are the more consequential half, and not because any single one is a disaster. They are attacks that make a validating resolver lie while looking correct: a downgraded delegation, a forged NXDOMAIN, a denial record that was never verified. That class of bug is exactly what DNSSEC exists to prevent, which is why it is worth patching the same week it lands rather than at the next change window. Read the release notes before the changelog, mind your build flags, and remember that the 9.18 branch is already past end of life, so there is no third option hiding in the archives.