Zusammenfassung

  • Der Whois-Commit 252681a vom 10. September stellt die Quellenauflistung und Namensprüfung des NRTMv4-Dienstes auf NrtmSourceSlaveDao und damit auf den Lese-Datasource um.
  • Der DAO für die letzte Benachrichtigung kann nach einem leeren Slave-Ergebnis den Master abfragen. Zuvor muss der Dienst die Quelle aber bereits aus dem replizierten Katalog aufgelöst haben.
  • Daraus folgt weder ein Produktivbetrieb noch ein beobachteter Replikationsverzug. Ein Zulassungsbeleg für neue Quellen würde genau den Übergang absichern und den Leseweg beibehalten.

„Es gibt einen Fallback“ klingt wie eine Ende-zu-Ende-Eigenschaft. In Wirklichkeit hat jeder Fallback einen Anfang. Der RIPE-NCC-Commit 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855 macht sichtbar, dass dieser Anfang hinter einer anderen Entscheidung liegt.

Der Commit wurde am 10. September 2026 um 10:56 UTC geschrieben und trägt den Titel „Use read-only (slave) source DAO in NRTMv4 Service“. Drei Dateien ändern sich. NrtmSourceDao wird als @Primary markiert. Die neue, zwanzig Zeilen lange Klasse NrtmSourceSlaveDao erbt seine Abfragen, übergibt jedoch nrtmSlaveDataSource. NrtmService erhält fortan diese Unterklasse.

Die stärkste Verteidigung ist naheliegend. Ein Quellenkatalog umfasst wenige, selten veränderte Einträge. Öffentliche Abrufe sind dagegen häufig. Solche Lesevorgänge auf eine Replik zu verlagern, schont den Schreibpfad und trennt Zuständigkeiten. Auch NRTMv4 selbst ist beweisorientiert: signierte Update Notification Files, Hashes für Snapshots und Deltas, Sitzungskennungen und Versionen. Der Benachrichtigungs-DAO versucht bei einem leeren Slave-Ergebnis sogar bereits den Master.

Die Architektur ist also nicht kontrolllos. Die offene Stelle ist kleiner: Der spätere Rückfall kann eine Quelle nicht retten, die am vorgelagerten Katalogtor abgewiesen wurde.

Derselbe Leseweg listet und legitimiert Namen

Der bestehende NrtmSourceDao fragt id und name aus der Tabelle source ab. Normalerweise wird er mit nrtmMasterDataSource gebaut. Seine neue Unterklasse führt dieselbe Logik mit dem Slave-Datasource aus. Der Dienst nutzt diese Liste auf zwei Wegen.

Auf der Wurzelseite wird für jede von getSources() gelieferte Quelle ein Link zum Update Notification File erzeugt. Fehlt ein Eintrag in der Lesesicht, fehlt er auch in dieser Übersicht.

Bei einem direkten Abruf ist die Liste nicht nur Navigation, sondern Zulassungsinstanz. Für eine Benachrichtigungsdatei führt der Dienst findLastNotification(getSource(source)) aus. getSource() liest den Katalog, filtert nach dem Namen und wirft „Invalid source“, wenn keine Zeile passt.

Java wertet das Argument vor dem Methodenaufruf aus. Erst wenn getSource() ein Objekt liefert, beginnt findLastNotification(). Scheitert die replizierte Namensprüfung, erhält der rückfallfähige DAO keine Gelegenheit.

Seine eigene Logik ist sorgfältig. UpdateNotificationFileSourceAwareDao sucht zuerst den Payload. Ist er nicht vorhanden und der aktuelle SourceContext vom Typ SLAVE, erzeugt der Code die korrespondierende Master-Quelle, schaltet den Kontext vorübergehend um, fragt erneut und stellt den ursprünglichen Kontext in finally wieder her. Damit ist „Quelle bekannt, jüngste Benachrichtigung in der ersten Sicht noch leer“ abgedeckt.

Nicht abgedeckt ist „Quelle in der ersten Sicht noch unbekannt“. Das ist keine Fehlfunktion des Fallbacks, sondern seine definierte Position. Auch die Quellübersicht nutzt ihn nicht.

Ein Aktivierungsrand, kein Befund über den Dauerbetrieb

Bei lange bestehenden Quellen können alle Katalogzeilen längst repliziert sein. Dann akzeptiert der Dienst den Namen wie erwartet, und die zweite Abfrage behält ihren Rückfall. Die erfassten Dateien enthalten weder Messwerte zur Replikation noch eine beobachtete Fehlermeldung oder einen betroffenen Spiegel.

Relevant wird die Reihenfolge bei einer neuen Quelle, einer wiederhergestellten Zeile, der Rückkehr eines Datasources oder einer Konfigurationsänderung. Für eine kurze Zeit könnte der Master den Namen kennen, während der vom Dienst gelesene Katalog ihn noch nicht kennt. Unter dieser Voraussetzung würde die Startseite keinen Link erzeugen und ein direkter Abruf vor der Master-Abfrage des Payloads abbrechen. Die Voraussetzung ist möglich, aber nicht belegt.

Ebenso unbelegt ist, dass dieser Commit produktiv läuft. Ein öffentlicher Branch ist keine Release-Zuordnung und kein Deployment-Nachweis. Aussagen über Ausfall, veraltete IRR-Daten, Datenverlust oder eine Sicherheitslücke wären daher falsch präzise.

Repliken tauschen unmittelbare Gleichheit gegen Kapazität und Isolation. Das ist eine normale Systemeigenschaft. Entscheidend ist, welche Entscheidung auf welcher Sicht beruhen darf. Wiederholte Abfragen eines stabilen Katalogs können einen anderen Vertrag tragen als der einmalige Akt, die öffentlich akzeptierte Namensmenge zu erweitern.

Signaturen schützen Dateien, nicht die interne Freigabe

Zum Erfassungszeitpunkt führte der IETF Datatracker draft-ietf-grow-nrtm-v4 als Revision 11. Der Entwurf beschreibt die einseitige Synchronisation von IRR-Datensätzen über HTTPS. Eine Veröffentlichung besteht aus einem Update Notification File, einem aktiven Snapshot und null oder mehr Deltas.

Die Benachrichtigung ist im JSON-Web-Signature-Format. Ein Client kennt URL, IRR-Datenbankname und öffentlichen Schlüssel. Er prüft den Quellennamen, die Signatur und die SHA-256-Hashes der referenzierten Dateien. Eine session_id begrenzt die Versionsfolge; ändert sie sich, muss der Client vom aktuellen Snapshot neu laden, statt eine nicht mehr gesicherte Delta-Kette fortzuschreiben.

Diese Mechanismen beantworten wichtige Fragen: Wer hat die Benachrichtigung signiert? Entspricht die Datei der signierten Referenz? Gehören Versionen zur selben Sitzung? Wann ist ein vollständiger Neustart nötig?

Sie können nicht bezeugen, ob die interne Katalogzeile vor der Aktivierung auf dem HTTP-Leseweg angekommen war. Wird ein Name vorher abgewiesen, erreicht der Client das kryptografisch prüfbare Objekt nicht. Umgekehrt wäre es unsinnig, Datenbankhosts oder Replikationsstände in das Drahtprotokoll zu tragen. Die fehlende Aussage gehört in den Betriebsprozess des Herausgebers.

Ein Zulassungsbeleg statt eines globalen Rückbaus

Der kleinste passende Kontrollgegenstand ist ein Quellenkatalog-Zulassungsbeleg. Er darf intern bleiben. Er soll nicht Infrastruktur offenlegen, sondern die Abfolge beweisen.

Zu erfassen wären Quellenname und Rollout-Generation, Freigabe oder Erstellung auf der Schreibseite, vorgesehener Service-Datasource und Zeitpunkt beziehungsweise Readiness-Marke, zu der diese Sicht den Eintrag beobachtet. Danach folgen der erste erfolgreiche Abruf einer gültig signierten Benachrichtigung über den tatsächlichen Serviceweg, beobachtete Sitzung und Version sowie ein Verweis auf den Signaturschlüssel.

Eine Prüfung der Wurzelliste und eine des direkten Pfads zeigen die zwei Nutzeransichten. Freigebender, Aktivierungszeit, Rückrollbedingung und Nachfolgebeleg liefern Verantwortlichkeit. Interne IDs, Hostnamen, Offsets und Zugangsdaten müssen dabei weder im öffentlichen noch im breiter zugänglichen Datensatz stehen.

Die Reihenfolge lautet: auf der Schreibseite genehmigen; in der für NrtmService vorgesehenen Lesesicht beobachten; die erste signierte Benachrichtigung genau über diesen Weg validieren; erst dann aktivieren. Bleibt die Sicht hinter einer festgelegten Frist zurück, wird die Aktivierung gehalten oder ein ausdrücklich genehmigter, befristeter Ausweichweg benutzt.

Auch Tests sollten die beiden Zustände auseinanderhalten. Test eins zeigt die neue Quelle nur dem Master und prüft die gewählte Zulassungspolitik. Test zwei zeigt die Quelle beiden Seiten, lässt aber den neuesten Benachrichtigungs-Payload in der Lesesicht fehlen und prüft den vorhandenen Rückfall. So kann eine spätere Änderung nicht versehentlich den falschen Beweis als ausreichend behandeln.

Der Beleg bewahrt den Nutzen der Leseverlagerung. Ein seltener Zustandswechsel erhält einen zusätzlichen Kontrollschritt; jeder gewöhnliche Abruf bleibt günstig. Kontrolle sitzt damit dort, wo sich die erlaubte Namensmenge ändert.

Quellen