Zusammenfassung

  • Das historische Skript rpkic_run.sh verwendet in beiden Aktionen rpkic_rpkiv5_cache, verschiebt dessen Ziel aber von /var/cache/rpki-client nach /root/cache.
  • Ein benanntes Docker-Volume kann fortbestehen, ohne dass seine Einbindung den tatsächlich benutzten Cache-Pfad der Anwendung nachweist. Dieser Pfad wurde hier nicht geprüft.
  • Image-Zeichenfolge, gemeinsame Argumente und Vertrauensanker-Einbindung bleiben gleich. Die drei anderen untersuchten Startskripte behalten ihre jeweiligen Ziele bei.
  • Untersucht wurde am 14. September 2026 ein Commit vom 1. April 2024. Es fand kein Container- oder Validatorlauf statt; weder eine neue Migration noch ein Datenverlust oder Produktionsfehler ist belegt.

Der Vergleich beginnt vor dem Dienstwechsel

Ein Migrationstest muss nicht nur wissen, wohin er die Anwendung schickt. Er muss auch wissen, was die Anwendung dorthin mitnimmt. Das README im öffentlichen LACNIC-Repository beschreibt genau diese Voraussetzung: Zuerst läuft die Software gegen den bisherigen Dienst, bis ein erster vollständiger Durchgang den Cache gefüllt hat. Danach wird der Container gestoppt und die Aktion für den Ersatzdienst gestartet. Der zuvor aufgebaute Zustand soll erhalten bleiben.

Die Software übernimmt dabei die Rolle einer vertrauenden Partei: Sie verarbeitet RPKI-Material und erzeugt validierte Routinginformationen. Ein solcher Prozess mit bereits erworbenem Zustand untersucht eine andere Ausgangslage als ein Prozess, der alles von Grund auf entdeckt. Beide Versuche können sinnvoll sein. Ein bewusst frischer Start ist jedoch nicht ohne Weiteres der im README beschriebene Vergleich mit mitgeführtem Cache. Die Bezeichnung muss zur nachgewiesenen Ausgangslage passen.

Ein persistentes Docker-Volume ist ein vernünftiges Mittel, Daten über das Ende eines Containers hinaus zu tragen. Im rpki-client-Startskript heißt es in beiden Aktionen rpkic_rpkiv5_cache. Die Aktion current bindet es an /var/cache/rpki-client. Die Aktion rpkiv5 bindet denselben Namen an /root/cache. Die Quellseite der Speicherzuordnung bleibt also konstant, während sich ihre Zielseite innerhalb des Containers ändert. Diese Differenz ist unmittelbar im veröffentlichten Code sichtbar.

Die Beobachtung ist kleiner als ein Fehlerbericht. Sie belegt weder ein gelöschtes Volume noch einen verlorenen Cache noch einen gescheiterten Dienstwechsel. Sie belegt eine andere Anschlusskoordinate im beschriebenen Versuch. Ob die Anwendung ihren alten Zustand an dieser Koordinate tatsächlich nutzt, hängt von der ausgewählten Image-Konfiguration ab. Genau diese Beziehung ist mit dem Startskript allein nicht festgestellt. Ein Datenverlust wäre eine zusätzliche Behauptung, für die hier keine Laufbeobachtung vorliegt.

Was Docker erhält und was Docker nicht erklärt

Die offizielle Dokumentation unterscheidet die Quelle eines Volumes vom Zielpfad im Container. Ein benanntes Volume kann den Container überleben, der es benutzt hat, und anschließend von einem anderen Container verwendet werden. Sein Name wählt den Speicher aus; sein Zielpfad legt fest, an welcher Stelle der Inhalt im Container erscheint. Welches Verzeichnis ein Programm tatsächlich als Cache behandelt, ist damit noch nicht automatisch bestimmt.

Der gleiche Name ist deshalb positive Evidenz. Das Skript wählt für die zweite Aktion nicht ausdrücklich einen anderen Speicher. Ein geänderter Zielpfad löscht dessen Inhalt auch nicht von selbst. Der alte Zustand kann auf der Quellseite weiterhin vorhanden sein. Daraus folgt aber nicht, dass die Anwendung ihn an ihrer erwarteten Stelle sieht. Erhalten, eingebunden und benutzt sind drei verschiedene Aussagen. Keine sollte stellvertretend für die beiden anderen ausgegeben werden.

Eine interne Einstellung, ein Verzeichnisalias oder die Organisation des Einstiegspunkts könnte beide Zielpfade für die Anwendung gleichwertig machen. Ebenso könnte das Image einen weiteren effektiven Cache-Pfad wählen. Keine dieser Möglichkeiten wurde hier überprüft. Es wurde weder ein Image heruntergeladen noch dessen Einstiegspunkt, Berechtigungen oder symbolische Verknüpfungen untersucht. Deshalb bleibt die Wiederverwendung offen. Die gegenteilige Behauptung eines Starts ohne alten Cache bleibt ebenfalls offen und darf nicht als Befund erscheinen.

Docker erläutert außerdem, dass eine Einbindung über einem bereits gefüllten Containerverzeichnis dessen ursprünglichen Image-Inhalt verdecken kann. Ein zunächst leeres Volume kann beim üblichen Kopierverhalten vorhandene Containerinhalte aufnehmen. Diese Plattformregeln zeigen, warum der Zielpfad eine relevante Versuchsangabe ist. Sie zeigen nicht, was das ausgewählte Image enthielt oder wie diese rpki-client-Version ihren Cache tatsächlich behandelte. Allgemeine Speicherregeln ersetzen keinen versionsbezogenen Nachweis der Anwendung.

Ein historisches Werkzeug ist keine aktuelle Betriebsmeldung

Die untersuchten Dateien gehören zum unveränderlichen Commit fdbecab2890e0da2f9a393ac4be2659d14f54ca2 vom 1. April 2024. Gelesen wurden sie am 14. September 2026. Diese Datumsgrenze ist Teil des Befunds. Ein heute erreichbares Repository macht ein damaliges Prüfskript nicht zur Ankündigung einer neuen Migration. Es beschreibt auch nicht die heutige Produktionsflotte von LACNIC und rekonstruiert keine tatsächlich ausgeführten Container der damaligen Umstellung.

Das README erklärt, dass die Ersatzaktion eine Hostnamen-Zuordnung nutzt, um den neuen RRDP-Dienst anzusprechen. RRDP ist die in den Skripten benannte Oberfläche zum Abruf von Repository-Material. Anschließend sollen Ausgaben manuell verglichen werden; als Beispiel nennt das Dokument die Anzahl gültiger Route-Origin-Payloads, kurz VRPs. Der geplante Dienstwechsel ist damit verständlich. Der Text ist aber eine Versuchsabsicht und kein Beleg für einen abgeschlossenen, beobachteten Vergleich.

Auch der Hinweis auf eine damals noch nicht replizierte untergeordnete Zertifizierungsstelle bleibt historisch. Er kann nicht als Aussage über den heutigen Replikationsstand übernommen werden. Dasselbe gilt für Adressen und DNS-Zuordnungen in den Dateien: Sie sind veröffentlichte Eingaben eines damaligen Werkzeugs, keine in dieser Recherche kontaktierten Dienste. Aus ihnen eine gegenwärtige Störung oder einen bestimmten früheren Ablauf abzuleiten, würde den überprüften Stoff um unbeobachtete Betriebsbehauptungen erweitern.

Das untersuchte Quellenpaket enthält keinen abgeschlossenen paarweisen Laufnachweis, der den effektiven Cache-Zugriff vor und nach dem Wechsel feststellt. Das ist nicht die Behauptung, intern sei niemals getestet worden. Es trennt die öffentliche Anweisung von der benötigten Ausführungsbeobachtung. Der Code zeigt Namen, Pfade und Argumente. Welcher Zustand in einem konkreten Lauf vorhanden war und gelesen wurde, benötigt eine andere Art von Evidenz.

Die konstanten Eingaben sind Gegenbelege

Beide rpki-client-Aktionen wählen die Image-Zeichenfolge rpki/rpki-client:8.2. Beide binden das lokale Vertrauensanker-Verzeichnis an /etc/tals, verwenden die gemeinsame Argumentfolge -s 480 -c -v -v -v und behalten die gemeinsamen Optionen für Hintergrundbetrieb und eigenes DNS bei. Andere Image-Versionen erscheinen als Kommentare. Sie sind keine aktiven Auswahlentscheidungen dieser beiden Aktionen und dürfen nicht zu einer angeblich ausgeführten Versionsänderung zusammengesetzt werden.

Der Versuch verändert also nicht wahllos jede Bedingung. Image-Auswahl, Vertrauenseingaben, gemeinsame Argumente und die Quelle des Volumes bleiben im Code gleich. Gerade diese Konstanten begrenzen die Kritik auf den abweichenden Zielpfad und die noch nicht belegte Beziehung zum Anwendungscache. Ein Nachweis, dass das Image beide Ziele gleichwertig behandelt, würde die Sorge verringern. Ein belastbarer Text muss diese Möglichkeit behalten, auch wenn sie seine Schlussfolgerung weniger dramatisch macht.

Die Image-Zeichenfolge ist allerdings kein geprüftes Image mit bestätigtem Digest und bekanntem Inhalt. Eine solche Prüfung fand nicht statt. Auch den einzelnen Kommandooptionen wird ohne zusätzliche versionsspezifische Evidenz keine Laufsemantik zugeschrieben. Festgestellt ist ihre Gleichheit als Zeichenfolgen. Das ist ein engerer Befund als gleiche Ausführung, aber ein echter positiver Kontrollpunkt. Die Quellen sollen weder weniger noch mehr beweisen, als sie tatsächlich zeigen.

Die Ersatzaktion fügt eine Zuordnung des RRDP-Hostnamens zu 96.126.99.186 hinzu. Diese Adresse wurde nicht angesprochen. Ein anderes Dienstziel gehört zum Zweck des Migrationsversuchs. Ein anderes Speicherziel im Container ist eine davon unterscheidbare Eingabe. Falls Letzteres den effektiven Anfangszustand verändert, könnte eine spätere Ausgabe beide Änderungen widerspiegeln. Ob das tatsächlich geschieht, lässt sich dem Startskript nicht entnehmen. Die Bedingung bleibt ausdrücklich hypothetisch.

Die drei Nachbarn verhindern ein Flottenurteil

Das FORT-Skript behält /root/cache in seinen beiden Aktionen bei. Sein Ersatzlauf fügt RRDP- und Repository-Hostnamen hinzu. Das neuere Routinator-Skript behält /home/routinator/.rpki-cache; die Variante für Versionen vor 0.12 behält dieses Ziel innerhalb ihres eigenen Paares ebenfalls bei und wählt die Image-Zeichenfolge v0.10.1. Dies sind Vergleiche veröffentlichter Startanweisungen. Sie bescheinigen keinem der drei Programme eine tatsächlich gelungene Cache-Wiederverwendung.

Trotzdem zeigen sie, dass eine Verschiebung des Ziels keine allgemeine Voraussetzung der im Repository beschriebenen Migration ist. Die sichtbare Abweichung gehört zum rpki-client-Paar. Daraus wird weder ein Urteil über alle LACNIC-Validatoren noch eine Behauptung über Betreiberinstallationen oder Produktionscontainer. Die institutionelle Herkunft einer Datei vervielfacht ihre Aussagekraft nicht. Der angemessene Gegenstand ist eine bestimmte Zuordnung in einem bestimmten historischen Werkzeug.

Die benachbarten Dateien enthalten weitere Eingaben, die ein Laufnachweis festhalten sollte, ohne daraus eine neue Fehlerthese zu bauen. Im neueren Routinator-Skript nutzt die aktuelle Aktion gemeinsame Serverargumente mit --refresh=120. Die Ersatzaktion schreibt eine getrennte Argumentfolge ohne diese ausdrückliche Option. Ihr effektiver Standardwert wurde nicht festgestellt. Daraus folgt hier weder eine beobachtete Aktualisierungsverzögerung noch ein unerwartetes Verhalten. Es ist eine zusätzliche Bedingung, keine Laufdiagnose.

Die dnsmasq-Datei enthält Ersatzzuordnungen für RRDP und Repository sowie auskommentierte ältere Zuordnungen. Das README spricht auch über die Änderung der DNS-Option, falls dieser Dienst nicht verwendet wird. Welche DNS-Instanz tatsächlich lief und welche Antwort ein Referenzlauf bekam, ist damit nicht belegt. Eine Geschichte, wonach der Ausgangslauf schon auf den Ersatzdienst zeigte, wäre eine weitere ungesicherte Annahme. Sie würde die klar beobachtete Speicherfrage unnötig verwischen.

Gleiche Größe ist nicht gleicher Zustand

Die im README vorgeschlagene VRP-Zählung ist als erste Sichtprüfung nachvollziehbar. Doch zwei Mengen können gleich viele Einträge und unterschiedliche Mitglieder haben. Diese gewöhnliche Vergleichslogik ist kein Bericht über tatsächlich unterschiedliche Ausgaben. Sie begrenzt nur, was eine Anzahl beweist. Selbst eine festgestellte Mengenübereinstimmung würde nicht allein zeigen, dass die zweite Anwendung dieselbe vorherige Cache-Lage benutzt hat. Ergebnis und Herkunft brauchen getrennte Beobachtungen.

Für einen Vergleich mit gefülltem Cache müssen Speicherquelle, Containerziel, effektiver Anwendungspfad und beobachtetes Ergebnis miteinander verbunden sein. Ein gezielter Test mit frischem Zustand kann anders heißen und anders bewertet werden. Das Ziel ist nicht, jeden Versuch zu einer umfassenden Sicherheitszertifizierung auszubauen. Es ist, der konkreten Aussage eine konkrete Grundlage zu geben. Der Name des Volumes darf dabei die fehlende Verbindung nicht stellvertretend herstellen.

Eine reine Angleichung der beiden Pfadzeichenfolgen könnte die Anweisung verständlicher machen, würde aber die Ausführungsfrage nicht automatisch lösen. Der richtige Zielpfad hängt von der Anwendung ab. Zuerst sollte ihre Beziehung zum Volume erklärt werden; danach lässt sich entscheiden, ob die Anweisung korrigiert werden muss. Ebenso beweist eine spätere Korrektur keinen früheren Lauf. Der Quellenstand und die Laufgeschichte müssen auch nach einer Verbesserung getrennt bleiben.

Quellen

Die Basis bilden das historische README, das rpki-client-Skript, das FORT-Skript, das neuere Routinator-Skript, die ältere Variante, die DNS-Konfiguration und die Docker-Dokumentation. Sieben Dokumente von zwei Publikationsorten, nicht sieben unabhängige Untersuchungen. Kein Container-, Bereinigungs- oder Validatorbefehl wurde ausgeführt.