FAILED. Fünf Minuten später RECOVERED.

Wir betreiben die Nameserver für unsere Hosting-Kunden selbst: ns1 und ns2.bsnsoft.de sowie ns1 und ns2.bsnsoft-hostings.de. Ein Nameserver ist die Auskunftsstelle, die aus einem Domainnamen die IP-Adresse macht – fällt er aus, ist eine Website nicht „langsam“, sondern für den Rest der Welt schlicht nicht auffindbar.

Seit Wochen kamen aus dem Server-Monitoring nachts Meldungspaare, die immer gleich aussahen:

[ns1...] FAILED    : nameserver (<IP>)
[ns1...] RECOVERED : nameserver (<IP>)

Rund fünf Minuten auseinander, auf wechselnden Servern, immer im Nachtfenster. Dieser Artikel beschreibt, warum wir diese Meldungen zunächst falsch eingeordnet haben, was wirklich passiert ist und was am Ende offen bleibt. Wir schreiben das auf, weil der Mechanismus so an keiner öffentlichen Stelle dokumentiert ist – und weil ein Betriebsbericht ohne die offenen Punkte kein Betriebsbericht ist, sondern Werbung.

Warum wir es zuerst als Rauschen abgelegt haben

Eine Meldung, die sich selbst zurücknimmt, hat es leicht, durchzurutschen. In unserer Postfachsichtung liefen diese Paare unter „nächtliche Blips“, mit dem Verdacht auf Speicherdruck im Backupfenster. Nachts läuft die Sicherung, nachts wird der Server eng, nachts zuckt eine Prüfung. Das ist eine plausible Geschichte – und sie war falsch.

Drei Dinge haben zur Fehleinordnung beigetragen. Erstens der Zeitabstand: Fünf Minuten klingen nach einem Wimpernschlag. Zweitens das Wort „RECOVERED“: Es suggeriert, dass ein System sich selbst geheilt hat, also robust ist. Und drittens ein Detail in der FAILED-Mail – ein error 255 aus dem Reparaturskript restartsrv_named. Der sieht aus wie die eigentliche Störung, ist aber ein Folgefehler: Das Skript hat den Zustand am Ende korrekt hergestellt, unterwegs aber einen Fehlercode gemeldet. Alles zusammen ließ den Vorgang harmloser aussehen, als er war.

Was uns schließlich zum Hinschauen gebracht hat, war kein neues Symptom, sondern ein Muster: In der Nacht zum 23.08. meldeten beide bsnsoft-hostings-Nameserver dasselbe, nachdem in der Nacht davor bereits beide bsnsoft.de-Nameserver betroffen waren. Ein Problem, das über vier unabhängige Server wandert, ist kein Einzelserverproblem. Spätestens dann muss man ins Journal schauen.

Der Blick ins Journal

Das systemd-Journal ist das Betriebstagebuch eines Linux-Servers: Es protokolliert sekundengenau, welcher Dienst wann gestartet und gestoppt wurde. Auf ns1.bsnsoft-hostings.de ergab sich für die Nacht zum 23.08. folgende Kette (Zeiten in UTC, aus journalctl und dem cPanel-Update-Log):

01:11:01  cron startet upcp (naechtliches cPanel-Update)
01:11:55  apt entpackt 25 Pakete, darunter
          bind9 9.18.39-0ubuntu0.24.04.6
01:12:02  "Starting named.service" UND "Stopping pdns.service"
          - in derselben Sekunde
01:12:02  BIND uebernimmt Port 53, laedt aber nur 5 Zonen
          (die eingebauten)
01:15:07  chkservd bemerkt es, faehrt named runter, startet pdns
01:15:08  pdns laedt 237 Domains - Normalzustand wieder da

Dieselbe Signatur fand sich auf ns1 und ns2.bsnsoft.de in der Nacht zum 22.08. Damit war klar: Das ist kein Speicherdruck, das ist ein reproduzierbarer Ablauf, ausgelöst vom nächtlichen Paketupdate.

Der Mechanismus: drei einzeln harmlose Bausteine

Auf unseren cPanel-Servern beantwortet PowerDNS die DNS-Anfragen, nicht das ältere BIND. Beides sind Nameserver-Programme; wir haben uns bei der Einrichtung für PowerDNS entschieden. Drei Umstände greifen ineinander:

Erstens: BIND war noch scharf. Das Paket bind9 ist installiert, und sein Dienst named.service war im System weiterhin als „beim Start aktivieren“ markiert – ein Überbleibsel aus der Erstinstallation. Er lief nicht, aber er durfte laufen.

Zweitens: PowerDNS verdrängt BIND aktiv. Die von cPanel mitgelieferte Dienstdefinition für PowerDNS trägt den Eintrag Conflicts=named.service. Das ist eine systemd-Regel und sinnvoll gemeint: Startet BIND, stoppt systemd automatisch PowerDNS, damit nie zwei DNS-Server gleichzeitig um denselben Port streiten. Die Regel entscheidet allerdings nicht, wer der Richtige ist – sie gibt dem zuletzt Gestarteten recht.

Drittens: Das bind9-Paketupdate startet BIND. Beim nächtlichen Update ruft das Installationsskript des bind9-Pakets ein restart auf seinen eigenen Dienst. Und ein restart startet unter Debian und Ubuntu auch einen Dienst, der zwar gestoppt, aber eben noch aktiviert ist. Das war der Zünder.

Jeder dieser drei Bausteine ist für sich dokumentiert und für sich vernünftig. Erst ihre Kombination erzeugt den Fehler. Wir haben am 23.08.2026 im cPanel-Forum, bei WebHostingTalk, auf Reddit und in den PowerDNS-Issues gesucht: Zu genau dieser Konstellation gibt es keinen öffentlichen Bericht. Das liegt daran, dass vier Bedingungen zusammenkommen müssen – cPanel auf Ubuntu (die Mehrheit läuft auf AlmaLinux oder CloudLinux, wo sich die Paketskripte anders verhalten), PowerDNS statt des Standards BIND, PowerDNS bereits ab der Erstinstallation gewählt, und ein Update von bind9 selbst, das nur eine Handvoll Mal im Jahr kommt.

Der letzte Punkt ist der interessanteste, und hier ist cPanel tatsächlich etwas vorzuwerfen – ohne Drama, als Sachverhalt: Das Umschaltskript besitzt eine Funktion disable_bind(), die genau diese Altlast aufräumen würde. Sie läuft nur, wenn man einen bestehenden Server von BIND auf PowerDNS umstellt, nicht wenn man PowerDNS bei der Erstinstallation direkt aktiviert. Die Zeitstempel auf einem unserer Server zeigen das Fenster auf die Minute:

05.04.2025 08:42   Server aufgesetzt
05.04.2025 08:44   bind9 installiert, named.service aktiviert
05.04.2025 08:47   Umstellung auf PowerDNS

Der Aktivierungs-Symlink von 08:44 hat die Umstellung drei Minuten später überlebt und lag seither scharf da.

Warum REFUSED schlimmer ist als ein toter Port

Das ist der Teil, der uns am meisten beschäftigt hat. Es waren nicht fünf Minuten Rauschen, sondern 3 Minuten und 5 Sekunden, in denen der Server auf Port 53 antwortete – nur eben als BIND mit seinen fünf eingebauten Zonen statt als PowerDNS mit den Kundendomains. Für alle echten Domains kam in dieser Zeit ein REFUSED zurück: „Ich bin zuständig, und ich sage nein.“

Ein toter Port wäre fast harmloser gewesen. Wenn ein Nameserver gar nicht antwortet, läuft der fragende Resolver in einen Timeout und fragt den zweiten Nameserver der Domain – der Ausfall wird abgefedert, der Nutzer merkt bestenfalls eine kurze Verzögerung. Eine klare, schnelle Absage dagegen ist eine Antwort. Sie beendet die Suche schneller, als sie ein Timeout beenden würde.

Ein Dienst, der schweigt, wird umgangen. Ein Dienst, der falsch antwortet, wird geglaubt.

Dass in diesen Nächten keine Zone komplett ausgefallen ist, war Glück. Jede Domain hängt an einem Nameserver-Paar; solange sich die beiden Ausfallfenster nicht überschneiden, fängt der zweite Server alles ab. Die Update-Zeiten sind aber nur zufällig versetzt:

ns2.bsnsoft.de            00:06
ns1.bsnsoft.de            00:17
ns1.bsnsoft-hostings.de   01:11
ns2.bsnsoft-hostings.de   01:46

Beim Paar .bsnsoft.de liegen elf Minuten dazwischen – bei gut drei Minuten Ausfalldauer. Zieht sich ein Update einmal in die Länge, etwa durch einen Kernel, überlappen die beiden Fenster. Dann ist die Zone für ein paar Minuten gar nicht mehr auflösbar. Diese Rechnung ist der eigentliche Grund, warum wir den Fall nicht als „hat sich ja erledigt“ abgehakt haben.

Der Fix – und die Gegenprobe

Die Behebung ist unspektakulär. Auf allen fünf betroffenen Servern haben wir am 23.08.2026 den BIND-Dienst deaktiviert und zusätzlich gesperrt:

systemctl disable --now named.service
systemctl mask    named.service

Das disable ist der wirksame Hebel: Das Update-Werkzeug überspringt Dienste, die nicht aktiviert sind. Das mask ist die Absicherung obendrauf – ein Riegel, der auch einen direkten Startversuch abweist. Beides ist jederzeit rücknehmbar, falls wir je wieder von PowerDNS auf BIND wechseln.

Das Paket bind9 haben wir bewusst nicht entfernt. cPanel räumt in seinem BIND-Umfeld bei jedem Update mit auf, und die mitgelieferten Diagnosewerkzeuge dig und host brauchen wir täglich. Der Dienst war das Problem, nicht das Paket.

Wichtiger als der Eingriff ist die Kontrolle danach. Auf allen fünf Servern läuft PowerDNS, BIND ist gesperrt, und die Prozess-ID des DNS-Servers auf Port 53 ist unverändert dieselbe geblieben – es hat also nicht einmal einen Neustart gegeben. DNS-Abfragen von außen lieferten vorher wie nachher die richtige Antwort; auf dem Hosting-Server haben wir zusätzlich geprüft, dass Mailversand und Postfachzugriff unberührt blieben und die MX-Auskunft stimmt.

Dann haben wir den Auslöser nachgestellt, statt uns auf die Theorie zu verlassen. Auf jedem Server wurde exakt der Aufruf von Hand ausgeführt, den das bind9-Installationsskript beim Update absetzt:

deb-systemd-invoke restart named.service
  → "named.service is a disabled or a static unit
     not running, not starting it."

Vorher hätte dieser eine Befehl PowerDNS umgekippt. Jetzt passiert nichts. Ein direkter Startversuch scheitert zusätzlich mit dem Hinweis, dass die Einheit gesperrt ist. Das ist der Unterschied zwischen „wir haben etwas geändert“ und „wir haben nachgewiesen, dass die Änderung den konkreten Auslöser abfängt“.

Was offen bleibt

Hier wird es unbequem, und deshalb steht es im Artikel.

Die Haltbarkeit des Fix ist nicht bewiesen. Unsere Handprobe zeigt, dass die Sperre jetzt greift. Sie sagt nichts darüber, ob ein echtes bind9-Paketupgrade sie wieder abräumt: Dasselbe Installationsskript hebt im Normalablauf eine Sperre auf und kann einen Dienst anhand seines früheren Zustands erneut aktivieren. Wir wissen es erst beim nächsten bind9-Update – und das kommt nur ein paar Mal im Jahr, ein Termin lässt sich dafür nicht setzen. Die beiden Prüfbefehle sind hinterlegt, damit die Frage dann in zwei Minuten beantwortet ist:

systemctl is-enabled named.service
  # erwartet: masked

journalctl -u pdns --since "-1d" | grep -c "Stopping pdns"
  # erwartet: 0

Bleibt die Sperre bestehen, ist der Fall zu. Frisst das Update sie, ist die Alternative eine eigene systemd-Regel oder doch das Entfernen des Pakets bei Erhalt der Diagnosewerkzeuge.

Die zweite Verteidigungslinie fehlt noch. Elf Minuten Abstand zwischen zwei Nameservern desselben Paares sind zu knapp. Ein Nameserver-Paar darf sich nie im selben Fenster aktualisieren. Diese Entzerrung hilft auch gegen künftige Update-Stolperer, die mit bind9 nichts zu tun haben – sie ist geplant, aber noch nicht umgesetzt.

Nicht jede Meldung ist damit erklärt. Ein Ausfall auf dem Hosting-Server in der Nacht zum 21.08. hat eine andere Ursache: Im dortigen Journal findet sich seit Mitte August kein einziger Wechsel zwischen den beiden DNS-Diensten. Dort war PowerDNS also vermutlich nie wirklich weg, und die Prüfung selbst ist unter Last fehlgeschlagen. Dieser Punkt bleibt offen. Wir hängen ihn nicht an die vorliegende Erklärung an, nur weil sie gerade zur Hand ist – das ist die häufigste Art, sich eine Ursachenanalyse kaputtzumachen.

Der Fall selbst ist sauber belegt und reproduzierbar. Er gehört an den Hersteller gemeldet, mit dem naheliegenden Vorschlag, das Aufräumen von BIND auch beim Aktivieren von PowerDNS mitlaufen zu lassen und nicht nur beim Umschalten.

Was wir daraus mitnehmen – und was Sie davon haben

Drei Punkte, die über diesen einen Server-Zoo hinaus gelten:

• „FAILED, fünf Minuten später RECOVERED“ ist ein Prüftakt, keine Ausfalldauer. Die fünf Minuten sind der Abstand, in dem die Überwachung nachschaut – nicht die Zeit, die der Dienst gebraucht hat. Die tatsächliche Dauer stand im Journal und betrug gut drei Minuten. Wer Monitoring-Mails liest, muss wissen, was die Zahlen darin messen.
• Selbstheilende Symptome sind der beste Ort, um sich zu verstecken. Eine Störung, die eskaliert, wird bearbeitet. Eine, die sich selbst zurücknimmt, wandert in den Ordner mit den Kuriositäten. Bei uns datiert das erste nachweisbare Auftreten im Prüfprotokoll auf den 14. September 2025 – sichtbar die ganze Zeit, gelesen als Rauschen.
• Der harmlos aussehende Fall war der schlimmere. Ein Dienst, der antwortet, aber falsch, richtet mehr Schaden an als einer, der schweigt, weil er die eingebauten Umwege des Netzes aushebelt. Diese Umkehrung gilt weit über DNS hinaus: für Caches, die veraltete Daten ausliefern, für Schnittstellen, die brav 200 OK mit leerem Inhalt senden, für Prüfungen, die nur den Port testen und nicht die Antwort.

Für unsere Hosting-Kunden ist die praktische Konsequenz banal und trotzdem der Kern: Wir haben eine Meldung, die man hätte wegklicken können, bis zur Ursache verfolgt, den Auslöser nachgestellt und schreiben auf, was noch nicht bewiesen ist. Das ist der Unterschied zwischen einem Server, der jemandem gehört, und einem, der nur läuft. Wie wir Betrieb und Überwachung insgesamt aufziehen, steht auf der Hosting-Seite; wenn es um die Frage geht, wie belastbar eine bestehende Infrastruktur wirklich ist, gehört das eher in eine nüchterne Bestandsaufnahme als in eine Produktbroschüre.

Und wenn Sie selbst cPanel auf Ubuntu mit PowerDNS betreiben: Ein Blick auf den Zustand von named.service dauert zehn Sekunden.