CVE-2026-5950 — Unbounded Resend Loop im BIND-9-Resolver: warum DNS-Resilienz mehr ist als nur ein Patch in der Update-Welle

TL;DR — die 90-Sekunden-Zusammenfassung

Eine klassische Resolver-Resource-Exhaustion mit klarem Patch-Pfad — und ein guter Anlass, die DNS-Schicht in der Plattform-Architektur einmal so anzuschauen wie wir Webserver und Container-Hosts anschauen.

Was ist das Problem? — der „bad server“-Pfad im Resolver-State-Machine

Ein rekursiver Resolver muss mit unzuverlässigen Upstream-Nameservern umgehen — das ist normaler Betrieb. CVE-2026-5950 sitzt in der Logik, die genau diese Realität behandelt.

Der Bug in der Resolver-Logik

Ein rekursiver DNS-Resolver muss mit der Realität umgehen, dass Upstream-Nameserver schlecht antworten — verzögert, mit unvollständigen Antworten, mit Truncation-Flags, mit serverseitigen Fehlern. BIND hat dafür einen „bad server“-Handler, der erkennt, dass ein bestimmter Upstream-NS unzuverlässig ist, und die Strategie anpasst (anderen NS aus dem NS-Set wählen, Retry mit anderem Transport, etc.).

Der Fehler: in einer bestimmten Konstellation der „bad server“-Behandlung kommt der Resolver-State-Machine in eine Wiederholungs-Schleife, die kein eingebautes Abbruch-Kriterium hat — der einzige Exit-Pfad ist der globale Query-Timeout (typisch 10 Sekunden, in defensiven Setups bis 30 Sekunden). Während dieser Zeit hält die Schleife eine Resolver-Worker-Slot, schreibt Log-Einträge, sendet weitere Queries an den als „bad“ markierten Upstream-NS, und verarbeitet keine neue Client-Anfrage.

Ein Angreifer, der die richtige Sequenz aus präparierten Antworten (oder kontrollierten autoritativen NS-Antworten unter eigener Domain) liefert, kann gezielt den Pfad triggern. Bei genug parallelen Queries gegen denselben Resolver erschöpfen sich die Worker-Slots, und der Resolver ist effektiv DoS-frequent.

Wer ist betroffen?

Wichtigste Unterscheidung: rekursive vs. autoritative Konfiguration. Die zweite ist nicht betroffen, die erste schon. Der Rest ist Versions-Inventur.

Auswirkungen

DNS-Stillstand betrifft mehr als nur „die Website lädt nicht“. Drei Folgewirkungen, die in der Lage-Einschätzung mitgedacht gehören.

DNS-Stillstand als Plattform-Domino. Ein nicht-antwortender DNS-Resolver hat Folgewirkungen weit über „die Website lädt nicht“: TLS-Zertifikats-Refresh (Let's-Encrypt-ACME-Pfad), Software-Updates (apt/dnf/Wolfi-apk), Container-Image-Pulls (Registry-Hostname-Auflösung), Service-Discovery in Microservice-Architekturen, Mail-Versand (SPF/DKIM/DMARC-Lookup), Backend-Aufrufe an externe APIs. Wer im internen Office-Netz nur einen BIND-Recursor hat, hat im Worst Case einen Teil-Stillstand der Plattform-Operationalität.

Reicht das Query-Timeout-Window? Ja — und nein. Ja im Sinne, dass die Schleife nicht ewig läuft (Query-Timeout greift); nein im Sinne, dass die Schleife bei genug Parallel-Queries Worker-Slots verbraucht und die Slot-Erschöpfung schneller eintritt, als die Timeouts greifen. Bei einem typischen Mittelstand-Recursor mit 50–200 parallelen Slots reichen ein paar Hundert Trigger-Queries pro Sekunde aus, um den Resolver effektiv lahmzulegen.

Logging-Lawine. Während die Schleife läuft, schreibt BIND in der Regel Log-Einträge — was bei einem ausgenutzten Bug zu Disk-IO-Lawinen führen kann. Wer keinen Log-Ratelimit oder Log-Rotation-Sanity-Check hat, bekommt einen sekundären Effekt auf das Logging-Backend.

Mitigation / Sofortmaßnahmen

Drei Spuren: Distribution-Update, Container-Rebuild, Defense-in-Depth ohne Konfigurations-Knopf.

Pfad 1 — Distribution-Paket-Update

# Debian 13 / Ubuntu 24.04:
apt update && apt install --only-upgrade bind9 bind9-utils
named -v   # 9.18.49 erwartet, sobald Backport im 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 brauchen üblicherweise ein paar Tage nach ISC-Release. Stand 21.05.2026: ISC-Release vom 20.05., Debian/Ubuntu/RHEL-Pakete sollten zwischen 22.05. und 26.05. im Standard-Repo sein. Wer schneller will, kann auf den ISC-Source-Tarball zurückgreifen oder Distribution-spezifische proposed-updates-Repos aktivieren.

Pfad 2 — Containerisierte BIND-Setups

# Image-Rebuild gegen das aktualisierte Wolfi/Alpine/Debian-Paket
# Beispiel-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

# Anschliessend rollender Restart über Kubernetes:
kubectl -n dns rollout restart deployment/bind-recursor

Pfad 3 — Kein Workaround, aber Defense-in-Depth

Es gibt keinen Konfigurations-Knopf, der die Resend-Schleife blockt — der Fix sitzt im State-Machine-Code. Was Sie in der Zwischenzeit aktiv tun können:

• Mehrere Resolver redundant betreiben: Wenn Sie nur einen internen BIND-Recursor haben, ist das ohnehin eine schlechte Architektur. Eine zweite Resolver-Instanz (gerne mit anderer Implementierung — Unbound oder PowerDNS Recursor als Failover) ist die belastbare Antwort auf jede Resolver-DoS-Lage, nicht nur auf diese.
• Query-Volume-Telemetrie: Wenn die Outgoing-Query-Rate Ihres Resolvers gegen einen einzelnen Upstream-NS sprunghaft steigt, ist das ein Indikator. Prometheus-Exporter für BIND (bind_exporter) liefert die Metriken.
• Resolver-Cache-TTL-Hygiene: Ein gut gewärmter Cache puffert temporäre Resolver-Ausfälle. Wer den Cache aggressiv kurz konfiguriert hat, ist im DoS-Fall schneller im Loch.

Detection / Prüfung

Versions-Inventur, Retry-Telemetrie, Log-Pattern — in dieser Reihenfolge.

Versions-Inventur

# Auf jedem Host mit BIND:
named -v
# Erwartet: BIND 9.18.49 / 9.20.23 / 9.21.22 (oder höher)

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

Resolver-Telemetrie auf Retry-Bursts

# BIND eigene Statistik-Schnittstelle:
rndc stats
cat /var/cache/bind/named.stats | grep -E 'resolver|query'

# Prometheus bind_exporter — Key-Metriken:
#   bind_resolver_queries_total{type=...}
#   bind_resolver_retries_total{type=...}
#   bind_resolver_query_duration_seconds{quantile="0.99"}

Verdachts-Pattern: starker Anstieg bei bind_resolver_retries_total bei gleichzeitig fast unverändertem bind_resolver_queries_total (interner Retry-Verkehr ohne entsprechende Client-Last). Das ist genau der Effekt, den die unbounded loop produziert.

Log-Anomalien

# named.log auf Wiederhol-Pattern gegen einzelne Upstream-NS:
grep -E 'lame server|FORMERR|SERVFAIL' /var/log/named/named.log \
  | awk '{print $NF}' | sort | uniq -c | sort -nr | head -20

Betreiberempfehlung

Operational Decision Block

• Sofort mitigieren, wenn: Sie einen öffentlich erreichbaren rekursiven BIND-Resolver betreiben (Mail-Provider, ISP-ähnliche Rolle, Hosting-Anbieter mit Customer-DNS) — die Angriffs-Oberfläche ist offen
• Wartungsfenster möglich, wenn: Sie einen internen BIND-Recursor im Office-/Datacenter-Netz haben, das nicht direkt erreichbar ist — Standard-Update-Roll-out im Wochenfenster
• Backlog reicht, wenn: BIND nur autoritativ läuft (kein recursion-Pfad konfiguriert) — autoritative Services sind explizit nicht betroffen

Mittelstand

Distribution-Backport abwarten (in den nächsten 3–5 Tagen erwartet), regulärer Patch-Lauf im Wartungsfenster der kommenden Woche. Parallel die DNS-Resilienz-Frage anschauen: Wer fährt heute noch genau einen Recursor mit einer einzigen Implementierung? Ein zweiter Recursor in einer anderen Implementierung (BIND + Unbound, oder BIND + PowerDNS-Recursor) ist eine geringe Mehrkomplexität für einen erheblichen Resilienz-Gewinn. Wir empfehlen das bei Neu-Aufsetzen, und dieses Advisory ist ein guter Anlass, die Frage in Bestandsumgebungen einmal aufzulegen.

Enterprise

Resolver-Telemetrie auf Retry-Verläufe pro Upstream-NS auswerten und als Anomalie-Detektion einhängen. Bei kritischen DNS-Pfaden Anycast-DNS und Multi-Implementation als Default-Architektur durchsetzen. Update-Welle in der gewohnten Pre-Patch-Validierungs-Pipeline durchfahren — BIND ist eine Komponente, bei der „einfach updaten“ in den meisten Fällen ohne Reibung läuft, aber Subscription-Linien (BIND 9 Supported) verlangen oft eigene Test-Schritte.

Kubernetes

Wenn CoreDNS auf einen externen BIND-Recursor forwarded (forward . 10.x.x.x im Corefile): den Backend-Recursor patchen. CoreDNS selbst ist nicht betroffen. Bei Cluster-internen Recursors als Sidecar/DaemonSet das Image-Tag pinnen und gegen die Patch-Welle aktualisieren.

Deklarative Stacks

NixOS/Talos/Flatcar-Module-Update gegen die neuen BIND-Versionen einplanen; bei NixOS-Flakes typischerweise innerhalb von Tagen im unstable-Channel, im stable-Channel im nächsten Backport-Lauf.

Was wir tun

Eine Vorbemerkung zur Lage bei uns selbst: BIND ist in unserer eigenen Plattform nicht die zentrale DNS-Schicht — die Service-Auflösung in den Kubernetes-Clustern und Application-Containern hängt an CoreDNS, das für externe Auflösung typischerweise auf einen vorgelagerten Resolver-Dienst (Provider-Resolver oder eine eigene Recursor-Instanz, je nach Setup) forwarded. Wo BIND als rekursiver Resolver läuft, betrifft die CVE-Lage unmittelbar; wo eine andere Implementierung (Unbound, PowerDNS-Recursor) den Pfad bedient, gilt sie nicht.

Wie wir die Lage operativ angehen — als Vorgehensraster, nicht als Bericht abgeschlossener Maßnahmen:

1. Versions-Inventur: Hosts mit bind9 / bind im Paket-Index gegen die betroffenen Strangbereiche (9.18.36–9.18.48, 9.20.8–9.20.22, 9.21.7–9.21.21) abgleichen. Distribution-Stable-Pakete sind in den meisten Bestandsumgebungen die Default-Linie und damit innerhalb der Affected-Range; bei Mixed-Mode-Setups (autoritativ + rekursiv) ist der rekursive Anteil betroffen.
2. Patch-Pipeline scharfstellen: sobald die Distribution-Backports verfügbar sind (erwartet zwischen 22.05. und 26.05.), läuft das Update bei Plattformen unter unserer Pflege im jeweiligen Wartungsfenster durch — wie bei jedem anderen Distribution-CVE-Update. Subscription-Linien (BIND 9 Supported) brauchen oft eigene Test-Schritte; das ist eingeplant.
3. Resolver-Telemetrie: wo bind_exporter-Metriken nicht oder unvollständig in der Prometheus-Sicht stehen, ist das jetzt der Anlass, die Sicht zu vervollständigen — nicht als Pflicht-Update wegen dieser CVE, sondern weil ein Resolver-DoS ohne Telemetrie nur als Folgeschaden sichtbar wird, nicht als Ursache.
4. Architektur-Frage: dort, wo wir heute nur einen einzelnen internen BIND-Resolver sehen, ist die CVE ein guter Anlass für eine Architektur-Notiz mit der Empfehlung, einen zweiten Resolver in einer alternativen Implementierung (Unbound oder PowerDNS-Recursor) parallel zu fahren. Das ist keine Folge dieser konkreten CVE, sondern eine generelle Resilienz-Empfehlung.
5. Logging-Sanity-Check: BIND-Log-Rotation gegen Disk-IO-Lawinen prüfen, bevor ein ausgenutzter Resend-Loop sekundär das Logging-Backend mitreisst. logrotate.d/named mit kurzem Intervall plus compress ist die belastbare Default-Konfiguration.

Eine inhaltliche Beobachtung: DNS-Resilienz ist eine Schicht, die im Mittelstand häufig auf „läuft halt, ist halt da“ verbucht wird — bis sie nicht mehr läuft. CVE-2026-5950 ist nicht spektakulär, aber sie ist ein guter Anlass, die DNS-Schicht einmal so anzuschauen, wie wir Webserver, Container-Hosts und CMS-Stacks anschauen: mit Versionierung, Telemetrie, Redundanz, Recovery-Pfad.

Fazit

CVE-2026-5950 ist nicht das spektakulärste DNS-Advisory des Jahres, und das ist gut so — kein RCE, kein Datenleck, keine aktive Ausnutzung im Umlauf. Es ist ein klassischer Resource-Exhaustion-Bug in einem Code-Pfad, den BIND seit Jahren stabil pflegt, und ISC hat sauber Patches in drei Versions-Linien geliefert. Wer einen BIND-Recursor betreibt, fährt die Update-Welle im normalen Wartungsfenster der nächsten Tage und ist fertig.

Was wir aus der CVE mitnehmen sollten — über das reine Patchen hinaus: DNS ist eine Infrastruktur-Schicht mit Plattform-weitem Domino-Effekt. Ein nicht-antwortender Resolver legt mehr lahm als nur „eine Website lädt nicht“. Die Frage, ob die DNS-Schicht in Ihrer Plattform-Architektur die gleiche Resilienz-Disziplin geniesst wie der Webserver oder der Container-Host — Redundanz, Multi-Implementation, Telemetrie, Recovery-Pfad — ist nicht durch dieses Advisory ausgelöst, sondern davon nur einmal in den Blick gerückt. Die Antwort kann sehr unterschiedlich ausfallen, je nach Plattform-Grösse und Risiko-Profil. Worauf es ankommt: dass die Frage gestellt wird, bevor das nächste Advisory in einem für Sie kritischeren Pfad landet.