BIND 9 DoH Flaw Crashes DNS With a Single Request

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · production infrastructure for US and EU teams

The short answer

What ISC patched — and the one to watch

On September 16, the Internet Systems Consortium — the nonprofit that maintains BIND, the most widely deployed DNS server software on the internet — released BIND 9.20.29 and 9.21.26, closing 14 security flaws at once. Seven are rated high severity and seven medium. The high-severity group can be exploited remotely to trigger program crashes, memory exhaustion, or resource depletion, while the medium-severity issues include cache poisoning, CPU exhaustion, and injection of arbitrary data into DNS zones.

The standout is CVE-2026-77692, rated CVSS 7.5. It lets an unauthenticated remote attacker terminate the named daemon by sending a single DNS-over-HTTPS (DoH) request carrying a cryptographically invalid SIG(0) record, then abruptly closing the transport connection before validation completes. The result is a NULL pointer dereference that aborts the process — a clean denial of service with no login, no session, and no valid signature required. For internet-facing resolvers, that is close to the worst-case ratio of effort to impact.

ISC says it is not aware of any of the 14 vulnerabilities being exploited in the wild. That is reassuring but time-limited: the consortium also notes that tests reproducing the flaws are public, which sharply lowers the work an attacker needs to weaponize them. When a proof-of-concept path is already documented, "not yet exploited" is a scheduling detail, not a reason to defer the upgrade. Anyone running BIND should treat this as a same-week action and fold it into a disciplined security and patch routine.

Why DNS-over-HTTPS widened the attack surface

DNS-over-HTTPS was designed to improve privacy by wrapping DNS queries in encrypted HTTPS traffic, and its adoption across enterprise resolvers and public DNS providers has grown steadily. But every new transport a server speaks is new code that parses untrusted input, and CVE-2026-77692 lives precisely in that seam: the handling of SIG(0) transaction signatures over the DoH transport. The flaw is not in DNS resolution logic itself but in how the server manages a connection that is torn down mid-validation.

That pattern — a crash triggered by malformed input plus an early disconnect — is a recurring class of bug in network daemons, and it is exactly why input parsing on edge-facing services deserves extra scrutiny. If your resolvers expose DoH, they are reachable over ordinary HTTPS ports that firewalls typically leave open, so the "internal service" mental model does not protect you. The practical takeaway is to know which transports each DNS endpoint actually speaks, and to treat every one of them as an attack surface that needs patching and monitoring.

It also reinforces a design principle for any service that terminates untrusted connections: assume clients will misbehave, disconnect early, and send invalid data on purpose. Robust connection lifecycle handling — and crash-restart supervision as a backstop — is not gold-plating; it is the difference between a logged error and a company-wide outage.

What it means for US & EU teams

The first implication is a blast-radius problem. DNS is a dependency of almost everything: service discovery, API calls, email, certificate validation, and customer-facing traffic all assume resolution works. A crash in named does not fail one feature; it can cascade into timeouts across a whole platform. For teams in FinTech, HealthTech, or e-commerce, where uptime is contractual and downtime is measured in revenue and regulatory exposure, an unauthenticated DoS in DNS is a business-continuity issue, not just an ops ticket.

The second implication is about ownership. Many organizations do not know who patches their DNS. It may be a managed provider, a platform team, an appliance, or a container image nobody has rebuilt in months. This release is a good forcing function to answer a simple question: for every DNS resolver and authoritative server we depend on, who is accountable for applying BIND 9.20.29 or 9.21.26, and by when? Unclear ownership is how a documented, patchable flaw survives for months.

The third implication is resilience by default. Even after you patch, the next DNS bug will eventually arrive. Teams that run named under a process supervisor, spread resolution across redundant instances, apply rate limiting to DoH endpoints, and alert on repeated restarts will absorb the next crash-class flaw with a blip instead of an outage. That is the posture we build into every custom software platform: the critical services are supervised, redundant, and observable, so a single failure degrades gracefully rather than taking the system down.

What to do now

1. Inventory your BIND footprint. Find every recursive and authoritative server, including appliances and container images. You cannot patch what you have not located.
2. Upgrade to the fixed release. Move to BIND 9.20.29 or 9.21.26 (or 9.20.29-S1 for the Supported Preview Edition) on the branch you run. Confirm the running version after deployment, not just the package version.
3. Reduce DoH exposure. Restrict which clients can reach DNS-over-HTTPS endpoints, and put resolvers behind rate limiting and network controls so a flood of crafted requests cannot repeatedly crash the service.
4. Supervise and monitor named. Run it under systemd or an equivalent that restarts it automatically, and alert on repeated crashes rather than discovering them from a customer report.
5. Assign clear ownership. Name the team accountable for DNS patching and add BIND to the same review cadence as your application dependencies, so the next advisory is routine, not a fire drill.

Frequently asked questions

Sources

ISC — CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request
SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
The Hacker News — BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS