Zusammenfassung

  • APNIC zufolge erkannte eine Netzwerk-Firewall am 28. August 2026 einen Hardwarefehler und startete zwischen 19:10 und 19:18 Uhr, UTC+10, neu.
  • Genannt werden MyAPNIC, die Registry-API, Orbit, FTP, das RPKI-Provisionierungs- und Publikationsprotokoll sowie RPKI-rsync.
  • Die öffentliche Meldung belegt weder Datenverlust noch Beschädigung, doppelte Aktualisierungen oder einen Sicherheitsvorfall. Sie weist aber auch keine dienstbezogenen Annahme-, Commit-, Warteschlangen- oder Konsistenzzustände aus.
  • Ein knapper Vorgangsbeleg könnte innerhalb derselben Incident-ID zwischen nicht empfangen, angenommen, abgeschlossen, sichtbar, wiederholbar, nur abfragbar und unbekannt unterscheiden.

Was um 19:18 Uhr tatsächlich endete

Die APNIC-Meldung vom 28. August setzt den Beginn auf 19:10 Uhr und das Ende auf 19:18 Uhr in UTC+10. Eine der Netzwerk-Firewalls habe einen Hardwarefehler erkannt und neu gestartet. Dadurch seien die aufgeführten Dienste unterbrochen worden. APNIC untersucht die Ursache mit dem Hardwareanbieter und will das Umschalten des Verkehrs zwischen den Firewalls verbessern. Der RSS-Feed enthält dieselbe Zeit und Beschreibung.

Das ist für eine frühe Betriebsmeldung eine nützliche Grenze. Daraus folgt weder, dass die gesamte Registry ausfiel, noch, dass jeder Dienst acht Minuten vollständig unerreichbar war. Eine Unterbrechung kann eine abgewiesene Verbindung, einen Teilfehler, einen verlorenen Antwortweg nach der Annahme, eine verspätete Veröffentlichung oder einen fehlgeschlagenen Abruf bei unverändertem Objekt bedeuten.

APNIC ordnet diese Zustände nicht den einzelnen Diensten zu. Deshalb wäre sowohl eine Schadensbehauptung als auch eine pauschale Entwarnung unzulässig. Die Uhr beschreibt den Firewall-Incident. Ein bereits angestoßener Vorgang kann eine längere oder andere Uhr besitzen.

Die API arbeitet weiter, wenn der HTTP-Dialog schon abgebrochen ist

Laut APNICs Einführung der Registry-API lassen sich Delegationsinformationen abrufen und Whois-Einträge, Reverse DNS, ROAs und Route Objects verwalten. Die Schnittstelle liest also nicht nur, sondern nimmt zustandsändernde Arbeiten entgegen.

Alle Aktualisierungen werden als asynchrone Task-Objekte geführt. Nach der Einreichung erhält der Client einen Link, über den er den Status bis zum Ergebnis abfragt. Batches für Reverse DNS und abstrakte Routenverwaltung wirken nach Möglichkeit transaktional.

Damit liegen zwischen „gesendet“ und „fertig“ mehrere Grenzen. Eine Verbindung kann abbrechen, bevor der Server den Request sieht, nach dem Empfang aber vor der Annahme, nach dem Erzeugen des Tasks oder nach dem Commit, obwohl die letzte Antwort den Client nicht mehr erreicht.

Im ersten Fall kann ein erneuter Versuch sinnvoll sein. Existiert der Task, ist dessen Abfrage sicherer. Ist die Änderung bereits wirksam, erzeugt ein blindes Wiederholen womöglich nur einen neuen Vorgang. Für den 28. August ist weder ein Doppel-Update noch ein verlorener Task belegt. Die Meldung sagt lediglich nicht, welche dieser Zustände rund um das Zeitfenster galt.

MyAPNIC bildet eine zweite Sicht. APNIC schreibt, dass API-Funktionen den Portal-Funktionen entsprechen: Änderungen an registrierten Routen werden in MyAPNIC sichtbar, und Portal-Änderungen erscheinen über die API. Ein wieder erreichbares Portal belegt einen neuen erfolgreichen Lesezugriff. Es belegt nicht automatisch den Abschluss eines früheren Tasks oder die gleichzeitige Konsistenz beider Darstellungen.

Für Mitglieder wären vier Aussagen handlungsfähig: Während des Fensters wurden keine Schreibvorgänge angenommen; angenommene Tasks sind abgeglichen; einzelne Tasks laufen noch; oder der Zustand ist nicht beobachtbar. „Der Netzwerkverkehr war wiederhergestellt“ ist ebenfalls richtig, beantwortet aber eine andere Frage.

Orbit und FTP haben gegensätzliche Wiederholungsrisiken

Orbit ist APNICs Community-Kommunikationsplattform und die Weiterentwicklung von Mailinglisten. Dort werden Archive gelesen, Beiträge veröffentlicht und Nachrichten per E-Mail verteilt. Ein fehlgeschlagener Archivabruf kann meist folgenlos wiederholt werden. Bei einer unklar angenommenen Veröffentlichung sollte zunächst das Archiv geprüft werden, damit kein Doppelbeitrag entsteht. Verzögerte E-Mail-Zustellung hat nochmals einen anderen Abschluss.

Die Meldung nennt nur Orbit. Sie belegt keinen verlorenen Beitrag und keine Warteschlange. Sie lässt offen, welcher Pfad betroffen war.

FTP ist öffentliche Verteilung. Das RIR Statistics Exchange Format sieht weltweit lesbare Dateien ohne Zugriffskontrolle vor, dazu einen dauerhaften Namen für die neueste Ausgabe und Validierungsmaterial.

Ein fehlgeschlagener Download beschädigt die Datei nicht. Eine Tagesausgabe kann erstellt sein, während ein Zugriffsweg noch fehlt. Der Verweis latest und sein datiertes Ziel können getrennt geprüft werden. Für keines dieser Szenarien gibt es einen Beleg. Gerade deshalb sollte der öffentliche Status eng bleiben: nur Lesen gestört, Publikation verzögert, Objekt unverändert, Zeiger geprüft oder unbekannt.

RPKI ist kein einzelner Dienstaufruf

APNICs Certification Practice Statement trennt Provisionierungsprotokoll, Publikationsprotokoll, Repository-Zugriff über rsync und Zugriff über RRDP. Zertifikatsaussteller und Subjekt, Publisher und Repository sowie Repository und Relying Party kommunizieren in unterschiedlichen Richtungen.

RFC 6492 beschreibt Request und Response der Ressourcen-Zertifikatsprovisionierung. RFC 8181 definiert Publikationsoperationen. RFC 8182 definiert RRDP über HTTPS.

Die Incident-Meldung nennt „RPKI Provisioning and Publication protocol“ und gesondert „RPKI rsync“. RRDP wird nicht genannt. Daraus folgt weder Verfügbarkeit noch Ausfall noch eine bestimmte Lage zur Firewall. Der öffentliche Text weist RRDP schlicht keinen Zustand zu.

Ein unterbrochener Repository-Abruf bedeutet auch nicht, dass Router sofort ihre gegenwärtige Policy verloren. Validatoren verwenden lokal abgerufene und geprüfte Objekte in eigenen Zyklen. Cache-Alter, Ablaufzeit, Validatorverhalten und Routingwirkung sind nicht dokumentiert.

Der Abschluss muss deshalb richtungsbezogen sein. Erhielt der Provisionierungsrequest seine passende Antwort? Wurde eine Publikation bestätigt oder muss sie erneut ausgeführt werden? Kehrte der rsync-Objektsatz konsistent zurück? Wurde RRDP überhaupt beobachtet? Diese Trennung unterstellt kein Fehlverhalten. Sie verhindert, dass das Kürzel RPKI mehrere voneinander unabhängige Zustände verschluckt.

Schnelle Warnung, später Abgleich

Es wäre falsch, den Ersthinweis so lange zurückzuhalten, bis jeder Task und jede Queue ausgewertet ist. Die Meldung half Nutzern, eigene Fehler zeitlich zuzuordnen, und gab Ursache, Reichweite sowie Korrekturrichtung an. Ein früher Incident-Clock erfüllt damit eine legitime Funktion.

APNIC kennt die Messgrenze bereits. Im Verfügbarkeitsbericht für Q4 2025 verbindet die Organisation minütliche externe Probes mit Erfolgs- und Fehlerraten aus Nutzersicht. Überschneidende Zeiträume werden ausgeschlossen, damit derselbe Vorfall nicht doppelt zählt. Endpoint-Erreichbarkeit und Request-Ergebnis sind also schon zwei Evidenzflächen.

Die Meldung kann kurz bleiben. Nach dem internen Abgleich kann eine kleine Vorgangsmatrix an dieselbe Incident-ID angehängt werden.

Der kleinste belastbare Abschlussbeleg

Jede Zeile braucht Schnittstelle, Richtung und Vorgangsklasse: Mitglieder-Update, Task-Abfrage, Community-Schreiben oder -Lesen, Dateierzeugung oder -Abruf, RPKI-Provisionierung, RPKI-Publikation, rsync-Abruf und gegebenenfalls RRDP-Beobachtung.

Ein begrenztes Vokabular genügt: nicht empfangen, vor Annahme abgewiesen, angenommen, committed, zurückgerollt, ausstehend, in einer benannten Darstellung sichtbar, sicher wiederholbar, nur abfragen, unbekannt. Schnittstellenrückkehr, Queue-Abbau und Darstellungsabgleich bekommen eigene Zeitpunkte.

Volumen können als Band angegeben werden. Mitgliederidentitäten, rohe Requests, Objektinhalte, interne Adressen, Credentials, Gerätekennungen und sicherheitsrelevante Topologie bleiben geschützt. Ändert eine spätere Auswertung die Einstufung, ergänzt sie die Korrektur mit Zeitstempel, statt den ersten Zustand zu löschen.

Um 19:18 Uhr endete nach APNICs Angabe der Firewall-Incident. Ein Registry-Schreibvorgang endet, wenn Annahme und Wirkung feststehen. Eine Publikation endet, wenn das Repository-Ergebnis bekannt ist. Ein Abruf endet mit einer prüfbaren Darstellung. Ein Ereignis kann alle drei Uhren enthalten. Es sollte nicht so tun, als wären sie dieselbe.

Quellen