DNS is the service you set up once, confirmed it worked, and never thought about again. That is exactly why ISC's October 21 disclosure matters: four fresh vulnerabilities in BIND 9, the reference implementation that still underpins an enormous slice of the internet's name resolution. One of them — CVE-2026-94300 — is a memory-corruption flaw that ISC says "may potentially achieve remote code execution." It was independently discovered and responsibly reported by Dave Aitel of OpenAI. The other three are denial-of-service bugs, but do not let the word "just" sneak in there: a dead resolver means every name lookup behind it fails, and that takes your mail, your SSO, and your outbound connectivity down with it.

Here is the quick triage table before we get to the drill:

| CVE | CVSS | What it does | Who is exposed | | --- | --- | --- | --- | | CVE-2026-94300 | 8.1 | Replaying GSS-TSIG signed UDP messages corrupts memory; potential RCE | Servers using GSS-TSIG (common in Kerberos/AD-integrated dynamic updates) | | CVE-2026-19630 | 7.5 | Malicious DNS messages with a huge number of crafted structures burn CPU and memory | Any resolver, no special config needed | | CVE-2026-97313 | 7.5 | Named exits on certain query patterns | Recursive servers with two RPZ zones using different recursive-only settings | | CVE-2026-96888 | 7.5 | Assertion failure aborts the server | Resolvers with a redirect zone plus strict QNAME minimization |

All four hit BIND 9.11.0–9.18.50, 9.20.0–9.20.29, and 9.21.0–9.21.26. ISC states it is not aware of any active exploits. There is also no workaround for any of them — patching is the only path.

The upgrade drill

Step 1: Find your BIND. On any machine that answers DNS, run named -v. If the answer starts with 9.18, 9.20, or 9.21, keep reading. Also check the package route — dpkg -l | grep bind9 on Debian/Ubuntu, rpm -qa | grep bind on RHEL-family — because the fix arrives through your distro's security repositories, not from ISC's tarballs.

Step 2: Map yourself to the table. The GSS-TSIG flaw (CVE-2026-94300) is the scariest but also the most conditional: the attacker must capture a previously signed message and replay it while the negotiated TSIG key is still valid. If you do not use GSS-TSIG at all, you are not in its blast radius. CVE-2026-19630, on the other hand, needs nothing special — any resolver will chew through CPU and memory on a crafted message. Most self-hosted setups (Pi-hole front ends, homelab resolvers, small authoritative servers) fall into this second camp.

Step 3: Mind the 9.18 trap. This is the detail most people will miss. ISC's fixed releases are 9.20.30 and 9.21.27 (plus 9.20.30-S1 for preview customers). There is no fixed release for the 9.18 branch. If you are still on 9.18 — and many stable server distros ship it — you cannot patch your way out; you need to plan a branch migration. Treat that as a scheduled change, not an emergency one, but put it on the calendar now rather than after the next disclosure.

Step 4: Upgrade and restart named. Pull the update from your distro (apt upgrade bind9, dnf update bind — check your distro's security advisory first, since ISC's release and distro packages land at different times), then restart the service. Unlike a kernel patch, this does not require a reboot — but restarting is not optional, and neither is confirming it: systemctl status named or rndc status should show the new version string. An upgraded package with an un-restarted daemon is just a vulnerability wearing a patched costume.

Step 5: Watch for the earliest signal. Unexpected named restarts and latency spikes are the first observable signs of resource-consumption and crash attacks against resolvers. If you have any monitoring at all — even a simple process check — make sure named is in it. The crash flaws are remotely triggerable with no credentials, so "nobody is attacking us" is not a defense.

Step 6: Harden while you are in there. Since you are already touching the config: restrict recursion to known client networks, require TSIG for zone transfers, disable dynamic updates where they are not needed, and audit those RPZ and redirect-zone settings that two of these CVEs specifically target. None of this replaces the patch, but it shrinks the attack surface for the next batch.

The uncomfortable takeaway

DNS security advisories do not get the attention kernel CVEs do, partly because named sits there silently doing its job for years at a time. That silence is the risk: the most dangerous server in your infrastructure is the one you forgot was infrastructure. October's batch is a good excuse to audit yours — find it, version it, and get it onto a supported branch before the disclosure that comes with an exploit in the wild.

Sources