Zusammenfassung

  • Öffentliche RIPE-Daten verbinden die Bezeichnung DFINFRA mit AS210860. Diese administrative Verbindung belegt weder wirtschaftliches Eigentum noch den Betrieb eines Netzes oder eines Dienstes.
  • IRR-Objekte, RPKI-ROAs und BGP-Beobachtungen beantworten unterschiedliche Fragen: Sie zeigen deklarierte Routing-Absichten und zeitabhängig sichtbare Kontrollplaneigenschaften, aber keine Kunden, Kapazitäten, Verfügbarkeit oder Umsätze.
  • Die belastbare Untersuchung muss deshalb jede Stufe einzeln prüfen: Registrierung, Autorität über Ressourcen, beobachtete Ankündigung, Abhängigkeiten und die Folgen eines Ausfalls.

Die erste Aussage ist eine Registeraussage

Die RIPE-Datenbank und der RIPE-RDAP-Dienst sind geeignete Primärquellen für die öffentliche administrative Verbindung zwischen der Bezeichnung DFINFRA und AS210860 (RIPE-RDAP, RIPE-Aut-num-Objekt). Das ist eine wichtige, aber begrenzte Feststellung. Ein aut-num-Objekt beschreibt, wie eine autonome Systemnummer im Register geführt wird. Es sagt nicht automatisch, wer die wirtschaftlich berechtigte Organisation ist, welche Router sie betreibt oder ob das System zum beobachteten Zeitpunkt tatsächlich Dienste erbringt.

Auch eine Suche nach dem Namen DFINFRA im RIPE-Register liefert zunächst eine administrative Spur, keine vollständige Unternehmensprüfung (RIPE-Suche nach DFINFRA). Für eine Aussage über die letztliche Autorität wären zusätzliche juristische und organisatorische Quellen erforderlich: ein verifizierbarer Rechtsträger, Verträge, Betreiberangaben oder eine andere unabhängige Dokumentation. Die verfügbaren Registerdaten reichen dafür nicht aus.

Diese Unterscheidung verhindert einen häufigen Fehler in Infrastrukturprofilen. Aus „Name und ASN erscheinen gemeinsam in einem Register“ wird schnell „Organisation besitzt und betreibt das Netz“. Die erste Aussage ist öffentlich belegbar. Die zweite ist eine weitergehende Behauptung und benötigt eine andere Evidenz.

Routing-Berechtigung ist nicht Routing-Betrieb

Die nächste Ebene betrifft die deklarierte Routing-Politik. RIPE-IRR-Objekte für IPv4- und IPv6-Routen können angeben, dass AS210860 als Ursprung bestimmter Präfixe vorgesehen ist (RIPE-Route-Suche, RIPE-Route6-Suche). Solche Objekte beschreiben eine veröffentlichte oder registrierte Absicht. Sie sind kein Beweis dafür, dass ein Präfix gerade angekündigt wird oder dass DFINFRA die zugrunde liegende Adresse wirtschaftlich kontrolliert.

RPKI fügt eine kryptografisch überprüfbare Autorisierungsschicht hinzu. Eine gültige ROA kann AS210860 berechtigen, ein bestimmtes Präfix bis zu einer festgelegten maximalen Präfixlänge zu originieren (Cloudflare-RPKI-Daten). Das beantwortet die Frage, ob eine Route innerhalb der veröffentlichten Ressourcen- und Längenbedingungen autorisiert wäre. Es beantwortet nicht, ob die Route aktuell weltweit sichtbar ist, ob sie von einem betriebsbereiten Router ausgesendet wird oder ob auf dem Präfix ein erreichbarer Kundendienst läuft.

Die drei Zustände müssen daher getrennt bleiben:

  1. Eine Ressource kann im Register DFINFRA oder AS210860 zugeordnet sein.
  2. Eine IRR-Regel oder ROA kann eine Originierung durch AS210860 beschreiben oder autorisieren.
  3. Ein Beobachter kann eine tatsächliche BGP-Ankündigung zu einem bestimmten Zeitpunkt sehen.

Keiner dieser Zustände ersetzt die anderen. Ebenso wenig beweist einer von ihnen allein physische Präsenz, Kundenbetrieb oder Dienstverfügbarkeit.

Was unabhängige BGP-Beobachter zeigen können

Mehrere öffentliche Mess- und Analysequellen liefern komplementäre Sichtweisen auf AS210860. RIPEstat stellt Übersichten, angekündigte Präfixe, Routing-Historie und den aktuellen Routingstatus bereit (AS-Übersicht, angekündigte Präfixe, Routing-Historie, Routingstatus). Ergänzende Perspektiven liefern RIPEstat-Nachbarschaftsdaten sowie BGP.Tools, Hurricane Electric, der NLNOG IRR Explorer und Potaroo (RIPEstat-AS-Nachbarn, BGP.Tools, Hurricane Electric BGP Toolkit, NLNOG IRR Explorer, Potaroo-AS-Bericht).

Eine zeitgleiche Sichtbarkeit in mehreren Beobachtern stärkt die Aussage, dass eine Ankündigung im Control Plane beobachtet wurde. Sie beweist aber nicht automatisch universelle Erreichbarkeit. BGP-Daten können zeitabhängig, standortabhängig und von der jeweiligen Messabdeckung geprägt sein. Eine benachbarte ASN im AS-Pfad zeigt Konnektivität oder eine beobachtete Pfadbeziehung. Sie unterscheidet nicht zuverlässig zwischen Transit, Peering, bezahlter Weiterleitung oder einer anderen kommerziellen Vereinbarung. Sie nennt weder Preis noch Kapazität, Service-Level, Vertragsdauer oder tatsächliches Verkehrsvolumen.

Auch Routing-Historie muss präzise beschrieben werden. Sie kann zeigen, wann ein Beobachter eine Route erstmals oder zuletzt wahrnahm und wie sich die Sichtbarkeit veränderte (RIPE-RIS-First/Last-Seen). Daraus lässt sich ein zeitlicher Verlauf der Beobachtung ableiten. Daraus lässt sich nicht ohne zusätzliche Messung ableiten, ob eine Organisation dauerhaft verfügbar war, warum eine Route verschwand oder welche Nutzer davon betroffen waren.

Ressourcenregistrierung und Routing sind separate Prüfungen

Die öffentliche Delegationsstatistik kann Hinweise auf die Zuteilungs- und Registrierungsstruktur von IP-Ressourcen liefern (RIPE-NCC-Delegationsdaten). Sie ersetzt jedoch keine Präfix-für-Präfix-Prüfung. Für jedes aktuell relevante Präfix müssten mindestens die Adressregistrierung, passende IRR-Objekte und die RPKI-Nutzlast miteinander verglichen werden.

Das ist besonders wichtig, wenn eine ASN mit mehreren Ressourcen oder historischen Einträgen verbunden erscheint. Eine ASN-Zuordnung sagt nicht zwingend, dass alle beobachteten Adressräume derselben Organisation gehören. Umgekehrt kann ein registrierter Adressraum ohne aktuelle BGP-Ankündigung sein. Die technische Prüfung muss deshalb immer fragen: Welches Präfix? Welche Quelle? Welcher Zeitstempel? Welche Autorisierung? Welche beobachtete Originierung?

Eine belastbare Veröffentlichung sollte mutable Antworten archivieren und mit Zeitstempeln und Hashes versehen. Ohne diese Sicherung können spätere Änderungen an RDAP-, IRR-, RPKI- oder BGP-Daten die Reproduzierbarkeit einer früheren Aussage beeinträchtigen.

Abhängigkeiten: Sichtbare Nachbarschaft ist keine Dienstarchitektur

PeeringDB kann ergänzende Angaben zur Netzwerkpräsenz und zu veröffentlichten Verbindungen liefern (PeeringDB-Netzwerkdatensatz). Solche Angaben sind nützlich, weil sie eine Verbindung zwischen einer ASN und einer öffentlich beschriebenen Interconnection-Identität herstellen können. Sie beweisen jedoch nicht, dass eine Präsenz aktuell aktiv ist, welche Kapazität verfügbar ist oder welche Kunden über sie versorgt werden.

Ebenso können RIPE Atlas-Abfragen Hinweise darauf geben, ob Messsonden mit IPv4- oder IPv6-Bezug zu AS210860 sichtbar sind (RIPE Atlas IPv4-Sonden, RIPE Atlas IPv6-Sonden). Eine solche Beobachtung ist ein Messsignal, keine vollständige Beschreibung der physischen Bereitstellung. Sie zeigt weder Routerstandorte noch Stromversorgung, Redundanz, Kundenverträge oder die Verfügbarkeit einer Anwendung.

Damit wird die zentrale Grenze der derzeit verfügbaren Evidenz sichtbar: Die Quellen beschreiben überwiegend die Control Plane und administrative Daten. Sie belegen keine physische Deployment-Tiefe, keine Verkehrsmenge, keine Anwendungsschicht, keine Betriebszeit und keinen Umsatz. Für diese Behauptungen wären aktive Messungen, unabhängige Betriebsdaten, Kundenbelege oder andere öffentliche Primärquellen notwendig.

Was sich heute sagen lässt — und was nicht

Die stärkste derzeit vertretbare Aussage lautet: Öffentliche RIPE-Daten verbinden DFINFRA administrativ mit AS210860; technische Register können Routing-Absichten und Autorisierungen für diese ASN dokumentieren; mehrere externe Beobachter können zeitabhängige Informationen über Präfixe, Sichtbarkeit, Historie und AS-Pfad-Beziehungen liefern. Diese Kombination ist ein belastbarer Untersuchungsansatz und mehr als eine bloße Namenssuche.

Sie reicht jedoch nicht für die Behauptung, DFINFRA betreibe nachweislich ein bestimmtes physisches Netz, kontrolliere alle zugeordneten Adressressourcen, unterhalte eine bestimmte Kapazität oder biete einen verfügbaren Dienst für Kunden an. Ebenso lässt sich aus den vorliegenden Quellen kein Ausfallrisiko quantifizieren. Dafür fehlen unter anderem unabhängige Verfügbarkeitsmessungen, Verkehrsdaten, Dienstabhängigkeiten und eine Zuordnung konkreter Nutzer oder Anwendungen.

Die richtige Schlussfolgerung ist deshalb nicht, dass die öffentliche Spur wertlos sei. Sie ist wertvoll, weil sie die nächste Untersuchung präzise strukturiert. Jeder weitere Anspruch muss an eine eigene Evidenzstufe gebunden werden: Registerdaten für administrative Identität, Ressourcen- und Routingdaten für technische Autorität, zeitgestempelte Mehrfachbeobachtungen für sichtbare Operation und aktive Messungen oder unabhängige Betriebsquellen für Dienst- und Ausfallfolgen.

DFINFRA bleibt damit ein überprüfbares Infrastrukturthema, aber kein durch Registerdaten abschließend erklärtes Infrastrukturunternehmen. Die Daten zeigen eine technische und administrative Spur. Sie zeigen noch nicht die gesamte Organisation, ihre physische Reichweite oder ihren kommerziellen Einfluss.

Quellen und Evidenzgrenzen

Die Analyse verwendet die öffentlichen Register-, Routing-, RPKI-, Interconnection- und Messquellen, die in den Links dieses Artikels genannt sind. Beobachtungen aus veränderlichen Diensten gelten für den jeweiligen Abrufzeitpunkt. Aussagen über Eigentum, physische Bereitstellung, Kunden, Betriebszeit, Dienstqualität, Ausfallfolgen und Umsatz bleiben offen, sofern keine unabhängige Evidenz hinzugefügt wird.