Zusammenfassung

  • RIPE Whois 1.124 bietet historische Fassungen nun auch als Klartext an. Zurückgegeben wird ein gefiltertes historisches Objekt, kein vollständiges Archiv der ursprünglichen Änderungsanfrage.
  • Im untersuchten Code kehrt der Klartextzweig zurück, bevor der strukturierten Antwort ausdrücklich die historische Revisionsnummer zugewiesen wird. Ein Archiv sollte deshalb den Anfragekontext mitbewahren. Über sämtliche HTTP-Header sagt dieser Befund nichts aus.

Eine Textdatei kann lange lesbar bleiben. Der Objektschlüssel ist vorhanden, die Beschreibung ebenfalls. Doch wenn beim Speichern die Anfrage-URI verloren geht: Woran erkennt ein späterer Leser die abgerufene Revision und die Bedingungen des Abrufs? Das ist ein angenommenes Archivierungsszenario, kein in dieser Recherche entdeckter falscher Beleg. Die neue historische Klartextantwort von RIPE gibt dem Problem einen konkreten technischen Ort.

Die Veröffentlichung von Whois 1.124 nennt Klartextunterstützung für die REST-Schnittstelle historischer Fassungen. Die GitHub-Veröffentlichung datiert auf den 12. August 2026; RIPEs offizieller Veröffentlichungsverlauf nennt den 13. August für den Release Candidate und den 27. August für den Produktionseinsatz. Dieser Beitrag untersucht die Änderung im September. Er meldet keinen neuen September-Release und behauptet nicht, sämtliche laufenden Installationen hätten diesen Stand. Seine Grundlage sind der festgehaltene Veröffentlichungscode und offizielle Dokumentation, nicht ein Testabruf gegen das Produktivsystem.

Klartext ist eine vernünftige Option. Netzbetreiber kennen RPSL; ohne zusätzliche Antwortstruktur lassen sich Objekte leichter mit Kommandozeilenwerkzeugen lesen und vergleichen. Eine nützliche Darstellung muss nicht zugleich eine vollständige Beweissammlung sein. Das Risiko entsteht, wenn derjenige, der sie archiviert, die zweite Funktion stillschweigend voraussetzt.

Die Auswahl der historischen Fassung beginnt mit der Anfrage. WhoisVersionService baut eine Abfrage mit SELECT_TYPES und SHOW_VERSION; letzterem wird die angeforderte historische Nummer übergeben. Die Verarbeitung wählt das zugehörige RPSL-Objekt. Datumsangaben und Bemerkungen im Objekt können sachlich wichtig sein. Sie sind aber nicht automatisch derselbe Identifikator wie die Revisionsnummer in der Antwortstruktur.

Auch eine ausgewählte historische Fassung wird nicht ohne Verarbeitung zurückgereicht. VersionQueryExecutor wendet Filter für E-Mail, Authentifizierung, changed und persönliche Informationen an, bevor die ausgewählte Revision in das Rückgabeobjekt verpackt wird. Der Abruf liefert also ein nach diesen Regeln sichtbares historisches Objekt. Er verspricht keine ungekürzte Kopie der damaligen HTTP-Anfrage, der Aktualisierung per E-Mail oder sämtlicher interner Vorgangsunterlagen.

Filterung ist deshalb nicht als Beschädigung der Geschichte zu bezeichnen. Datenschutz und der Schutz von Authentifizierungsinformationen sind legitime Gründe für eine eingeschränkte öffentliche Darstellung. Ebenso wenig folgt daraus, dass jedes Feld zwangsläufig verändert wird oder ein zurückgegebener Text niemals mit einer damaligen Einreichung übereinstimmen könnte. Entscheidend ist die Grenze des Angebots: Eine historische Objektfassung ist kein zugesichertes Originalarchiv der Transaktion.

Danach trennen sich die Darstellungswege. Enthält Accept den Wert text/plain, gibt der Dienst getRpslObject().toString() zurück. Dieser Rücksprung liegt vor dem strukturierten Mapping und vor WhoisObject.setVersion, das dem Objekt ausdrücklich die historische Revisionsnummer zuweist. Der Klartextkörper durchläuft diese Zuweisung der strukturierten Antwort nicht.

Der Befund gilt für diesen Weg zur Erzeugung des Antwortkörpers. Er ist keine Prüfung aller Interzeptoren, Proxys und HTTP-Header. Die ursprüngliche Anfrage-URI kann weiterhin Objekt und angeforderte Revision verbinden. Wer URI und Text zusammen archiviert, verliert diese Zuordnung nicht zwangsläufig durch die Wahl von Klartext. Vom Körper auf jede mögliche Kontextquelle zu schließen wäre zu weitgehend.

Der strukturierte Zweig übergibt den ausgewerteten Parameter unformatted an das serverseitige Attribut-Mapping und setzt die historische Revision des Objekts. Die äußere Antwort kann außerdem Softwareversion, Fehler und Nutzungsbedingungen enthalten. Die historische Objektnummer und die Version des Dienstprogramms beantworten verschiedene Fragen: Welche Fassung wurde gewählt, und welche Implementierung erzeugte die Darstellung? Eine einzige Spalte „Version“ kann diesen Unterschied verdecken.

unformatted bedeutet auch nicht „ursprüngliche Anfrage wiederherstellen“. Im untersuchten Weg betrifft es das Mapping strukturierter Attribute. Klartext kehrt bereits vor diesem Mapper zurück. Der Parameter hebt die vorherigen Filter nicht allgemein auf, holt keine ursprüngliche Aktualisierungs-E-Mail zurück und belegt keine Änderungsbefugnis. Unformatiert ist kein Synonym für ungefiltert.

Die praktische Archivierung kann schlicht bleiben: neben dem Körper die URI, Datenbankquelle, Objekttyp und Schlüssel, angeforderte Revision, Accept und unformatted, Abrufzeit, einschlägige Header sowie Darstellungsform und Hash aufbewahren. Das ist ein Vorschlag für Nutzer, keine hier behauptete neue Vorgabe von RIPE. Teams können unterschiedliche Dateiformate wählen; die Identifizierung sollte nicht allein am Dateinamen oder am Gedächtnis hängen.

Ein Hash belegt die Unverändertheit gespeicherter Bytes. Er ersetzt keine verworfenen Anfrageinformationen und beweist nicht die damalige Autorisierung. Sollten sich Darstellung oder Filter künftig ändern, könnten sichtbare Bytes derselben historischen Revision anders ausfallen. Das ist ein Vergleichsszenario, kein hier beobachteter Manipulationsfall und kein Nachweis einer Ressourcenänderung.

Die Klartextfunktion macht die Arbeit bequemer. Erst die Behauptung, sie beweise ohne weitere Unterlagen die vollständige ursprüngliche Einreichung, Befugnis oder Ressourcenrechte, überlädt sie. Der Antwortkörper darf leicht sein. Für die Informationen, die ihn einer Anfrage zuordnen, muss das Archiv trotzdem einen Platz vorsehen.

Quellen

  1. Veröffentlichungshinweise zu RIPE Whois 1.124
  2. Offizielle RIPE-Database-Dokumentation mit Veröffentlichungsverlauf
  3. WhoisVersionService im festgehaltenen Release-Commit
  4. Ausführung historischer Abfragen und Filterreihenfolge
  5. Serverseitiger Attribut-Mapper
  6. Objekt-Mapper der strukturierten Antwort
  7. Rückgabeobjekt mit historischem RPSL