Zusammenfassung

  • ARIN kündigte für die Wartung am 28. Juli 2026 an, dass Whois, Whois-RWS, RDAP, IRR und das RPKI-Repository weiter betrieben würden, während keine Updates veröffentlicht würden.
  • ARIN Online, RESTful Provisioning, RPKI Up/Down und RPKI Repository Publication sollten nicht verfügbar sein; REST-Aufrufe konnten in eine Warteschlange geraten und mussten gegebenenfalls erneut gesendet werden.
  • Anhang C des Jahresberichts 2025 nennt sechs Verfügbarkeitswerte—99,9, 99,9, 99,9, 100, 100 und 99,9 Prozent—aber keine Spalte für Aktualität, Datenalter, letzte Veröffentlichung oder maßgebliches Update.
  • Eine Dienstkarte mit Leseuhr und Veröffentlichungsuhr könnte Abfrage, Annahme, Veröffentlichung und Abgleich sauber unterscheiden, ohne aus einer geplanten Wartung einen Störfall zu machen.

Wer auf ein Register angewiesen ist, braucht nicht immer dieselbe Zusage. Für eine Recherche kann es genügen, dass ein bereits veröffentlichter Datensatz erreichbar ist. Für eine kurz zuvor eingereichte Änderung ist dagegen entscheidend, ob sie angenommen, öffentlich wirksam gemacht und nach einer Wartung abgeglichen wurde. Diese Unterschiede sind keine Nuancen des Wortes „online“, sondern unterschiedliche Zustände einer öffentlichen Infrastruktur.

Der Wartungshinweis von ARIN vom 14. Juli 2026 beschreibt sie bemerkenswert klar. Für den 28. Juli sollten ARIN Online, RESTful Provisioning, RPKI Up/Down und RPKI Repository Publication nicht verfügbar sein. Whois, Whois-RWS, RDAP, IRR und das RPKI-Repository sollten hingegen weiter funktionieren. Gleichzeitig würden während des Fensters keine Aktualisierungen veröffentlicht. RESTful-Provisioning-Aufrufe konnten in eine Warteschlange gelegt werden und möglicherweise eine erneute Übermittlung verlangen.

Der letzte Satz ist keine Aussage, dass ein Aufruf verloren ging. Er markiert einen Wiederaufnahme- und Prüfpfad. Ebenso wenig belegt der Hinweis veraltete Antworten, einen Schaden, ein fehlgeschlagenes Wiederanlaufen oder einen verdeckten Ausfall. Belegt ist ein geplanter Zustand, in dem Lesen, Schreiben, maßgebliches Veröffentlichen und der spätere Abgleich auseinanderfallen.

Weshalb das offene Lesen eine Stärke sein kann

ARINs beste Verteidigung liegt nicht in einem möglichst breiten Grün, sondern in der Nützlichkeit des verbleibenden Lesewegs. Ein Whois- oder RDAP-Leser kann auf bereits veröffentlichte Informationen zugreifen. IRR-Abfragen können weiter den vorhandenen Zustand liefern. Bei RPKI arbeiten vertrauende Programme mit publizierten signierten Objekten und lokaler Cache-Haltung; eine neue Veröffentlichung muss nicht im selben Augenblick stattfinden, damit das schon Vorliegende unverifizierbar wird.

Die Seiten zu Hosted RPKI, Repository Publication Service, Trust Anchor Locator und RPKI-Begriffen beschreiben zusammenhängende, aber getrennte Rollen von Zertifizierungsstelle, Publikation, Repository und Relying Party. Sie tragen die begrenzte Aussage, dass zwischengespeichertes signiertes Material während einer Publikationspause noch prüfbar sein kann. Sie begründen weder einen einheitlich zulässigen Zeitwert noch eine Behauptung über jede konkrete Antwort.

Ein verfügbarer Leser ist also kein Scheindienst. Er ist ein sinnvoller degradierter Dienst. Gerade deshalb sollte sein Status nicht heimlich die Arbeit eines Schreib- oder Veröffentlichungspfads bescheinigen.

ARINs Statusseite ordnet öffentliche Komponenten bereits getrennt. Daraus folgt nichts über interne Dashboards, Sicherheitsverfahren, Lieferanten oder Wiederherstellungsziele. Es zeigt nur, dass die öffentliche Darstellung nicht auf einen einzigen Zustand beschränkt sein muss.

Was die sechs Kennzahlen sichtbar machen

Der Anhang C des ARIN-Jahresberichts 2025 führt ARIN Online, Whois/RDAP, Resource Public Key Infrastructure, RDAP Bootstrap, Internet Routing Registry und Registration Transaction Service auf. Die Werte lauten in dieser Reihenfolge 99,9, 99,9, 99,9, 100, 100 und 99,9 Prozent; ergänzt werden sie um Komponentenwerte.

Das ist ein wertvoller Befund über Erreichbarkeit. Eine Oberfläche, die nicht antwortet, hilft dem Leser nicht dadurch, dass sie möglicherweise neue Daten schreiben könnte. Verfügbarkeit verdient darum einen eigenen, dauerhaften Platz im Bericht.

Die Feststellung hier ist enger: In der eingefrorenen Tabelle auf Seite 24 steht keine Spalte oder Bezeichnung freshness, data age, last published oder authoritative update. Diese Beobachtung betrifft die Tabelle, nicht ARINs interne Überwachung, nicht jede öffentliche Ansicht und nicht die Fähigkeit zur Wiederherstellung. Doch für den öffentlichen Leser fehlt damit gerade die Angabe, wann der maßgebliche Zustand zuletzt erfolgreich nach außen gelangte.

Während einer kontrollierten Publikationspause kann ein hoher Verfügbarkeitswert daher vollständig zutreffen und dennoch die zweite Frage offenlassen. „Kann ich lesen?“ und „Wie weit reicht der veröffentlichte Stand?“ sind zwei richtige, nicht austauschbare Fragen.

Zwei Uhren statt einer überladenen Ampel

Eine brauchbare Lösung wäre klein und versionsfähig. Die Leseuhr einer Dienstkarte nennt Komponente, Leseoberfläche und Abfrageverfügbarkeit. Die zweite Uhr nennt die Annahme von Schreibvorgängen, die erwartete Veröffentlichungsfrequenz, die letzte erfolgreiche maßgebliche Veröffentlichung und das im aktuellen Zustand erwartete maximale Datenalter.

Bei Wartung sollte dieselbe Karte sagen, ob eine Anfrage abgewiesen, eingereiht, erneut ausgeführt, erneut einzureichen oder abgeglichen ist. Eine Versionskennung mit Korrekturverweis würde spätere Änderungen erklären, statt frühere Kommunikation unsichtbar zu überschreiben.

Das ist keine Forderung nach Passwörtern, Topologie oder sicherheitsrelevanten Abläufen. Es ist auch keine globale Frist für RPKI, RDAP, IRR und Registrierungstransaktionen. Es beschreibt, welche Aussage die öffentliche Grenze im Augenblick tatsächlich trägt. Der Status-Schnappschuss darf „All Systems Operational“ melden; letzter maßgeblicher Veröffentlichungspunkt und abgeschlossener Warteschlangenabgleich sind zusätzliche Tatsachen.

Quellen

  1. ARIN-Wartungshinweis
  2. ARIN Annual Report 2025, Anhang C
  3. ARIN Service-Level-Reports
  4. ARIN Statuspage und Zusammenfassung
  5. Hosted RPKI, RPS, TAL und RPKI terms