BIND-Sicherheitslücken: Was DNS-Server-Betreiber nach dem CERT-Bund-Advisory jetzt prüfen müssen

Ein DNS-Server läuft meistens einfach vor sich hin, jahrelang unangetastet, bis irgendwann ein Advisory mit einer Nummer wie WID-SEC-2026-2484 auftaucht und du dich fragst, ob "named" auf deinem Server eigentlich noch die Version ist, die du 2023 einmal installiert hast.

Worum es geht

Der Warn- und Informationsdienst des CERT-Bund hat ein Advisory zu Sicherheitslücken in BIND veröffentlicht, dem Nameserver, den ein großer Teil der autoritativen und rekursiven DNS-Infrastruktur im Netz verwendet – vom Hobby-Nameserver für eine Handvoll Domains bis zum rekursiven Resolver eines ganzen Rechenzentrums. Die genauen CVE-Nummern, betroffenen Versionsbereiche und den Schweregrad findest du im Original-Advisory beim CERT-Bund – das ist die verbindliche Quelle, nicht diese Zusammenfassung.

Was für dich als Betreiber zählt, ist unabhängig von den Details im Advisory immer gleich: Du musst wissen, welche Version läuft, ob der Dienst aus dem Internet erreichbar ist, und wie schnell du ein Update einspielen kannst, ohne die Namensauflösung für deine Domains oder Kunden zu unterbrechen.

Wer betroffen sein kann

Nicht jeder mit einer Domain betreibt einen eigenen Nameserver – die meisten nutzen den DNS ihres Registrars oder Hosters. Relevant wird das Advisory für dich, wenn du auf einem eigenen Rootserver oder VPS selbst bind9 bzw. named installiert hast, zum Beispiel um eigene Zonen zu verwalten, einen rekursiven Resolver für interne Dienste zu betreiben oder DNS für mehrere Domains zentral zu bündeln.

So prüfst du deinen eigenen Server

Die folgenden Schritte gehen davon aus, dass BIND als bind9-Paket über die Paketverwaltung deiner Distribution installiert ist, wie es auf den meisten Debian- und Ubuntu-Systemen üblich ist.

1. Installierte Version feststellen. Prüfe zuerst, welche Version tatsächlich läuft, nicht nur, welche im Paketmanager als installiert gilt.

   named -v
   sudo systemctl status bind9

2. Mit dem Advisory abgleichen. Öffne das Advisory und vergleiche die dort genannten betroffenen Versionsbereiche mit deiner Ausgabe. Ist deine Version älter als die im Advisory genannte gepatchte Version, bist du betroffen.
3. Erreichbarkeit prüfen. Stelle fest, ob und wie dein Server aus dem Internet erreichbar ist – das entscheidet, wie dringend das Update ist.

   sudo ss -tulpn | grep :53

4. Paketquelle aktualisieren und Update einspielen. Ziehe zuerst die aktuelle Paketliste, dann das Update selbst.

   sudo apt update
   sudo apt list --upgradable | grep bind9
   sudo apt upgrade bind9

5. Dienst neu starten und Zustand prüfen. Ein Upgrade allein reicht nicht – der laufende Prozess muss neu gestartet werden, damit die gepatchte Version aktiv wird.

   sudo systemctl restart bind9
   sudo rndc status

6. Konfiguration härten, unabhängig von diesem konkreten Advisory. Schränke ein, wer rekursive Anfragen stellen und Zonentransfers anfordern darf, in named.conf.options:

   allow-recursion { 127.0.0.1; dein.internes.netz/24; };
   allow-transfer { deine.sekundaer.ip; };

Prüfen, ob es geklappt hat

Nach Update und Neustart solltest du zwei Dinge kontrollieren: dass die neue Version tatsächlich aktiv ist und dass die Namensauflösung noch funktioniert.

named -v
dig @127.0.0.1 deine-domain.de +short

Liefert dig eine Antwort und zeigt named -v die erwartete, gepatchte Versionsnummer, war das Update erfolgreich. Wirf danach noch einen Blick ins Log, um sicherzustellen, dass der Neustart ohne Konfigurationsfehler durchgelaufen ist:

sudo journalctl -u bind9 -n 50 --no-pager

Eigenen BIND-Server betreiben oder abgeben?

Ein Advisory wie dieses ist ein guter Anlass, grundsätzlich zu hinterfragen, ob ein selbst gepflegter Nameserver für deinen Anwendungsfall noch die richtige Wahl ist.

Wenn du dich für den eigenen Betrieb entscheidest, gilt für BIND dasselbe Grundprinzip wie für jeden anderen öffentlich erreichbaren Dienst auf deinem Server: Zugriff so eng wie möglich fassen, Updates zeitnah einspielen, und den Rest der Absicherung nicht vergessen. Wie du zum Beispiel den SSH-Zugang auf demselben Server richtig absicherst, haben wir in einem separaten Beitrag zu SSH-Zugang, Schlüsseln und fail2ban zusammengefasst – die Prinzipien lassen sich direkt übertragen.

Ein Advisory ändert nichts an der Bedrohungslage, es macht sie nur sichtbar. Die Lücke war vorher schon da – nur ohne öffentliche Nummer.

Dass ein bekannt gewordenes Advisory schnell zum echten Problem wird, wenn es ignoriert wird, zeigt unser Rückblick auf den Virtualizor-Vorfall mit BGP-Hijack und untergeschobenem Update: Auch dort war die eigentliche Lücke bekannt, bevor sie ausgenutzt wurde. Wer nach einem Update nicht nur den Dienst neu startet, sondern ihn auch dauerhaft im Blick behält, bekommt einen erneuten Ausfall oder eine erneute Kompromittierung deutlich früher mit – dafür haben wir unser Monitoring für Server und Services im Programm.

Wenn du BIND gar nicht mehr brauchst

Nicht selten bleibt BIND installiert, obwohl der eigentliche Bedarf längst weggefallen ist – ein altes Setup, ein Testserver, ein Projekt, das eingestellt wurde. In dem Fall ist die sauberste Reaktion auf ein Advisory nicht das Update, sondern die Deinstallation:

sudo systemctl stop bind9
sudo systemctl disable bind9
sudo apt purge bind9

Ein Dienst, der nicht läuft, kann durch keine noch so kritische Lücke ausgenutzt werden – und jeder offene Port weniger ist eine Angriffsfläche weniger, unabhängig vom aktuellen Advisory.