Export des Registry-Zustands: So werden Einträge zu Internet-Nummernressourcen wiederherstellbar

Ein nützlicher Export ermöglicht es einem anderen Betreiber, den dokumentierten Zustand und seine Historie zu überprüfen. Eine Kopie aufzubewahren ist nur der Anfang; auch die Übergabe muss verständlich und testbar sein.

Solange eine Registry verfügbar ist, kann eine Internet-Nummernressource wie eine einfache Datenabfrage erscheinen. Man fragt ein IP-Präfix oder die Nummer eines autonomen Systems ab und erhält einen Datensatz. Dieser Datensatz ist nützlich, aber er zeigt nur einen Ausschnitt eines umfassenderen Zustands: wen die Registry anerkannte, was sich geändert hat, welche Dienste delegiert wurden, welche Routing-Autorisierungen bestanden und welche Nachweise die aktuelle Antwort stützen.

Die schwierigere Frage stellt sich, wenn die Registry nicht verfügbar, umstritten oder kompromittiert ist oder ersetzt wird. Kann der legitime Zustand der Ressource dann noch von jemandem verstanden und überprüft werden, der weder über die ursprüngliche Datenbank noch über die internen Verfahren verfügt?

Die Kontinuitätsfrage: Wenn das aktuelle Registry-System morgen nicht mehr antwortet, welche Informationen bräuchte ein legitimer Inhaber oder Nachfolger, um den letzten überprüften Zustand zu rekonstruieren, ohne einen neuen zu erfinden?

Zunächst drei verschiedene Zustände trennen

Viele Diskussionen über Registrys werden unübersichtlich, weil drei unterschiedliche Fragen als eine behandelt werden:

• Registry-Zustand: was eine zuständige Stelle aktuell über die Ressource, den anerkannten Inhaber, Kontakte, Ereignisse, Delegation und Status verzeichnet.
• Betriebszustand: wie die Ressource in der Praxis genutzt wird, einschließlich Reverse DNS, Anbieterbeziehungen und Dienstkontinuität.
• Routing-Zustand: welches autonome System eine Route als Ursprung ankündigt und ob die betreffende Routing-Autorisierung gültig ist.

Diese Zustände können übereinstimmen, müssen sich aber nicht gleichzeitig ändern. Ein Präfix kann zwischen Anbietern wechseln, während sein anerkannter Inhaber derselbe bleibt. Ein Registry-Eintrag kann korrekt sein, während eine Route falsch konfiguriert ist. Eine Routing-Autorisierung kann gültig sein, während ein Kontaktobjekt veraltet ist. Ein nützlicher Export muss die Beziehungen zwischen diesen Zuständen bewahren und zeigen, welche Aussage der jeweilige Nachweis stützt.

Was RDAP liefert und was nicht

RDAP ist die standardisierte Abfrageschnittstelle für Registrierungsdaten. Sein JSON-Modell beschreibt Objekte wie IP-Netzwerke, Nummern autonomer Systeme, Entitäten, Ereignisse und Links. Das erleichtert es, aktuelle Einträge registryübergreifend abzufragen und zu interpretieren. Die Struktur ist in RFC 9083 definiert.

RDAP beantwortet eine gegenwartsbezogene Abfrage: Was liefert die antwortende Registry jetzt für dieses Objekt zurück? Die Antwort kann den aktuellen Eintrag und Ereignisinformationen enthalten, ist aber nicht automatisch ein unabhängiges Kontinuitätspaket. Sie garantiert für sich genommen nicht, dass ein Inhaber über eine portable, authentifizierte Folge früherer Zustände, eine vollständige Dokumentation der Übergänge oder die nötigen Unterlagen für ein geordnetes Nachfolgeverfahren verfügt.

Dieser Unterschied ist wichtig. Ein aktuell erreichbares Verzeichnis ist ein Fenster in ein System. Ein Export des Registry-Zustands ist eine Möglichkeit, genügend überprüften Zustand zu bewahren, um Kontinuität beurteilen zu können, wenn sich das Fenster, das System oder die institutionelle Beziehung verändert.

Was RPKI beweist und was nicht

RPKI beantwortet eine Routing-Frage. Eine Route Origin Authorization benennt ein autonomes System, das der Inhaber des Adressraums dazu autorisiert hat, Routen für ein oder mehrere Präfixe als Ursprung anzukündigen. Das Profil und die Validierungsregeln werden in RFC 9582 beschrieben.

Das ist ein wertvoller Nachweis, aber keine vollständige Antwort auf jede Registry-Frage. Eine gültige ROA belegt für sich allein weder die gesamte rechtliche oder administrative Historie einer Ressource noch identifiziert sie sämtliche betrieblichen Ansprechpartner, stellt die Reverse-DNS-Kontinuität sicher oder löst einen Streit darüber, welcher Registry-Zustand anzuerkennen ist. Die RPKI-Autorisierung ist eine Ebene in einer Kontinuitätsdokumentation, kein Ersatz für diese Dokumentation.

Eine Arbeitsdefinition des Exports des Registry-Zustands

Der Export des Registry-Zustands ist ein vorgeschlagenes Kontinuitätspaket, das den wesentlichen überprüften Zustand einer IPv4-, IPv6- oder ASN-Ressource portabel, verständlich und testbar macht. Es sollte einem unabhängigen Leser ermöglichen, vier Fragen zu beantworten:

1. Über welche Ressource und welchen anerkannten Inhaber sprechen wir?
2. Was war der letzte überprüfte Zustand, und wann wurde er wirksam?
3. Welche wesentlichen Änderungen sind seit diesem Zustand eingetreten?
4. Welche Nachweise und Befugnisse stützen einen legitimen Übergang oder ein legitimes Nachfolgeverfahren?

Das ist gezielter als ein Datenbank-Dump und nützlicher als ein Bildschirmfoto. Der Export sollte den Zustand enthalten, den ein Nachfolger benötigt, und dabei sachfremde Kundendaten, vertrauliche Geschäftsstrategien und interne Implementierungsdetails auslassen, die nichts zum Nachweis der Ressource beitragen.

Der kleinste sinnvolle Export

Ein praktischer Export lässt sich in eine überschaubare Gruppe miteinander verbundener Datensätze gliedern. Jeder Datensatz sollte eine stabile Kennung, einen Wirksamkeitszeitpunkt, seine Quelle und genügend Informationen enthalten, um eine nicht erklärte Änderung erkennen zu können.

• Ressourcenidentität: das IPv4-Präfix, IPv6-Präfix oder die ASN, gegebenenfalls die übergeordnete Ressource oder Zuteilungsbeziehung sowie die Registry-Kennungen.
• Anerkannter Inhaber: die im überprüften Zustand anerkannte Organisation oder Entität, die Registry-Kennung sowie Wirksamkeitsdatum und Status dieser Anerkennung.
• Kontakte: administrative und technische Ansprechpartner sowie Missbrauchs- und Sicherheitskontakte, die ein Nachfolger oder eine auf die Angaben vertrauende Partei tatsächlich benötigt.
• Wesentliche Historie: Transfers, Namens- oder Organisationsänderungen, Delegationen, Statusänderungen, Streitfälle und die mit jedem Ereignis verbundenen Nachweise oder Autorisierungen.
• Betriebliche Beziehungen: relevante Beziehungen zu Anbietern, Nutzern mit delegierten Rechten, Reverse DNS und Diensten, jeweils mit Geltungszeiträumen und Beendigungsstatus.
• Routing- und Sicherheitsreferenzen: die relevante Ursprungs-ASN, Referenzen auf ROAs oder RPKI-Objekte, der Veröffentlichungszustand und der Zeitpunkt, zu dem dieser Zustand beobachtet wurde.
• Konfliktzustand: ob ein Streitfall, eine Sperre oder ein widersprüchlicher Anspruch vorliegt, welche Ressource betroffen ist und welcher Zustand zuletzt unstrittig war.
• Prüfpfad: wer was wann mit welcher Befugnis von welchem Wert auf welchen Wert geändert hat und mit welchem Prüfergebnis.
• Integritätsinformationen: Versionsnummern, Zeitstempel, Objekt-Hashes, Signaturen und ein Exportmanifest, damit ein Empfänger die Quelle überprüfen und Veränderungen erkennen kann.

Der Export muss nicht jede interne Datenbanktabelle nachbilden. Er muss die Beziehungen bewahren, durch die die öffentliche Antwort aussagekräftig und der Übergang überprüfbar wird.

Warum eine Sicherungskopie nicht genügt

Eine Sicherungskopie ist gewöhnlich dafür gedacht, ein System für denselben Betreiber wiederherzustellen. Ein Export des Registry-Zustands soll dagegen einer anderen autorisierten Partei ermöglichen, den Zustand zu verstehen und zu überprüfen, wenn sich das ursprüngliche System, die Organisation oder die Betriebsstruktur nicht einfach wiederherstellen lässt.

• Eine Sicherungskopie kann proprietäre Software, undokumentierte Beziehungen und die ursprünglichen Zugangsdaten voraussetzen.
• Ein Export sollte für einen unabhängigen Nachfolger lesbar sein und die Nachweise hinter jeder wesentlichen Aussage ausweisen.
• Eine Sicherungskopie kann weit mehr Daten enthalten, als ein Ressourceninhaber erhalten darf oder möchte.
• Ein Export sollte auf die Ressource begrenzt, authentifiziert, maschinenlesbar und portabel sein.

Diese Unterscheidung ist keine technische Geschmacksfrage. Es ist der Unterschied zwischen dem Erhalt einer Maschine und dem Erhalt der Fähigkeit, einen legitimen Zustand anzuerkennen.

Was geschieht, wenn Kontinuität benötigt wird

Ein Kontinuitätsverfahren sollte nicht damit beginnen, zwei Systemen zu erlauben, dieselbe Ressource zu beanspruchen. Es sollte damit beginnen, den letzten überprüften Zustand festzuhalten und den Übergang ausdrücklich zu dokumentieren.

1. Den Auslöser bestimmen: Ausfall, Insolvenz, Kompromittierung, Migration, Streitfall oder ein anderes festgelegtes Kontinuitätsereignis.
2. Den letzten überprüften Zustand bewahren: Ressource, anerkannten Inhaber, Kontakte, wesentliche Historie und die Nachweise für diese Momentaufnahme dokumentieren.
3. Den Export überprüfen: Signaturen, Hashes, Zeitstempel, Autorisierungsreferenzen und die Integrität des Manifests prüfen.
4. Die Nachweisebenen trennen: den Registry-Zustand mit betrieblicher Nutzung, Reverse DNS, Routing-Beobachtungen und RPKI-Zustand vergleichen, statt eine Ebene als Nachweis für alle anderen zu behandeln.
5. Den Nachfolger dokumentieren: festlegen, wie der bisherige Zustand abgelöst wird, wie Konflikte behandelt werden und wie darauf angewiesene Systeme den anerkannten Nachfolger ermitteln.
6. Den Übergang veröffentlichen: den neuen Zustand und seinen Wirksamkeitszeitpunkt auffindbar machen und zugleich den vorherigen Zustand als überprüfbaren historischen Datensatz erhalten.

Das Verfahren soll Kontinuität bewahren, ohne aus einem Ausfall eine Gelegenheit für einen ungeprüften Anspruchsteller zu machen, die Geschichte umzuschreiben.

Was ein Export des Registry-Zustands nicht tun darf

Ein Kontinuitätsexport ist keine zweite Registry, die jedem Empfänger die Macht gibt, Eigentum zu beanspruchen. Er sollte weder parallele Ansprüche schaffen noch die geltenden Ressourcenrichtlinien umgehen, Kundendatenverkehr oder vertrauliche Strategien offenlegen oder betriebliche Nutzung stillschweigend in anerkannte administrative Kontrolle umwandeln.

Der Export sollte auch seine Grenzen benennen. Ist ein Feld nicht verfügbar, unkenntlich gemacht oder umstritten, sollte das im Datensatz stehen. Eine offen benannte Wissenslücke ist sicherer als ein vollständig wirkender Wert ohne Nachweis.

Wie sich ein Export vor einer Krise testen lässt

Ein Ressourceninhaber oder Betreiber kann das Konzept anhand einer einfachen Prüfung testen:

• Kann ein unabhängiger Leser die genaue IPv4-, IPv6- oder ASN-Ressource identifizieren?
• Kann der Leser den zuletzt überprüften anerkannten Inhaber und das Wirksamkeitsdatum bestimmen?
• Kann der Leser wesentliche Transfers, Delegationen und Organisationsänderungen rekonstruieren?
• Kann der Leser den Registry-Zustand vom aktuellen Routing und der betrieblichen Nutzung unterscheiden?
• Kann der Leser die relevanten RPKI- und Reverse-DNS-Nachweise finden?
• Kann der Leser erkennen, ob ein Streitfall oder ein widersprüchlicher Anspruch besteht?
• Kann der Leser überprüfen, wer den Export erstellt hat und ob er danach verändert wurde?
• Kann ein legitimer Nachfolger den Datensatz nutzen, ohne die ursprüngliche private Datenbank zu importieren?

Lassen sich diese Fragen nicht bejahen, verfügt die Organisation möglicherweise über eine aktuelle Abfragemöglichkeit oder eine Sicherungskopie, aber noch nicht über eine getestete Kontinuitätsdokumentation.

Wie das in den IPv4-Lebenszyklus passt

Eine IPv4-Ressource hat einen Lebenszyklus, der Registry-Einträge, Transfers, betriebliche Delegation, Routing und schließlich Nutzungsänderungen umfasst. Der Export verbindet diese Stationen miteinander. Beginnen Sie mit der Frage, was Registry-Daten über einen IPv4-Lebenszyklus zeigen können, und unterscheiden Sie anschließend den regionalen Wechsel bei Inter-RIR-Transfers von einer Routing-Änderung beim BGP-Rehoming.

Dieselbe Überlegung gilt für die umfassendere Governance-Frage: Wenn ein System eindeutige Ressourcen koordiniert, sollte die Möglichkeit, den Zustand zu überprüfen und mitzunehmen, nicht vollständig von einer einzigen, nicht verfügbaren Verwaltungsstelle abhängen. Deshalb gehört der Export des Registry-Zustands zu den praktischen Fragen, was beim Ausfall einer Internet-Registry geschieht und was ein Kontrollnachweis tatsächlich zeigen kann.

Fazit

Der Export des Registry-Zustands macht Kontinuität konkret. Er ersetzt weder RDAP noch RPKI, Routing-Daten, Reverse DNS oder Registry-Richtlinien. Er verbindet die relevanten Nachweise zu einem authentifizierten, versionierten und portablen Datensatz, den ein berechtigter Leser verstehen kann, wenn dem ursprünglichen System nicht ohne Weiteres vertraut oder dieses nicht einfach wiederhergestellt werden kann.

Wenn die Registry verschwindet, besteht das Ziel nicht darin, jedem einen Anspruch auf die Ressource zu ermöglichen. Das Ziel besteht darin, genügend überprüften Zustand zu bewahren, damit sich die legitime Antwort weiterhin erkennen, prüfen und fortführen lässt.