Die Website war für die halbe Welt tot, und niemand hat sich beschwert

Vor ein paar Wochen habe ich die Website eines Kunden umgezogen. Alte Anlage vor Ort, neuer Server, alles vorbereitet, Umschalttag geplant. Lief.

Wochen später sitze ich abends im DNS-Verwaltungsbereich, weil ich einen Mail-Eintrag ändern muss. Reine Routine, zwei Minuten. Dabei fällt mein Blick eine Zeile zu weit nach unten.

Da steht noch die IP-Adresse des alten Anbieters.

Was da eigentlich stand

Vereinfacht sah es so aus:

Name	IPv4	IPv6
Hauptdomain	192.0.2.10 — alte Leitung, kein Webserver mehr	2001:db8::1 — neuer Server, läuft
www	192.0.2.10 — alte Leitung	fehlt komplett

Beim Umzug war der IPv6-Eintrag neu gesetzt worden. Der IPv4-Eintrag war eine Altlast und hat einfach niemand angefasst.

Das Ergebnis ist absurd, wenn man es ausspricht: Wer über IPv6 kam, sah die Seite. Wer über IPv4 kam, sah nichts. Und www hatte gar keinen IPv6-Eintrag, war also für alle tot.

In Deutschland heißt das grob: Handynutzer und moderne Anschlüsse sahen die Seite, viele Firmennetze und alles, was hinter älteren Anschlüssen oder Firmen-Proxys hängt, nicht.

Bei einer Arztpraxis ist genau das die falsche Hälfte.

Warum sich niemand beschwert hat

Das ist der Teil, der mich am meisten beschäftigt hat. Wochenlang, und keine einzige Rückmeldung. Nicht vom Kunden, nicht von Besuchern.

Die Erklärung liegt darin, wie die alte Leitung kaputt war. Sie war nicht aus. Der Port für verschlüsselte Verbindungen nahm die Anfrage brav an — und dann starb der Verbindungsaufbau leise.

Für den Browser heißt das: Verbindung wird aufgebaut, es passiert nichts, Zeitüberschreitung, und erst dann fällt er auf IPv6 zurück. Der Aufruf klappt also. Er dauert nur beim ersten Mal ungewöhnlich lange. Danach ist der Weg gemerkt und alles fühlt sich normal an.

Niemand meldet „Ihre Seite ist kaputt”. Alle denken „ist heute halt langsam” und klicken weiter.

Ein Totalausfall wird gemeldet. Ein halber Ausfall wird ertragen. Deshalb leben halbe Ausfälle länger.

Und warum ich es selbst nicht gesehen habe

Ich habe die Seite in diesen Wochen mehrfach aufgerufen. Sie ging immer.

Zwei Gründe. Erstens bevorzugt mein Rechner IPv6, wenn beides angeboten wird — ich landete also automatisch auf dem funktionierenden Weg. Zweitens, und das ist die eigentliche Falle: Wenn ich über meinen VPN-Tunnel arbeite, läuft alles über IPv4. Der Tunnel hat mich also auf den kaputten Weg gezwungen.

Ich habe das damals sogar bemerkt und falsch eingeordnet: „über den Tunnel geht die Seite nicht so richtig”. Und weil sie ohne Tunnel ging, habe ich den Tunnel verdächtigt.

Die Lehre, die ich mir aufgeschrieben habe und die ich hier gerne weitergebe:

Wenn jemand sagt „die Seite ist nicht erreichbar” und du siehst sie selbst — prüfe beide Wege getrennt. curl -4 gegen curl -6. Alles andere ist Raten.

Der Teil, der wehtut: Ich hatte eine Warnung

Ich betreibe eine kleine Überwachung, die täglich prüft, ob die Zertifikate meiner Domains noch gültig sind. Nicht anhand irgendeiner Datei auf einem Server, sondern über eine echte Verbindung von außen — weil nur das die Wahrheit sagt.

Diese Überwachung hat den Fehler gefunden. Am 6. August um 20:46. Vier Tage bevor ich zufällig im DNS darüber stolperte.

Im Protokoll steht:

Zertifikat nicht pruefbar:
Keine TLS-Verbindung moeglich. Entweder ist die Seite offline
oder von hier aus nicht erreichbar.

Diese Nachricht ist damals auf meinem Handy gelandet. Ich habe sie weggewischt.

Und ich verstehe sogar, warum. Zwei Dinge, die ich selbst so gebaut habe, haben zusammengewirkt:

Erstens die Anti-Nerv-Regel. Im Code steht wörtlich, dass eine nicht erreichbare Domain nur einmal gemeldet wird, nicht täglich. Der Gedanke dahinter ist richtig: Eine Überwachung, die jeden Tag dasselbe schreit, liest irgendwann niemand mehr. Nur führt genau diese Regel dazu, dass die eine wichtige Meldung mit allem anderen konkurriert, was an einem Mittwochabend um Viertel vor neun auf dem Handy aufploppt. Und verliert.

Zweitens der Wortlaut. „Entweder ist die Seite offline oder von hier aus nicht erreichbar.” Der zweite Halbsatz liefert die Ausrede gleich mit. Wer das abends liest, denkt „ach, von dem Server aus halt” und wischt weg.

Ich hatte eine Warnung geschrieben, die ihre eigene Entwarnung enthält.

Sechzehn Stunden

Die Sache hat noch eine zweite Ebene, die ich erst hinterher begriffen habe.

Das Zertifikat der Seite lief am 17. August ab. Erneuert wird es automatisch, und zwar in der Nacht zum 11. August. Für diese Erneuerung muss die Zertifizierungsstelle jeden Namen der Domain über IPv4 erreichen können — auch www. Und www hatte keinen funktionierenden IPv4-Weg.

Die Erneuerung wäre gescheitert. Am 17. August wäre das Zertifikat abgelaufen. Und dann hätten ausgerechnet die IPv6-Besucher, die als Einzige die Seite überhaupt sahen, eine rote Sicherheitswarnung bekommen.

Ich habe den DNS-Eintrag am 10. August korrigiert. Die automatische Erneuerung lief in der Nacht darauf um 02:17 durch. Das Zertifikat gilt jetzt bis November.

Rund sechzehn Stunden Abstand. Zwischen einem zufälligen Blick auf die falsche Zeile und dem Moment, in dem es zu spät gewesen wäre.

Zwei Kleinigkeiten, die beim Umstellen wichtig waren

Nicht alles mitnehmen, was auf der alten IP liegt. An derselben Adresse hingen Mail-Dienste des Kunden. Wer beim Aufräumen „die alten Einträge” pauschal umbiegt, legt nebenbei die Firmen-Mail lahm. Ich habe genau drei Einträge angefasst und den Rest bewusst stehenlassen.

Nach dem Umstellen misst dein eigener Rechner Unsinn. Direkt nach der Änderung meldete mein Mac für die Hauptdomain gar nichts mehr, während www schon lief. Das war der Zwischenspeicher im System, der noch die alte Adresse hielt. Abfragewerkzeuge für DNS umgehen diesen Speicher, ein normaler Seitenaufruf nicht. Wer nach einem Umzug prüft, sollte von einem fremden Rechner aus messen oder das Ziel im Aufruf fest vorgeben.

Was ich geändert habe

An der Überwachung, nicht an mir. Auf mich ist in dieser Hinsicht kein Verlass, das habe ich jetzt schriftlich.

Die Schwellen sind pro Domain unterschiedlich geworden, damit nicht dreimal gewarnt wird, bevor überhaupt etwas passieren könnte. Und der Text einer Warnung enthält keine Ausrede mehr.

Der eigentliche Fehler war aber keiner in der Technik. Es war die Annahme, dass eine Website entweder läuft oder nicht läuft. Sie kann auch für die eine Hälfte laufen und für die andere nicht — und dann sagt dir niemand Bescheid, weil die Hälfte, die es merkt, dich gar nicht kennt.