Skip to content
Hack Your WorldSoftware · Infrastructure · Home automation

Analysis

One DNS-over-HTTPS Request Can Crash BIND 9.20. First Check Whether You Serve DoH.

By Hack Your World · Published

A highlighted malformed request reaching and stopping a DNS resolver process
A malformed HTTPS request reaches a DNS resolver process while the surrounding network remains intact.

ISC has fixed a BIND vulnerability through which one unauthenticated DNS-over-HTTPS request can terminate named. The request needs a cryptographically invalid SIG(0) record followed by a prematurely closed transport connection. If it reaches an affected DoH listener, the process aborts.

CVE-2026-77692 affects BIND 9.20.0 through 9.20.27 and the 9.21 development releases through 9.21.25. ISC rates it High at 7.5, lists no workaround, and says it is not aware of active exploitation. The fixes are 9.20.29 and 9.21.26.

That warrants an update. It does not mean every BIND server on the Internet can be dropped with an HTTPS request.

The protocol in the headline defines the exposure

This failure is in the DNS-over-HTTPS path. BIND only accepts DoH when an http configuration is referenced by listen-on or listen-on-v6. The listener may use TLS directly, normally on port 443, or tls none when a reverse proxy handles HTTPS in front of it.

A conventional authoritative server answering DNS over UDP and TCP on port 53 does not become a DoH server merely because it runs an affected BIND release. The vulnerable request needs an HTTP path into named.

The reverse-proxy case is easy to miss. A host may not expose BIND’s HTTPS port publicly, yet a proxy can still forward /dns-query traffic to an unencrypted HTTP listener on a private interface. Looking only for named on port 443 can therefore produce a false sense of safety.

I would check the installed version and the effective configuration, including included files:

named -V
named-checkconf -px

In the canonical configuration, look for listen-on or listen-on-v6 statements containing http, then follow the referenced http and tls definitions. The -x option masks shared secrets, but the resulting configuration still contains operational details and should not be pasted into a public ticket.

Then check the network path. Confirm which addresses and ports are listening, what the reverse proxy forwards, and whether an access-control layer limits the endpoint. Configuration intent and reachable service are not always the same thing.

A crash is not code execution, but it is still an outage primitive

ISC describes the impact as abnormal termination and denial of service. The advisory does not claim data disclosure, authentication bypass, or remote code execution. Keeping that distinction intact prevents a useful patch notice from becoming another story about the Internet collapsing.

Availability still matters. A single malformed request is cheap to repeat. A service manager may restart named, but automatic restart converts a permanent outage into a loop of short outages; it does not remove the trigger. Load balancing and secondary resolvers help only if the attacker cannot reach and repeat the request against each backend.

The operational impact also depends on what the server does. Losing one node from a redundant public resolver pool is different from repeatedly crashing the only internal resolver used for logins, package installation, monitoring, and service discovery. DNS tends to reveal its dependency graph after it stops working.

Patch the package you actually run

ISC’s fixed upstream releases are 9.20.29 and 9.21.26, with 9.20.29-S1 for Supported Preview customers. Distribution packages may carry a security backport without adopting ISC’s complete version number, so the package maintainer’s advisory and changelog matter more than a simplistic string comparison.

BIND 9.18 is not listed as affected by this CVE. It also reached upstream end of life in June 2026. Those facts can coexist: this specific DoH crash is not a reason to claim 9.18 is vulnerable, and upstream end of life does not automatically mean a supported Debian or enterprise distribution has stopped maintaining its package. Check the party that actually supplies your updates.

For affected installations, I would stage the update as an availability change:

  1. Inventory every DoH listener and the proxy or load balancer in front of it.
  2. Confirm whether the vendor package contains the CVE fix.
  3. Update a redundant node first and test ordinary DNS, DoH, DNSSEC validation where applicable, logging, and health checks.
  4. Roll through the remaining nodes while preserving enough capacity to answer traffic.
  5. Verify the running process, not only the package database. A replaced binary does not help a daemon that was never restarted.
  6. Watch restart counters and DoH error rates for evidence that the request is already being attempted.

Removing an unused DoH listener can reduce exposure, but ISC still lists no workaround for an affected service that needs to keep serving DoH. Access controls and a reverse proxy can narrow who reaches it; they do not repair named.

The headline number here is one request. The useful question is whether that request has a route to your process. Answer that first, then patch the systems for which the answer is yes.

Sources