Zusammenfassung

  • Laut RIPE NCC löste eine kurze Unterbrechung der Netzwerkverbindung des primären Lastverteilers die Umschaltung zur Reserve aus. Wegen einer Fehlkonfiguration gingen neue Datenbankverbindungen für Whois-Updates an eine schreibgeschützte Datenbank; bestehende Anwendungsverbindungen blieben an der Hauptdatenbank.
  • Die gemeldete Fehlerphase am 28. Oktober dauerte von 11:42 bis 19:40 UTC. Fehlgeschlagene Anträge zur Reverse-Delegation hätten nach späterer Prüfung keine Delegation verändert: Sie enthielten keine Änderung oder scheiterten an zonemaster-Vorprüfungen.

Der Schalter sprang, der Schreibweg bog falsch ab

Der Nachbericht der RIPE NCC nennt vier Schritte: kurze Leitungsunterbrechung am primären Lastverteiler, Umschaltung auf die Reserve, neue Whois-Update-Verbindungen über diesen Weg, schreibgeschützte statt primäre Datenbank als Ziel. Bereits bestehende Verbindungen der Anwendung blieben auf der Hauptdatenbank und waren nicht betroffen. Das Wort „intermittierend“ beschreibt hier eine klare Grenze. Der Unterschied hing am Alter der Verbindung, nicht an einem launischen Schreibdienst.

Für Abfragen ist eine Nur-Lese-Datenbank sinnvoll. Eine Änderung an einem Registry-Objekt kann sie nicht übernehmen. Der Ersatz-Lastverteiler konnte also netzseitig funktionieren und zugleich die wichtigste Aufgabe einer neuen Update-Verbindung vereiteln. Dass alte Sitzungen weiter Erfolg hatten, machte den Fehler schwerer zu erkennen: Ein Teil des Betriebs lieferte richtige Ergebnisse, während der neue Pfad an der falschen Rolle endete.

Die RIPE NCC setzt den Zeitraum fehlgeschlagener Updates am 28. Oktober auf 11:42 bis 19:40 UTC. Die erste Störungsmeldung nannte nicht verarbeitete Updates und Auswirkungen auf einige Domain-Objekte mit Bezug zum Reverse DNS. Erst der Bericht vom 3. November lieferte die konkrete Ursache. Der veröffentlichte Text nennt weder die fehlerhafte Einstellung noch die Zahl misslungener Verbindungen oder eine Aufschlüsselung nach Einreichungsweg. Ein Konfigurationsvergleich und Verbindungsprotokolle würden die Reichweite bestimmen.

Auch die Aussage zum Reverse DNS ist begrenzt und präzise. Die nachträgliche Prüfung ergab laut RIPE NCC, dass keiner der fehlgeschlagenen Reverse-Delegation-Anträge eine Delegation geändert hätte. Manche enthielten keine Veränderung, andere bestanden die zonemaster-Vorprüfung nicht. Der kaputte Schreibpfad ist belegt; aus dieser Gruppe folgt kein verlorener gültiger Zoneneintrag.

Was das Ergebnis eines Updates zeigt

Die RIPE-Dokumentation zur Objektverarbeitung beschreibt die getrennte Bearbeitung jedes Objekts und eine anschließende Bestätigung. Der Leitfaden zur Bestätigung hält fest, dass Syncupdates selbst bei einem HTTP 200 einzelne Objektfehler enthalten kann. Wer ein Register aktualisiert, braucht das konkrete Operationsergebnis und eine spätere Abfrage des Objekts. Ein erreichbarer Lastverteiler stellt diese Quittung nicht aus.