Zusammenfassung

  • RIPE NCC zufolge ergänzt RISwhois-rs eine Testsuite für einen Routensuchdienst, der zuvor keine hatte, und verkürzt den Aktualisierungszyklus von acht Stunden auf eine.
  • Die Frage bleibt konkret: Welche Präfixe und Origin-AS hat RIPE RIS an welchen Collectors und zu welchem Zeitpunkt beobachtet? Eine Testliste und ein Migrationsplan sind noch nicht veröffentlicht.

Alte Sprache, neuer Motor

whois -h riswhois.ripe.net 193.0.0.1 ist kein Befehl für die Bühnenshow. Er soll eine Antwort ins Terminal holen, bevor jemand das passende Dashboard gefunden hat. RIPE NCCs RISwhois bietet seit 2003 eine schnelle Abfrage der BGP-Daten, die RIPE-Route-Collectors empfangen. Die Ausgabe ähnelt RPSL, einem Format, das Netzbetreiber und vorhandene Werkzeuge kennen.

Am 26. Oktober stellte Sam van Kampen, Entwickler bei RIPE NCC, auf der RIPE 93 den Nachfolger RISwhois-rs vor. Laut dem offiziellen Tagesbericht wurde die neue Version in den vergangenen Monaten entwickelt. Die alte hatte keine Testsuite; das begrenzte die Weiterentwicklung. Das Team hat jetzt eine ergänzt und kann die Daten stündlich statt alle acht Stunden aktualisieren.

Der erste produktive Rust-Dienst von RIPE NCC ist ausgerechnet ein WHOIS-artiger Abfragedienst. Die sichtbare Bedienung trägt ein altes Gewand, darunter wurde der Motor erneuert. Wer den Code pflegt, kann Änderungen nun mit wiederholbaren Prüfungen begleiten, statt sich auf eine Handvoll manueller Abfragen zu verlassen.

Was RISwhois zurückgibt

RISwhois fragt beobachtete Routingdaten ab. Je nach Eingabe – IP-Adresse, Präfix oder ASN – kann die Antwort passende Präfixe, Origin-AS, beobachtende Collectors, Aktualisierungszeiten und die Zahl der RIS-Peers enthalten, die die Route gesehen haben. Die Option -R ergänzt RPKI-Origin-Validation-Informationen. Einige Traceroute-Werkzeuge können außerdem über einen WHOIS-Dienst jedem Hop eine ASN zuordnen.

Das Ausgabeformat gehört zum Produkt. Wer prüfen möchte, ob RIS eine Ankündigung empfangen hat, muss keine neue Weboberfläche lernen. Ein Kommandozeilenclient sendet seine Anfrage über Port 43 und erhält ein strukturiertes Objekt im RPSL-Stil. Skripte, Menschen und Diagnosewerkzeuge können denselben Zugang verwenden.

Schon die erste Ankündigung machte den Zweck klar. RIPE NCC beschrieb im November 2003 zehn Route-Collectors und mehr als 200 IPv4- und IPv6-Peers. RISwhois fasste aktuelle Routingtabellen-Snapshots zusammen und zeigte, wo ein Präfix auftauchte und welches AS es originierte. So wurde die Sicht der Collectors in einem Format abfragbar, das vorhandene Werkzeuge verstanden.

Die Antwort hat einen klaren Gegenstand: Was haben die teilnehmenden Collectors empfangen, an welchem Punkt und zu welcher Zeit? Betreiber können diese Beobachtung neben ihre eigenen Logs und Alarme legen. Die Ausgabe beschreibt die an die beteiligten Collectors gelieferten Routen; gerade diese externe Sicht macht sie für Untersuchungen brauchbar.

Aus acht Stunden wird eine

Der frühere Aktualisierungszyklus lag bei acht Stunden. Mit stündlichen Updates rücken die geplanten Snapshots näher zusammen. Während einer Routingänderung kann ein Team die Abfrage wiederholen, ohne den größten Teil einer Schicht auf den nächsten Datenlauf zu warten.

Das ändert den Takt einer Untersuchung. Betreiber sehen früher, ob eine neue Ankündigung die relevanten Collectors erreicht hat. Der RIS-Befund lässt sich mit einem jüngeren RPKI-Ergebnis vergleichen. Automatisiertes Monitoring kann auf einer kürzeren Datenuhr arbeiten. Der Fortschritt braucht kein Feuerwerk: Die nächste geplante Sicht liegt nicht mehr fast einen Arbeitstag entfernt.

Stündliche Updates sind kein Live-Stream. RIPE NCC bietet RIS Live separat für BGP-Nachrichten in nahezu Echtzeit an. RISwhois ist die kurze Abfrage über gesammelte Daten; RIS Live verfolgt eintreffende Nachrichten. Beide Dienste haben unterschiedliche Formen und Zeitmaßstäbe. Die veröffentlichte Änderung verkürzt acht Stunden auf eine.

Auch die Dateien dump und dump6 sind ein eigener Zugang. Laut aktueller Dokumentation werden sie auf Anfrage erzeugt und entsprechen den gleichnamigen RISwhois-Befehlen. Der Aktualisierungszeitpunkt des Dienstes verrät deshalb nicht automatisch, wann eine heruntergeladene Datei erzeugt wurde. Beide Zeitstempel gehören getrennt ausgewiesen.

Tests senken die Maut für Änderungen an alter Software

„Es gab keine Testsuite“ klingt nach einer Randnotiz, bis man die Schnittstelle betrachtet. RISwhois nimmt verschiedene Abfrageformen an, erzeugt strukturierte Antworten, hält Kompatibilitätsoptionen vor und kann RPKI-Felder ausgeben. Jedes Verhalten ist eine Stelle, an der eine Änderung einen älteren Client überraschen kann.

Eine Testsuite gibt dem Team einen Ort, um zu bewahrende Verhaltensweisen festzuhalten und nach jeder Änderung erneut zu prüfen. Für diesen Dienst wären etwa Adress- und Präfixabfragen, exakte und spezifischere Treffer, IPv4 und IPv6, dauerhafte Verbindungen, Zeitstempel, Peer-Zahlen, RPKI-Felder und fehlerhafte Eingaben geeignete Fälle. RIPE NCCs Tagesbericht nennt die tatsächlichen Tests nicht; damit bleibt offen, welche Teile der Kompatibilität sie abdecken.

Rust ist Teil derselben Wartungsgeschichte. RIPE NCC nennt RISwhois-rs seinen ersten produktiven Rust-Dienst und sagt, die Sprache senke die Hürde, Dinge ordentlich umzusetzen. Der Bericht nennt Geschwindigkeit, Wartbarkeit und Erweiterbarkeit als Ziele. Einen gemessenen Latenzvergleich, ein Repository oder Testergebnisse veröffentlicht er nicht.

Die sichtbare Betriebsänderung ist die stündliche Aktualisierung. Die weniger sichtbare ist ein Satz wiederholbarer Prüfungen, mit denen kommende Änderungen günstiger zu prüfen sind. Bei einem Dienst, der zwei Jahrzehnte überdauert hat, schafft diese unscheinbare Arbeit Platz für den nächsten Entwicklungsschritt.

Die nächste Versionsnotiz sollte den Beleg mitliefern

RISwhois hält seit mehr als zwei Jahrzehnten ein schlichtes Versprechen: Eine Frage in alter Syntax liefert eine knappe Sicht auf beobachtete Routen. RISwhois-rs behält diesen Zugang, erneuert die Implementierung und verkürzt den Aktualisierungsabstand.

Die nächste RIPE-NCC-Mitteilung sollte das Produktionsdatum nennen, den Änderungsbedarf für Clients erklären, die von den Tests abgedeckten Abfragen und Ausgaben aufführen und gemessene Antwortzeiten vergleichen. Eine versionierte Kompatibilitätsmatrix gäbe Betreibern Gelegenheit, ihre Parser vor dem Ende des alten Dienstes zu prüfen. So wird aus „Wir haben es neu geschrieben“ ein überprüfbarer Änderungsnachweis.

Primärquellen: RIPE NCCs RISwhois-Ankündigung von 2003 · RISwhois-Dokumentation · Sam van Kampens RIPE-93-Sitzung · RIPE-93-Tagesbericht, veröffentlicht am 26. Oktober 2026.