Zusammenfassung

  • Am 13. November 2025 sperrte ARIN von 13:30 bis 14:30 Uhr EST administrativ jeden Zugriff auf seine Hosted- und RPS-Repositories. Um 14:35 Uhr meldete es vollständige Redundanz, um 14:50 Uhr die Rückkehr auf das Niveau vor dem Test.
  • Geprüft wurde die Erholung von einem nicht erreichbaren Repository. Die öffentliche Mitteilung benennt weder externe Abhängigkeitsklassen und gemeinsame Ausfallbereiche noch zirkuläre Abhängigkeiten oder den Beobachtungsumfang aus ACSP-Vorschlag 2025.7.
  • Eine versionierte Erklärung je Dienst und Ausfallbereich könnte Schutzzustand, Testgrenze, Zeitmarken, verbleibende Annahmen und Benachrichtigungsschwelle verbinden, ohne sicherheitskritische Topologie zu veröffentlichen.

Die Geschichte beginnt nicht mit dem Failover, sondern mit drei Unterlagen, die zeitlich dicht beieinanderliegen und dennoch getrennt gelesen werden müssen.

Am 23. Oktober 2025 erhielt ARIN nach der Einführung der ROA-Unterstützung für Transfers einen Kundenhinweis zu Hosted RPKI. Der öffentliche Bericht vom 27. Oktober begrenzt das Problem auf eine bestimmte ROA-Konstellation und einen Kunden. ARIN hielt laufende Transfers an, fand einen Codefehler, spielte die Korrektur ein und ergänzte Validierungen.

Am 28. Oktober reichte Ramakant Pandrangi den ACSP-Vorschlag 2025.7 ein. Gefordert wurden Abhängigkeiten pro Dienst, Vorabinformationen über wesentliche betriebliche oder architektonische Änderungen sowie ein Überblick über RTO, RPO und Kontinuitätsplanung. Genannt wurden unter anderem DNS, CDN, IP-Adressen, BGP-Routen, Provider sowie systemische und zirkuläre Abhängigkeiten.

Am 12. November antwortete ARIN, es erarbeite einen Plan zur Dokumentation zentraler Abhängigkeiten, zur Klärung des Änderungsmanagements und zur Beschreibung von Resilienz- und Kontinuitätszielen. Das Ergebnis solle der Community vorgelegt werden. Einen Tag später folgte der Produktionstest.

Der Vorfallbericht betrifft einen Softwarefehler. Der Vorschlag betrifft die Voraussetzungen kritischer Dienste. Der Test betrifft die Erholung von einem herbeigeführten Zustand. Erst diese Trennung macht aus den drei Unterlagen belastbare Evidenz.

Fünf Zeitmarken statt eines Verfügbarkeitsadjektivs

Laut ARINs technischer Mailingliste begann die Organisation um 13:00 Uhr EST, den Zugriff auf die Standorte der Hosted- und RPS-Repositories einzuschränken. Um 13:30 Uhr wurde der Zugriff vollständig administrativ gesperrt, um einen Totalausfall zu simulieren. Um 14:30 Uhr kam er zurück. Um 14:35 Uhr bestätigte ARIN die vollständige Redundanz, um 14:50 Uhr das frühere Systemniveau.

ARIN begründet auch den Test in Produktion: Eine getrennte Umgebung hätte Leistung und Vorbereitung auf einen Repository-Ausfall nicht wirklichkeitsgetreu abgebildet. Damit ist die Mitteilung mehr als die Behauptung „hochverfügbar“. Sie verbindet einen benannten Dienst, einen Eingriff und einen Wiederanlauf.

Die Aussage bleibt dennoch begrenzt. Die administrative Sperre sagt nicht, ob Wiederanlaufpfade denselben DNS-, CDN-, Transit-, Standort-, Strom- oder Identitätsdienst nutzen. Sie nennt keinen dahinter entfernten physischen oder logischen Ausfallbereich. Auch die zur Bestätigung genutzten externen Validatoren und mögliche Routingwirkungen werden nicht gemessen.

Diese Grenzen entwerten den Test nicht. Sie verhindern lediglich, dass aus dem getesteten Zugriffsausfall die Unabhängigkeit der gesamten Dienstkette abgeleitet wird.

Zwei redundante Wege können denselben Boden teilen

Systemische und zirkuläre Abhängigkeiten sind schwer zu erkennen. Zwei Anwendungen können getrennt laufen und doch dieselbe Namensauflösung benötigen. Umgekehrt ist ein externer Anbieter nicht automatisch eine Schwachstelle; eine Abhängigkeit kann diversifiziert, zwischengespeichert, austauschbar oder organisatorisch getrennt sein.

Eine Anbieterliste wäre daher zugleich sensibel und unzureichend. Entscheidend ist, welche Eigenschaft eines Dienstes beim Verlust einer Abhängigkeitsklasse erhalten bleiben muss.

Für ein RPKI-Repository könnte dies das weitere Lesen des zuletzt akzeptierten Zustands sein, die Integrität publizierter Inhalte, eine Obergrenze für deren Alter oder die geordnete Abstimmung aufgeschobener Schreibvorgänge. Die richtige Zusage hängt von der Ebene ab. Ein Relying Party, ein Ressourcenhalter beim ROA-Ändern, eine delegierte CA beim Publizieren über RPS und ARINs Wiederanlaufteam führen nicht dieselbe Handlung aus.

Die Wartungsankündigung vom Juli 2026 zeigt diese Trennung. ARIN Online, RESTful Provisioning, RPKI Up/Down und RPS sollten ausfallen; das RPKI-Repository sollte lesbar bleiben, aber keine Aktualisierungen veröffentlichen. Ein früherer Text von Theo March behandelte die zwei Uhren aus Erreichbarkeit und Aktualität. Hier geht es um etwas anderes: Welche Ausfallbereiche erreichen welche Ebene, und welche Kombination wurde tatsächlich geprüft?

Hosted, Delegated und RPS verteilen Verantwortung verschieden

ARINs aktuelle Dokumentation gibt an, dass mehr als 95 Prozent seiner RPKI-Installationen Hosted nutzen. Dort betreibt ARIN die Zertifizierungsstelle und das hochverfügbare Repository. Bei Delegated kann der Ressourcenhalter CA und Publikationsserver selbst führen. RPS teilt die Aufgabe: Der Halter kontrolliert CA und privaten Schlüssel, ARIN das Repository.

Die RPS-Seite beschreibt dies als bewusste Arbeitsteilung. Ein konsolidiertes Repository kann außerhalb des administrativen Bereichs der Stelle liegen, die ein RPKI-Element ausstellt. Eine Organisation kann kryptografische Kontrolle wünschen, ohne einen 24-Stunden-Publikationsdienst betreiben zu wollen.

Kontinuität hat dann mindestens zwei Fragen. Kann der Aussteller gültiges Material erzeugen? Kann das Repository es annehmen und verfügbar machen? Ein Test der Repository-Erholung sagt Wichtiges über die zweite Fähigkeit. Er prüft nicht automatisch CA, Publikationsprotokoll, Kontozugang oder Benachrichtigungsweg.

Gerade bei RPS wäre die Gleichsetzung falsch. Kryptografische Autorität und Publikationsverfügbarkeit liegen absichtlich bei verschiedenen Verantwortlichen. Das Beweisergebnis der einen Seite ist nicht die Garantie der anderen.

99,9 Prozent zeigen Leistung, nicht Architektur

ARINs Jahresbericht 2025 weist für RRDP- und Rsync-Repository jeweils 99,9 Prozent Verfügbarkeit aus. Der Wert ist nützlich: Er macht Jahre vergleichbar und übersetzt Zuverlässigkeit in eine Kennzahl.

Er zeigt keinen gemeinsamen Ausfallbereich, kein RTO, kein RPO und keine zulässige Alterung während eines Nur-Lese-Zustands. Er verrät auch nicht, welcher Test welchen Teil des Jahresergebnisses stützt. Hohe Verfügbarkeit und eine noch offene Abhängigkeitsdokumentation können gleichzeitig wahr sein. Auch eine gut getrennte Architektur kann eine gemessene Unterbrechung erleben.

Der Oktoberbericht beschreibt wiederum einen Codefehler nach einer Einführung, begrenzt auf eine Konstellation und einen Kunden. Er ist Evidenz für Änderungssteuerung und Korrektur, nicht für das Versagen eines externen Anbieters oder der Repository-Redundanz.

Öffentliche Rechenschaft wird stärker, wenn jede Unterlage nur die Schlussfolgerung tragen muss, die sie tatsächlich misst.

Ausfallklassen veröffentlichen, nicht den internen Schaltplan

Gegen eine detaillierte Abhängigkeitskarte gibt es einen berechtigten Sicherheitseinwand. Namen von Anbietern, Standorte, genaue Routen, Steuerpunkte und Umschaltbedingungen können Angriffe erleichtern. Verträge können Vertraulichkeit verlangen. Eine detaillierte Karte altert schnell.

Zwischen ihr und Schweigen liegt eine brauchbare Lösung. Für jeden kritischen Dienst und jede Ebene könnte ARIN eine kurze, versionierte Erklärung veröffentlichen:

  1. öffentliche Funktion sowie Leser und Schreiber;
  2. Abhängigkeitsklassen und Annahmen über gemeinsame Ausfälle ohne sensible Namen oder Orte;
  3. den Zustand, der beim Verlust einer Klasse erhalten bleiben soll;
  4. Szenario und Eingriffsgrenze des letzten Tests;
  5. beobachtete Zeiten für Einschränkung, Wiederherstellung, Redundanz und Normalisierung;
  6. nicht geprüfte Ausfallarten;
  7. geltende Ziele für Verfügbarkeit, RTO oder RPO;
  8. die wesentliche Änderung, die eine Mitgliederinformation auslöst;
  9. Version, Prüftermin und Korrekturverlauf.

Für die Öffentlichkeit reichen Klassen wie Namensdienst, Inhaltsauslieferung, Konnektivität, Identität und Betriebsstandort. Genauigkeit entsteht durch die Verbindung von Klasse, Schutzzustand und Test, nicht durch Koordinaten und Firmennamen.

Die Erklärung braucht ein Ablaufdatum. Nach einer Migration kann eine im Jahr 2025 korrekte Aussage über vollständige Redundanz weiter zitiert werden, obwohl sich ihre Grundlage geändert hat. Vorschlag 2025.7 verknüpft Abhängigkeitstransparenz und Änderungsmanagement zu Recht: Eine neue Architektur verlangt eine neue Evidenzgrenze.

Open ist ein Prozessstatus, kein Urteil über interne Arbeit

Zum Untersuchungsstichtag steht Vorschlag 2025.7 weiterhin auf Open. ARIN hatte angekündigt, ihn bis zur Umsetzung offen zu halten und den Plan der Community vorzulegen. Daraus lässt sich der öffentliche Stand beschreiben. Es lässt sich weder Stillstand noch eine verborgene konkrete Schwäche ableiten.

Der nächste nützliche Schritt muss keine Universalgarantie sein. Eine erste begrenzte Erklärung mit Dienst, Ebenen, Klassen, Test, Restannahmen und Prüftermin genügt. Der folgende Test kann dann vergleichbare Evidenz hinzufügen.

ARIN hat bereits den seltenen Teil geleistet: einen Eingriff in Produktion und einen Wiederanlauf im Minutentakt. Die Abhängigkeitsfrage bleibt offen, weil die Erholung in einem Szenario und die Unabhängigkeit aller Voraussetzungen zwei verschiedene Aussagen sind. Ihre saubere Verbindung würde den Test von einer Tagesmeldung zu dauerhafter institutioneller Evidenz machen.

Quellen