Summary

  • APNICs Statushistorie zeigt den öffentlichen RSC-Prüfdienst am 6. Oktober von 01:30 bis 02:45 UTC in Wartung, während die Rollout-Strategie geändert wurde.
  • Um 02:45 wurde die Wartung als abgeschlossen markiert; der Status-Feed führte den Dienst als betriebsbereit und meldete eine durchschnittliche Antwortzeit von 780 Millisekunden.

Die Statushistorie von APNIC weist für rsc-verifier.apnic.net am 6. Oktober eine Wartungszeit von 75 Minuten aus. Der Zwischenstand sagte, der Endpunkt könne während einer Änderung der Rollout-Strategie nicht erreichbar sein. Um 02:45 UTC wechselte der Eintrag zu „Maintenance completed“. Der RSS-Feed meldete den Dienst zur selben Zeit als Operational und nannte eine durchschnittliche Antwortzeit von 780 Millisekunden.

Das dokumentiert einen Dienststatus, keine Release-Notiz. Der öffentliche Eintrag nennt weder die Softwareversion noch die konkrete Änderung, zählt betroffene Nutzer nicht, meldet keine fehlgeschlagenen Prüfungen und beschreibt keinen Abnahmetest. Die 780 Millisekunden sind eine Feed-Statistik am Ende des Fensters, keine Verfügbarkeitsgarantie und kein Nachweis, dass jeder Nutzer ein Objekt prüfen konnte.

Die Abgrenzung ist wichtig, denn der öffentliche Prüfdienst ist nur ein Weg, eine RPKI Signed Checklist (RSC) zu kontrollieren. APNIC beschreibt RSCs als RPKI-Objekte, mit denen ein Ressourceninhaber Dateien oder Dokumente über ein Zertifikat signieren kann, das bestimmten IP-Ressourcen oder ASNs zugeordnet ist. Empfänger können die Signatur lokal mit rpki-client prüfen oder APNICs öffentlichen Dienst verwenden. Die Website erleichtert die Prüfung, begründet aber nicht die Autorität der Signatur.

Aus dem Protokoll folgt deshalb nur: APNICs öffentlicher RSC-Endpunkt ging in Wartung und wurde zum angegebenen Ende wieder als betriebsbereit geführt. Eine Unterbrechung der RSC-Signierung, Zertifikatsausgabe, Repository-Veröffentlichung, ROA-Verarbeitung oder BGP-Routen lässt sich daraus nicht ableiten. Ebenso wenig zeigt der Eintrag, ob ein bestimmtes RSC während des Fensters geprüft werden konnte. Die lokale Prüfung ist ein separater Weg, sofern Nutzer ein geeignetes Werkzeug und die erforderlichen RPKI-Daten haben.

Diese Grenze hilft beim Einordnen weiterer APNIC-Hinweise. Eine Mitteilung vom 1. Oktober beschrieb einen anderen Load-Balancer-Fehler, der acht Dienste einschließlich des RSC-Prüfers betraf; die geprüften öffentlichen Quellen stellen keine Verbindung zur Wartung am 6. Oktober her. Eine spätere Mitteilung für den 13. Oktober betraf einen anderen Endpunkt, den RPKI-rsync-Dienst. Es gibt keinen Beleg für einen zusammenhängenden Ausfall.

Für Betreiber, die RSCs bei BYOIP, beim Kunden-Onboarding oder als Nachweis von Ressourcen verwenden, kann ein Online-Prüfer die Zusammenarbeit mit Gegenparteien vereinfachen. Ein belastbares Verfahren sollte festlegen, ob lokale Prüfungen akzeptiert werden, welche Implementierung anerkannt wird, welchen Ressourcenbereich sie prüft und wie das Ergebnis archiviert wird. Dann ist die Verfügbarkeit der Website eine Zugangsfrage und keine stillschweigende kryptografische Abhängigkeit.

Quellen