Zusammenfassung

  • ISC repariert laut eigener Richtlinie nur aktuell unterstützte, für den Produktivbetrieb empfohlene Produkte, und innerhalb eines Zweigs nur die jeweils neueste monatliche Version; Versionen am Ende des Lebenszyklus gelten als anfällig für neue CVEs.
  • Ein öffentlicher Hinweis wird ab einem CVSS-Wert von 7 ausgelöst; für mittlere Schweregrade zwischen 5 und 7 behält sich ISC vor, CVEs zu vergeben und Korrekturen nicht immer zurückzuportieren.
  • Debian trägt Reparaturen über die ISC-Grenze hinaus: Im September 2026 führt stable-security die Version 1:9.20.29-1deb13u1, während oldstable weiterhin die bereits eingestellte 9.18-Linie mit 1:9.18.49-1deb12u1 bedient.
  • Eine öffentliche Messung, welcher Anteil der betriebenen BIND-9-Server eine korrigierte Version ausführt, ließ sich nicht finden; der Bericht behauptet deshalb keine Verbreitungsquote.

Der Ablauf von der Meldung bis zur Reparatur ist bei BIND 9 kein einzelner Vorgang, sondern eine Kette mit drei dokumentierten Schwellen. Die erste ist die Lebensdauer eines Zweigs, die zweite der Schweregrad, ab dem ein Hinweis öffentlich wird, die dritte die Regel, dass nur die neueste monatliche Version eines Zweigs überhaupt Korrekturen erhält. Jede dieser Schwellen ist veröffentlicht, überprüfbar und vom Betreiber nicht beeinflussbar.

Vier Versionstypen, vier Jahre Laufzeit

In der Support-Richtlinie von ISC unterscheidet das Konsortium vier Arten von Hauptversionen: Development, Stable, Extended Support (ESV) und Supported Preview (-S). Geradzahlige Stable-Versionen werden demnach insgesamt vier Jahre unterstützt, grob zwölf Monate mit Funktions- und Fehlerkorrekturen, danach verlängerter Support und schließlich nur noch Korrekturen für Sicherheitslücken (Support-Lebensdauer-Richtlinie).

Diese Zeitrechnung lässt sich an konkreten Daten nachvollziehen: BIND 9.18 erschien im Januar 2022, wurde im Januar 2023 zur ESV-Version erklärt und war für Juni 2026 als Ende des Lebenszyklus vorgesehen; BIND 9.20 erschien im Juli 2024; BIND 9.16 wurde im März 2024 eingestellt, die letzte Ausgabe folgte im April 2024. Der nächste Stable-Zweig 9.22 wurde auf mindestens das vierte Quartal 2026 verschoben, in einem Blogbeitrag des Konsortiums sogar auf mindestens das Jahresende 2026, und dort ausdrücklich mit der Wirkung von LLM-Codeanalyse begründet, die eine historische Zahl potenzieller Schwachstellen finde.

ISC bezeichnet die eigene Veröffentlichungs- und Supportplanung zugleich als grobe Orientierung, nicht als Zusage. Das ist für Betreiber die wichtigste Einschränkung des gesamten Dokuments: Die Vier-Jahres-Rechnung ist ein Planungswert, kein Anspruch.

Was einen öffentlichen Hinweis auslöst

Die zweite Schwelle steht in der Richtlinie zur Offenlegung von Defekten und Schwachstellen: Ein öffentlicher Hinweis wird ab einem CVSS-Wert von 7 ausgelöst, also ab der Einstufung HIGH oder CRITICAL. ISC unterscheidet Typ I, wenn die Lücke nicht in freier Wildbahn ausgenutzt wird, und Typ II, wenn sie ausgenutzt wird oder bekannte Probleme verursacht (Offenlegungsrichtlinie).

Für Typ I erhalten Support-Kunden und OEM-Partner zwischen drei und fünf Arbeitstagen vorab eine formale Mitteilung und Vorabcode; sind autoritative Namensdienste betroffen, werden zusätzlich Root-Operatoren informiert. Paketbetreuer von Betriebssystemen erhalten bis zu vierundzwanzig Stunden Vorlauf. Die öffentliche Bekanntgabe folgt dann mit korrigierten Versionen aller aktuell unterstützten betroffenen Produkte. Für Typ II will ISC die korrigierende Version innerhalb von vierundzwanzig Stunden nach der Meldung veröffentlichen; eine vorherige Information der Paketbetreuer ist dabei nicht immer gewährleistet.

Die Richtlinie gilt ausdrücklich nur für aktuell unterstützte, für den Produktivbetrieb empfohlene Produkte und nur für die jeweils neueste monatliche Ausgabe einer Stable-Maintenance-Version. Sie erfasst keine Versionen am Ende des Lebenszyklus, keine Versionen am Ende der Wartung und keine Entwicklungsversionen, ebenso wenig Nicht-ISC-Abhängigkeiten, die in ISC-Paketen mitgeliefert werden. Wer eine eingestellte Version betreibt, besitzt damit keinen Anspruch auf eine Benachrichtigung und keinen Anspruch auf eine Korrektur.

Eine separate, kostenpflichtige Schiene verschiebt diese Grenze für zahlende Abonnenten: Der Dienst Early Vulnerability Notification ist im Software-Support-Abonnement enthalten und wird auch einzeln verkauft, erlaubt bis zu vier namentlich benannte Personen pro Abonnent und verlangt eine Vertraulichkeitsvereinbarung; benachrichtigt wird bis zu fünf Tage und mindestens drei Arbeitstage vor der öffentlichen Bekanntgabe (Early Vulnerability Notification).

Zur Art der Lücken macht ISC dort eine operative Angabe von Gewicht: Die meisten vom Konsortium selbst entdeckten BIND-9-Schwachstellen seien Wege, INSIST- oder ASSERT-Fehler auszulösen, die den Server beenden — ein wirksamer Denial-of-Service-Angriff. In manchen Fällen veröffentlicht der Melder selbst, und dann kann ISC die Offenlegung nicht mehr steuern.

Welcher Zweig überhaupt noch repariert wird

Die dritte Schwelle ist am einfachsten zu prüfen und am härtesten in der Wirkung. Die Schwachstellenmatrix zu BIND 9 ordnet jedem CVE die Version zu, die ihn behebt, und zeigt dabei nur aktuell unterstützte Stable-Zweige; ältere Zweige erhalten in der Regel keine Korrekturen und werden teilweise nicht einmal auf Schwachstellen geprüft (BIND-9-Schwachstellenmatrix).

In der abgerufenen Fassung ist BIND 9.18 als am Lebensende stehend ausgewiesen, 9.18.50 als letzte Ausgabe der Reihe, und für Versionen am Lebensende gilt die ausdrückliche Annahme, dass sie für neue CVEs anfällig sind. Die einzige im Auszug nicht eingestellte Zweigspalte ist 9.20, mit 9.20.29 vom 16. September 2026 als derzeit jüngster aufgeführter Korrekturversion. Unabhängig davon führt die community-gepflegte Lebenszyklusreferenz endoflife.date den Sicherheitssupport von 9.20 bis zum 8. Juli 2028, das Ende von 9.18 zum 30. Juni 2026 und das Ende von 9.16 zum 31. März 2024; Schwachstellen in Entwicklungszweigen werden dort als gewöhnliche Fehler ohne eigene CVE-Hinweise behandelt (endoflife.date zu BIND 9).

Wie sich der Reparaturbetrieb verdichtet hat, beschreibt ISC in einem Blogbeitrag vom 12. Mai 2026: Auf absehbare Zeit sei in jeder monatlichen BIND-Wartungsausgabe mit Sicherheitskorrekturen zu rechnen, was die frühere Praxis von ungefähr einem Sicherheitsrelease pro Quartal ersetzt (Änderung des Release-Rhythmus). Im selben Beitrag heißt es, man werde nicht zusätzlich ermitteln, welche Minor-Version ein Problem eingeführt hat, und Anwender sollten auf die neueste Wartungsversion ihres Zweigs aktualisieren. Zudem behält sich ISC vor, für mehr Schwachstellen mittlerer Schwere im CVSS-Bereich zwischen 5 und 7 CVEs zu vergeben und Korrekturen für mittelschwere CVEs nicht immer zurückzuportieren; die Schwelle für die Early Vulnerability Notice bleibt bei 7 und darüber.

Die praktische Folge: Wer auf einem Zweig bleibt, muss jede monatliche Ausgabe einspielen, weil einzelne Korrekturen nicht mehr gezielt einer Version zugeordnet werden. Wer den Zweig nicht mehr verlässt und nicht aktualisiert, verlässt zugleich den Kreis der Produkte, für die überhaupt Korrekturen vorgesehen sind.

Wer die verbleibende Arbeit erbt

Das Ende von BIND 9.18 ist in einem Blogbeitrag vom 10. Juni 2026 angekündigt: Die Wartung ende mit der für den 17. Juni 2026 geplanten Juni-Ausgabe nach etwa viereinhalb Jahren, Betreiber werden zur Migration auf 9.20 gedrängt, das dort als in ESV-Qualität beschrieben wird. Derselbe Beitrag nennt datierte Schritte, mit denen die Paket-Repositories bind-esv auf 9.20 umgestellt werden, darunter eine öffentliche Paketaktualisierung am 15. Juli 2026 und eine weitere Wartungsausgabe am 22. Juli 2026 (Ankündigung zum Ende von BIND 9.18).

Die Veröffentlichungshinweise zu BIND 9.20.26 zeigen, wie konkret diese Korrekturen aussehen: Dort sind mehrere Sicherheitskorrekturen mit CVE-Nummern aufgeführt, darunter CVE-2026-10723 zur Prüfung des NSEC3-Signernamens und CVE-2026-10822 zu einer fehlerhaften DNSKEY-Assertion (Versionshinweise zu 9.20.26).

Was ISC nicht mehr abdeckt, übernehmen Distributoren — mit eigenem Zeitplan und eigenen Grenzen. Der Sicherheitstracker von Debian führt bind9 in trixie mit 1:9.20.26-1deb13u1 und in trixie-security mit 1:9.20.29-1deb13u1, in bookworm mit 1:9.18.49-1deb12u1 und in bookworm-security mit 1:9.18.49-1deb12u2, für forky und sid mit 1:9.20.29-1, und weist einen Abschnitt mit offenen Problemen für das Paket aus (Debian-Sicherheitstracker zu bind9).

Der Debian-Pakettracker ergänzt die Suiten-Versionen: oldstable 1:9.18.49-1deb12u1, stable 1:9.20.23-1deb13u1, stable-security 1:9.20.29-1deb13u1, testing und unstable 1:9.20.29-1 sowie experimental 1:9.21.26-1. Er meldet fünfzehn offene Sicherheitsprobleme in bookworm und protokolliert die Aufnahme von 1:9.20.29-1deb13u1 in stable-security am 17. September 2026 sowie den Übergang von 1:9.20.29-1 nach testing am 19. September 2026 (Debian-Pakettracker zu bind9).

Diese Einträge belegen zweierlei. Erstens reicht die Reparatur einer bereits eingestellten Linie über die Verantwortung des Herstellers hinaus: Die 9.18-Linie erhält in bookworm-security weiterhin eine zweite Überarbeitung, obwohl ISC sie als am Lebensende stehend führt und für neue CVEs als anfällig annimmt. Zweitens lässt sich zwischen Herstellerangabe und Distribution ein messbarer Abstand ablesen: Während die ISC-Matrix die Korrektur 9.20.29 auf den 16. September 2026 datiert, protokolliert der Pakettracker die Aufnahme der entsprechenden Debian-Fassung in stable-security am 17. September 2026 und den Übergang nach testing am 19.

September 2026. Der Abstand ist hier kurz; er ist trotzdem die Zeitspanne, in der ein Paket noch die ältere Version ausliefert.

Ein weiteres Datum markiert dieselbe Kette: Die Debian-Sicherheitsankündigung DSA-6395-1, am 22. Juli 2026 von Salvatore Bonaccorso herausgegeben, behandelt neun bind9-CVEs und beschreibt Wirkungen wie die Umgehung der DNSSEC-Validierung, die Umgehung von RPZ-Richtlinien, Cache-Vergiftung und Denial of Service; die stabile Distribution wurde damit auf 1:9.20.26-1~deb13u1 gebracht (DSA-6395-1).

Widersprüche und die offene Messlücke

Drei öffentliche Aufzeichnungen nennen unterschiedliche Daten für das Ende von BIND 9.18: die für den 17. Juni 2026 geplante Juni-Ausgabe im Blogbeitrag des Konsortiums, der End-of-Life-Vermerk zum 1. Juli 2026 in der Schwachstellenmatrix und der 30. Juni 2026 in endoflife.date. Ähnlich unscharf ist die Verschiebung des Zweigs 9.22, die in der Support-Richtlinie als mindestens viertes Quartal 2026 und im Blogbeitrag als mindestens Jahresende 2026 formuliert wird.

Diese Abweichungen sind nicht auflösbar und werden hier den jeweiligen Quellen zugeordnet; für Betreiber bedeutet das vor allem, dass das genaue Datum eines Wartungsendes nicht aus einer einzelnen Quelle ableitbar ist.

Was in keiner der herangezogenen Quellen steht, ist die eigentlich entscheidende Zahl: welcher Anteil der betriebenen BIND-9-Server innerhalb eines bestimmten Zeitfensters eine korrigierte Version ausführt. ISC dokumentiert Zusagen, Debian dokumentiert Paketversionen, endoflife.date dokumentiert Supportzeiträume — keines dieser Dokumente misst die installierte Basis. Die Kette von der Offenlegung bis zur Reparatur lässt sich daher lückenlos beschreiben, ihr Ergebnis jedoch nicht beziffern.

Die Stärke der ISC-Dokumentation liegt in ihrer Nachprüfbarkeit: Schwellen, Fristen und Zweiggrenzen sind veröffentlicht. Ihre Schwäche ist dieselbe wie ihr Gegenstand — jedes dieser Dokumente ist die Darstellung des Konsortiums über seine eigenen Zusagen, und keine unabhängige Instanz bestätigt, dass die zugesagten Fristen eingehalten wurden. Die unabhängigen Aufzeichnungen, die in dieser Untersuchung vorliegen, betreffen den Weg danach, die Verpackung, nicht die Reaktionsgeschwindigkeit des Herstellers selbst.