Zusammenfassung

  • APNIC erklärt, dass während der Wartung eines Load-Balancer-Knotens der Schritt zum Entleeren von Verbindungen versehentlich am anderen Knoten ausgeführt wurde und einen Ausfall verursachte. Die Mitteilung nennt acht betroffene Dienste, vom Mitgliederportal bis zu mehreren RPKI-Funktionen.
  • Für den 1. Oktober nennt APNIC ein Zeitfenster von 14:44 bis 15:01 Uhr (UTC+10), also 17 Minuten zwischen den angezeigten Minuten. Das Feld für die Dauer weist dagegen 15 Minuten aus. APNIC will Wartungs- und Failover-Verfahren überprüfen; Nutzerzahl und Prüfergebnisse für neue Schutzmaßnahmen fehlen.

Analyse

Der operative Kern der am 2. Oktober veröffentlichten Mitteilung ist die Abweichung zwischen dem für die Wartung vorgesehenen Knoten und dem Knoten, an dem die Verbindungen tatsächlich entleert wurden. APNIC zufolge wurde ein Load-Balancer-Knoten gewartet, während der Drain-Schritt versehentlich am anderen Knoten ausgeführt wurde und einen Ausfall verursachte.

Die Mitteilung führt acht Dienste auf: das MyAPNIC-Mitgliederportal, registry-api.apnic.net, DASH, die Notification Platform, REx, RPKI rsync, das RPKI-Provisioning- und Publication Protocol sowie rsc-verifier.apnic.net. Damit umfasst die Liste Funktionen für Mitglieder, Registry-Dienste und RPKI. Sie belegt den von APNIC gemeldeten Umfang, nicht aber, dass alle acht Dienste während des gesamten Zeitraums vollständig unerreichbar waren oder intern denselben Pfad nutzen.

Auch die Zeitangaben passen nicht zusammen. Als Beginn steht 14:44 Uhr, als Ende 15:01 Uhr, jeweils UTC+10. Die angezeigten Minuten liegen 17 Minuten auseinander; das Dauerfeld nennt 15 Minuten. Sekundenangaben und eine Erläuterung fehlen. Damit stehen in der öffentlichen Dokumentation zwei verschiedene Messwerte für dasselbe Ereignis.

APNIC will Wartungs- und Failover-Verfahren überprüfen, klarer formulieren und zusätzliche Schutzmaßnahmen vorsehen. Das ist eine angekündigte Prüfung, kein Beleg dafür, dass ein neues Verfahren beschlossen, getestet oder eingeführt wurde. Die Mitteilung nennt weder eine verantwortliche Person noch eine Frist, eine Prüfung des Zielknotens vor dem Drain-Schritt oder dienstspezifische Wiederherstellungszeiten.

Die Beweisgrenze ist ebenso wichtig. Zwar nennt die Liste RPKI-Dienste, APNIC berichtet aber weder von einer veralteten oder falschen Route-Origin-Autorisierung noch von Routing-Auswirkungen, Datenverlust, einem Sicherheitsvorfall oder fehlerhaften Ressourceneinträgen. Auch die Zahl betroffener Mitglieder oder Nutzer bleibt offen. Das Ereignis vom 1. Oktober ist von den zwei MyAPNIC-Ausfällen im September mit anderen genannten Ursachen zu unterscheiden; eine gemeinsame Ursache ist nicht belegt.

Eine sinnvolle Ergänzung könnte ohne interne Adressen, Zugangsdaten oder Topologiedetails dokumentieren, welcher Knoten gewartet werden sollte, wie das Ziel vor dem Verbindungsabbau bestätigt wird, welche Dienstprüfungen den Vorfall beendeten und wie die Dauer berechnet wurde. Bis solche Belege vorliegen, trägt nur eine enge Aussage: APNIC zufolge führte ein fehlgeleiteter Wartungsschritt zu einem Ausfall bei acht aufgeführten Diensten; die Verfahren werden überprüft.

Quellen