Zusammenfassung

  • Das öffentlich ausgelieferte AIRRS-JavaScript hängt bei der Abfrage der RIPEstat-Seitenstruktur den wörtlichen Schlüssel amp;profile=afrinic an. Innerhalb einer JavaScript-Zeichenkette wird & nicht wie HTML dekodiert; der Parameter heißt tatsächlich amp;profile statt profile.
  • Am 11. September 2026 lieferten Standardaufruf und wörtlicher AIRRS-Aufruf für eine ASN, ein Präfix, eine Domain und ein Land jeweils 200, sieben Registerkarten und identische normalisierte Strukturdaten.
  • Der korrekt benannte Aufruf profile=afrinic ergab in allen vier Fällen HTTP 500, status: error, ein leeres Datenobjekt und keine Registerkarte. Das widerlegt nicht die Daten der Widgets, sondern die Annahme, eine gefüllte Seite beweise die Profilauswahl.
  • Ein belastbarer Abschluss muss Clientnamen, serverseitiges Profil und Nachweis gemeinsam reparieren: Ein Auswahlbeleg sollte angefordertes und verwendetes Profil, Struktur-Hash, API-Build, Status und Rückfallregel nennen.

Der sichtbare Erfolg beantwortet die falsche Frage

Ein offener Fehler ist unangenehm, aber erkenntnisreich. Er stoppt den Nutzer und zwingt den Betreiber, die Ursache zu prüfen. Eine plausible Standardantwort ist gefährlicher: Sie bewahrt die Nutzbarkeit, erfüllt den oberflächlichen Test und lässt die ausgelassene Konfigurationsfrage verschwinden.

AIRRS steht für African Internet Registry and Routing Statistics. Der Dienst beschreibt sich als Zusammenarbeit von AFRINIC und RIPE NCC, die von RIPEstat bereitgestellte Daten in einer benutzerfreundlichen Anwendung zeigt. Sein Anspruch reicht über eine technische Demonstration hinaus. Aktuelle Informationen zu Internetressourcen oder Ländern sollen Netzbetreibern, Regulierungsstellen, politischen Entscheidungsträgern und Forschenden zu fundierten Entscheidungen verhelfen.

Die archivierte AFRINIC-Ankündigung nennt WHOIS, RIPE RIS, RIPE Atlas und externe Datensätze als Quellen und erklärt, AIRRS werde von der RIPE Stat API gespeist. Die Startseite stellt vier Abfrageformen heraus: ASN-Informationen, Präfixinformationen, Domainabfrage und Länderbericht.

Damit ist AIRRS eine Auswahl- und Präsentationsschicht, nicht der Ursprung aller dargestellten Daten. Nach einer Eingabe fragt der Client bei RIPEstats results-page-structure ab, welche Registerkarten und Widgets aufgebaut werden sollen. Anschließend lädt er die Widgets. Dass eine verwertbare Struktur eintrifft, ist ein Zustand. Dass das beabsichtigte AFRINIC-Profil diese Struktur ausgewählt hat, ist ein anderer.

Eine HTML-Schreibweise in einer JavaScript-Zeichenkette

Die aktuelle Ergebnisanwendung nennt sich im Dateikopf „AFRINIC RIPEstat Template“ vom Februar 2020. Die HTTP-Header des erfassten Skripts verzeichnen den 11. März 2020, 10:00:24 UTC, als letzte Änderung. Der Code bildet zunächst die URL für die Seitenstruktur und hängt dann genau diese Zeichenfolge an:

&profile=afrinic

In einem HTML-Text steht & für das sichtbare kaufmännische Und. Hier befindet sich die Folge aber in einer JavaScript-Zeichenkette, die unmittelbar als URL verwendet wird. Das erste & trennt einen neuen Query-Parameter ab; die folgenden Zeichen bilden den wörtlichen Namen amp;profile. Es gibt keinen späteren HTML-Parser, der daraus einen Parameter profile macht.

Unbekannte Query-Schlüssel führen bei vielen Schnittstellen nicht zu einem Fehler. Sie werden ignoriert, während die Standardkonfiguration eine gültige Antwort liefert. AIRRS kann daraus Registerkarten bauen und Widgets vorladen. Ein visueller Rauchtest – „Sind Diagramme da?“ – besteht. Er beweist den Transport einer Antwort, nicht die beabsichtigte Auswahl.

Um beide Zustände zu trennen, wurden die vier von AIRRS beworbenen Ressourcenformen verwendet: AS327800, das Präfix 196.192.48.0/20, die Domain afrinic.net und der Ländercode ZA. Für jede Ressource wurden drei Antworten gesichert: ohne Profilangabe, mit dem wörtlichen AIRRS-Schlüssel amp;profile=afrinic und mit dem erwarteten profile=afrinic.

Vier Ressourcen, zwölf Antworten, eine klare Grenze

Bei AS327800 antwortete der Standardaufruf mit HTTP 200, status: ok und sieben Registerkarten. Der Aufruf mit amp;profile=afrinic lieferte ebenfalls 200, einen positiven Status und sieben Registerkarten. Nachdem volatile Hüllfelder entfernt waren, hatten beide normalisierten .data-Objekte exakt denselben SHA-256-Hash. profile=afrinic ergab dagegen HTTP 500, status: error, status_code: 500, ein leeres Datenobjekt und null Registerkarten.

Das Präfix 196.192.48.0/20 wiederholte die Aufteilung: Standard erfolgreich, wörtlicher Schlüssel erfolgreich und strukturell identisch zum Standard, korrekter Schlüssel fehlerhaft.

Bei afrinic.net und ZA blieb das Bild unverändert. Insgesamt stehen vier erfolgreiche Standardantworten, vier erfolgreiche wörtliche Aufrufe mit jeweils identischem normalisiertem Daten-Hash und vier 500-Antworten für das tatsächlich benannte AFRINIC-Profil.

Alle zwölf Antworten meldeten den RIPEstat-Build v0.11.15-2026.09.09 und die Pipeline 1415073. Gesichert wurden zudem individuelle Abfragekennungen, Zeitstempel, Registerkartenzahlen sowie Hashes der vollständigen und normalisierten Antworten. Das ist eine begrenzte, überprüfbare Beobachtung vom 11. September 2026, keine Erinnerung an den Eindruck einer Webseite.

In den Fehlerantworten steht data_call_status: supported. Dieses Feld darf nicht alleine gelesen werden. RIPEstats Dokumentation führt data_call_status, status und status_code getrennt. Eine unterstützte Aufrufart kann in einer konkreten Ausführung dennoch mit 500 und error scheitern. „Supported“ hebt den Fehlerstatus nicht auf.

Die Matrix trägt eine präzise, aber begrenzte Aussage. Für die vier Testressourcen änderte der von AIRRS gesendete Schlüssel die Standardstruktur nicht; das korrekt benannte Profil schlug fehl. Die serverseitige Ursache bleibt offen. Ebenso offen bleiben Beginn, Dauer, Verhalten im Jahr 2020, andere mögliche Ressourcen und der Zustand nach einem künftigen Release.

Nützliche Standarddaten sind kein Auswahlbeleg

Die sieben Registerkarten sind nicht automatisch falsch. Eine Standardstruktur kann wertvolle Registry-, Routing- und Messwerkzeuge enthalten. Nachdem die Seite zusammengestellt ist, greifen die einzelnen Widgets auf WHOIS, RIPE RIS, RIPE Atlas oder andere Quellen zu. Die Untersuchung hat weder eine konkrete Route noch ein Registry-Objekt oder einen Messwert als unrichtig bewertet. Sie belegt keinen allgemeinen Ausfall der Datenquellen.

Unbelegt bleibt die Herkunft der Zusammenstellung. Die Oberfläche sagt nicht, ob RIPEstat afrinic oder default ausgewählt hat, ob nach einem Profilfehler zurückgefallen wurde oder ob eine gespeicherte Struktur ausgeliefert wird. AFRINIC-Branding und afrikanischer Auftrag schließen diese Lücke in der Wahrnehmung. Nutzer halten die Seite für AFRINIC-konfiguriert, weil sie nach AFRINIC aussieht.

Möglicherweise sollen Standard- und AFRINIC-Profil identisch sein. Dann wäre der sichtbare Unterschied gering. Möglicherweise wählen sie andere Widgets, eine andere Reihenfolge oder einen anderen Kontext. Auch eine zuletzt bekannte Struktur wäre denkbar. Die vorliegenden Quellen entscheiden das nicht. Gerade deshalb sollte der tatsächlich verwendete Zustand ausgewiesen werden.

Ein Profil ist kein Gütesiegel für jede darunterliegende Tatsache. Es ist ein Vertrag über die Präsentation. Der Nachweis seiner Auswahl macht die Regionalansicht nicht wahrer als andere Ansichten. Er trennt lediglich drei Behauptungen: Die Seite trägt AFRINIC-Identität; der Client hat AFRINIC angefordert; der Server hat AFRINIC als Profil bestätigt. Gegenwärtig ist nur die erste unmittelbar sichtbar.

Für die von AIRRS angesprochenen Zielgruppen hat diese Trennung Folgen. Forschende übernehmen Screenshots in Methodenberichte. Regulierungsstellen vergleichen Länderseiten. Betreiber verwenden ASN- oder Präfixgrafiken in Planungen. Politische Stellen können die Zusammenstellung als regional kuratiert lesen. Ohne Auswahlbeleg reist die Grafik in ein Dokument, ihre Konfigurationsgeschichte jedoch nicht.

Sechs Jahre sind ein Prüfgrund, kein Schuldbeweis

Das erfasste Clientskript stammt aus dem Jahr 2020; die beobachteten RIPEstat-Antworten aus einem Build von September 2026. Der Abstand rechtfertigt einen dauerhaften Kompatibilitätstest an der Dienstgrenze. Er erklärt den Fehler nicht.

Die Quellen verraten nicht, ob profile=afrinic beim Start funktionierte, ob die Zeichenkette aus HTML übernommen wurde, ob der Profilname oder ein Schema wechselte oder ob 500 nur eine vorübergehende Serverlage war. Eine gebrochene Kompatibilitätszusage ist ebenfalls nicht dokumentiert. Last-Modified datiert die Datei, ersetzt aber kein vollständiges Bereitstellungsprotokoll.

Auch die Verantwortung lässt sich nicht einseitig verteilen. AFRINIC kontrolliert die AIRRS-Anfrage und kann die Rückfalllogik öffentlich erklären. RIPE NCC kontrolliert die Profilauflösung und Antwortsemantik von RIPEstat. Eine vollständige Korrektur dürfte Prüfungen auf beiden Seiten verlangen. Aus der Beobachtung folgt weder Manipulation noch Angriff, Routingvorfall oder Zusammenbruch der Quelldaten.

Die richtige Überwachungseinheit ist die Nahtstelle. Dass die Startseite lädt, ist kein ausreichender Test. Ein belastbarer Canary sendet je eine ASN, ein Präfix, eine Domain und ein Land mit explizitem Profil und prüft den deklarierten Auswahlwert, die geordnete Registerkartenliste, den Struktur-Hash und die Statusfelder.

Ein Auswahlbeleg statt einer großen Neuentwicklung

Die Unklarheit lässt sich ohne Portalneubau beseitigen. AIRRS könnte der Ergebnisseite oder einem öffentlichen Diagnosepunkt einen kompakten Profilauswahlbeleg hinzufügen.

Er würde Ressourcenart und kanonischen Ressourcenwert, den exakt gesendeten Parameternamen und den angeforderten Profilwert enthalten. Danach müsste RIPEstat das tatsächlich gewählte Profil ausweisen. Fällt die Auswahl auf den Standard, steht dort ausdrücklich default; ein leeres Feld darf nicht stillschweigend das AFRINIC-Branding erben.

Hinzu kommen Version oder normalisierter Hash der Seitenstruktur, die geordneten Tab- und Widgetkennungen, RIPEstat-Build, Abfragekennung und Zeitstempel sowie status, status_code und data_call_status. Nutzerhistorie, IP-Adresse oder sensible Betriebsdetails sind dafür nicht nötig.

Der Beleg muss auch die Rückfallregel erklären. Ist das benannte Profil nicht verfügbar, kann AIRRS die Seite mit einer klaren Meldung blockieren, die Standardstruktur sichtbar kennzeichnen oder eine letzte bekannte regionale Struktur samt Alter zeigen. Blockieren schützt die Herkunft, kostet aber Zugang. Ein gekennzeichneter Standard erhält Nutzen, verlangt aber Aufmerksamkeit. Eine gespeicherte Version wahrt Kontinuität, birgt aber Veraltungsrisiko. Entscheidend ist nicht eine universelle Option, sondern die sichtbare Entscheidung.

Schließlich gehört der jüngste erfolgreiche Canary für alle vier beworbenen Formen in den Beleg. Ein HTTP 200 allein ist schwach; geordnete Tabs und Hash erkennen stille Änderungen. Die Clientkorrektur belegt die richtige Frage. Eine erfolgreiche Profilantwort belegt die serverseitige Verfügbarkeit. Die erwartete Struktur belegt den inhaltlichen Vertrag. Keiner dieser Nachweise ersetzt die anderen.

Der Auswahlbeleg ist ein Vorschlag dieser Analyse, keine angekündigte Pflicht von AFRINIC oder RIPE NCC. Er soll eine kleine Implementierungsabweichung nicht dramatisieren. Er soll einer Oberfläche, die informierte Entscheidungen ermöglichen will, die fehlende Verbindung zwischen Ergebnis und ausgewählter Konfiguration geben.

Quellen