CVE-2026-5950 — unbounded resend loop in the BIND 9 resolver: why DNS resilience is more than just a patch in the update wave

TL;DR — the 90-second summary

A classic resolver resource exhaustion with a clear patch path — and a good occasion to look at the DNS layer in the platform architecture the same way we look at web servers and container hosts.

What is the problem? — the “bad server” path in the resolver state machine

A recursive resolver has to deal with unreliable upstream name servers — that is normal operation. CVE-2026-5950 sits in the logic that handles exactly this reality.

The bug in resolver logic

A recursive DNS resolver has to deal with the reality that upstream name servers respond badly — delayed, with incomplete answers, with truncation flags, with server-side errors. BIND has a “bad server” handler for this that detects when a particular upstream NS is unreliable and adapts the strategy (choose another NS from the NS set, retry with another transport, etc.).

The bug: in a certain constellation of “bad server” handling, the resolver state machine enters a retry loop with no built-in exit criterion — the only exit path is the global query timeout (typically 10 seconds, in defensive setups up to 30 seconds). During that time the loop holds a resolver worker slot, writes log entries, sends further queries to the upstream NS marked “bad”, and processes no new client request.

An attacker who supplies the right sequence of prepared responses (or controlled authoritative NS responses under their own domain) can trigger this path on purpose. With enough parallel queries against the same resolver, the worker slots get exhausted, and the resolver is effectively DoS'd.

Who is affected?

Most important distinction: recursive vs. authoritative configuration. The second is not affected, the first is. The rest is version inventory.

Impact

DNS outage affects more than just “the website does not load”. Three consequences that belong in the situation assessment.

DNS outage as a platform domino. A non-responding DNS resolver has consequences far beyond “the website does not load”: TLS certificate refresh (Let's Encrypt ACME path), software updates (apt/dnf/Wolfi-apk), container image pulls (registry hostname resolution), service discovery in microservice architectures, mail delivery (SPF/DKIM/DMARC lookup), backend calls to external APIs. Anyone running only a single BIND recursor in the internal office network has, in the worst case, a partial outage of platform operations.

Is the query timeout window enough? Yes — and no. Yes in the sense that the loop does not run forever (query timeout breaks it); no in the sense that with enough parallel queries the loop consumes worker slots and slot exhaustion occurs faster than the timeouts take effect. For a typical Mittelstand recursor with 50–200 parallel slots, a few hundred trigger queries per second are enough to effectively cripple the resolver.

Logging avalanche. While the loop runs, BIND usually writes log entries — which under an exploited bug can lead to disk-IO avalanches. Anyone without log rate limit or log rotation sanity check gets a secondary effect on the logging backend.

Mitigation / immediate measures

Three tracks: distribution update, container rebuild, defence in depth without a configuration knob.

Path 1 — distribution package update

# Debian 13 / Ubuntu 24.04:
apt update && apt install --only-upgrade bind9 bind9-utils
named -v   # 9.18.49 expected once backport is in the repo

# RHEL 9 / Rocky / Alma:
dnf upgrade bind bind-utils
named -v

# Fedora 43+:
dnf upgrade bind
named -v

# Wolfi:
apk update && apk upgrade bind

Distribution backports usually take a few days after the ISC release. As of 21 May 2026: ISC release was 20 May, Debian/Ubuntu/RHEL packages should be in the standard repo between 22 and 26 May. For faster turnaround, fall back to the ISC source tarball or activate distribution-specific proposed-updates repos.

Path 2 — containerised BIND setups

# Image rebuild against the updated Wolfi / Alpine / Debian package
# Example Dockerfile (Wolfi base):
docker build --pull -t my-recursor:bind-9.18.49 -<<'EOF'
FROM cgr.dev/chainguard/wolfi-base:latest
RUN apk add --no-cache bind
COPY named.conf /etc/bind/named.conf
EXPOSE 53/udp 53/tcp
ENTRYPOINT ["/usr/sbin/named","-g","-c","/etc/bind/named.conf"]
EOF

# Then a rolling restart via Kubernetes:
kubectl -n dns rollout restart deployment/bind-recursor

Path 3 — no workaround, but defence in depth

There is no configuration knob that blocks the resend loop — the fix sits in the state-machine code. What you can do actively in the meantime:

• Run multiple resolvers redundantly: if you only have one internal BIND recursor, that is a bad architecture anyway. A second resolver instance (preferably with a different implementation — Unbound or PowerDNS Recursor as failover) is the robust answer to any resolver DoS situation, not just this one.
• Query volume telemetry: if your resolver's outgoing query rate against a single upstream NS spikes, that is an indicator. The Prometheus exporter for BIND (bind_exporter) provides the metrics.
• Resolver cache TTL hygiene: a well-warmed cache buffers temporary resolver outages. Anyone running the cache aggressively short is faster in the hole in a DoS event.

Detection / verification

Version inventory, retry telemetry, log patterns — in that order.

Version inventory

# On every host with BIND:
named -v
# Expected: BIND 9.18.49 / 9.20.23 / 9.21.22 (or higher)

# Through inventory:
ansible all -m shell -a 'named -v 2>&1' | grep -E '9\.(18|20|21)\.'

Resolver telemetry on retry bursts

# BIND own statistics interface:
rndc stats
cat /var/cache/bind/named.stats | grep -E 'resolver|query'

# Prometheus bind_exporter — key metrics:
#   bind_resolver_queries_total{type=...}
#   bind_resolver_retries_total{type=...}
#   bind_resolver_query_duration_seconds{quantile="0.99"}

Suspicion pattern: a strong rise in bind_resolver_retries_total while bind_resolver_queries_total stays nearly unchanged (internal retry traffic without matching client load). That is exactly the effect the unbounded loop produces.

Log anomalies

# named.log for repeat patterns against a single upstream NS:
grep -E 'lame server|FORMERR|SERVFAIL' /var/log/named/named.log \
  | awk '{print $NF}' | sort | uniq -c | sort -nr | head -20

Operator recommendation

Operational decision block

• Mitigate immediately if: you operate a publicly reachable recursive BIND resolver (mail provider, ISP-like role, hosting provider with customer DNS) — the attack surface is open
• A maintenance window is fine if: you run an internal BIND recursor in an office / datacenter network that is not directly reachable — standard update rollout in the weekly window
• Backlog is enough if: BIND runs authoritative-only (no recursion path configured) — authoritative services are explicitly not affected

Mittelstand

Wait for the distribution backport (expected in the next 3–5 days), regular patch run in next week's maintenance window. In parallel, look at the DNS resilience question: who still runs exactly one recursor with a single implementation today? A second recursor in a different implementation (BIND + Unbound, or BIND + PowerDNS Recursor) is a small increase in complexity for a significant resilience gain. We recommend this for new setups, and this advisory is a good occasion to raise the question in existing environments.

Enterprise

Evaluate resolver telemetry on retry trajectories per upstream NS and hook it in as anomaly detection. For critical DNS paths, enforce anycast DNS and multi-implementation as default architecture. Run the update wave through the usual pre-patch validation pipeline — BIND is a component where “just update” works without friction in most cases, but subscription lines (BIND 9 Supported) often require their own test steps.

Kubernetes

If CoreDNS forwards to an external BIND recursor (forward . 10.x.x.x in the Corefile): patch the backend recursor. CoreDNS itself is not affected. For cluster-internal recursors as sidecar / DaemonSet, pin the image tag and update against the patch wave.

Declarative stacks

Plan a NixOS/Talos/Flatcar module update against the new BIND versions; for NixOS flakes typically within days in the unstable channel, in the stable channel in the next backport run.

What we do

A preliminary note on our own situation: BIND is not the central DNS layer in our own platform — service resolution in the Kubernetes clusters and application containers sits on CoreDNS, which forwards external lookups to an upstream resolver service (provider resolver or our own recursor instance, depending on the setup). Where BIND runs as a recursive resolver, this CVE situation applies directly; where another implementation (Unbound, PowerDNS Recursor) serves the path, it does not.

How we approach the situation operationally — as a working pattern, not as a report of completed measures:

1. Version inventory: reconcile hosts with bind9 / bind in the package index against the affected branch ranges (9.18.36–9.18.48, 9.20.8–9.20.22, 9.21.7–9.21.21). Distribution stable packages are the default line in most existing environments and therefore within the affected range; in mixed-mode setups (authoritative + recursive) the recursive part is affected.
2. Arm the patch pipeline: as soon as the distribution backports are available (expected between 22 and 26 May), the update runs through at platforms under our care in the respective maintenance window — like any other distribution CVE update. Subscription lines (BIND 9 Supported) often need their own test steps; that is planned in.
3. Resolver telemetry: where bind_exporter metrics are missing or incomplete in the Prometheus view, this is the occasion to complete the view — not as a mandatory update for this CVE, but because a resolver DoS without telemetry only becomes visible as a follow-on damage, not as a cause.
4. Architecture question: where we see only a single internal BIND resolver today, the CVE is a good occasion for an architecture note recommending running a second resolver in an alternative implementation (Unbound or PowerDNS Recursor) in parallel. That is not a consequence of this specific CVE, but a general resilience recommendation.
5. Logging sanity check: check BIND log rotation against disk-IO avalanches, before an exploited resend loop drags the logging backend along as a secondary effect. logrotate.d/named with a short interval plus compress is the robust default configuration.

A substantive observation: DNS resilience is a layer that in the Mittelstand is often booked as “it just runs, it is just there” — until it no longer runs. CVE-2026-5950 is not spectacular, but it is a good occasion to look at the DNS layer the way we look at web servers, container hosts, and CMS stacks: with versioning, telemetry, redundancy, recovery path.

Bottom line

CVE-2026-5950 is not the most spectacular DNS advisory of the year, and that is fine — no RCE, no data leak, no active exploitation in circulation. It is a classic resource-exhaustion bug in a code path BIND has maintained stably for years, and ISC has cleanly delivered patches in three version lines. Anyone running a BIND recursor runs the update wave in the normal maintenance window over the next few days and is done.

What we should take away from the CVE beyond merely patching: DNS is an infrastructure layer with platform-wide domino effects. A non-responding resolver cripples more than just “one website not loading”. The question whether the DNS layer in your platform architecture enjoys the same resilience discipline as the web server or the container host — redundancy, multi-implementation, telemetry, recovery path — is not triggered by this advisory but merely surfaced by it. The answer can vary considerably depending on platform size and risk profile. What matters: that the question is asked before the next advisory lands in a path that is more critical for you.