Zusammenfassung

  • Öffentliche Registerdaten verbinden das Label DFINFRA mit AS210860, beweisen aber weder wirtschaftliches Eigentum noch operative Kontrolle oder einen dauerhaft betriebenen Kundendienst. (RIPE RDAP; RIPE Database)
  • Routing-, RPKI-, IRR-, PeeringDB- und Aggregator-Daten beantworten unterschiedliche technische Fragen. Erst eine zeitlich begrenzte, über mehrere Evidenzarten korroborierte Kette könnte einen operativen Fußabdruck und eine Abhängigkeitsstruktur plausibel belegen.

Die belastbare Aussage ist kleiner als die naheliegende Behauptung

Die verfügbare öffentliche Dokumentation erlaubt eine vorsichtige Feststellung: Das Label DFINFRA wird in öffentlichen Materialien mit dem autonomen System AS210860 verbunden. Dafür sind die Nummernzuweisung und die Einträge der zuständigen Registry relevante Ausgangspunkte (IANA — AS-Nummern; RIPE RDAP; RIPE Database). Diese Feststellung ist administrativ. Sie sagt nicht, wer wirtschaftlich hinter dem Eintrag steht, wer den Betrieb kontrolliert, welche Leistungen angeboten werden oder ob das System dauerhaft aktiv ist.

Gerade bei Internet-Infrastruktur werden verschiedene Ebenen häufig zu einer scheinbar geschlossenen Geschichte verbunden. Ein ASN kann registriert sein. Ein Route Object kann eine Herkunft angeben. Eine RPKI-Autorisierung kann einen Origin legitimieren. Ein Collector kann Präfixe oder Nachbarschaften beobachten. Ein Eintrag in PeeringDB kann eine Präsenz oder ein Peering-Verhältnis beschreiben. Keine dieser Beobachtungen beantwortet allein dieselbe Frage wie ein Kundenvertrag, ein dokumentierter Service, ein belastbarer Betriebsnachweis oder eine unabhängige Bestätigung wirtschaftlicher Kontrolle.

Was Registerdaten zeigen — und was nicht

RDAP- und RIPE-Database-Daten sind Belege für die administrative Darstellung eines Internet-Ressourcen-Eintrags. Sie können Namen, Status, Kontakte, Zuordnungen und technische Attribute dokumentieren. Sie beweisen für sich genommen weder das wirtschaftliche Eigentum noch die tatsächliche operative Kontrolle, eine kontinuierliche Leistungserbringung oder eine Kundenbeziehung. Diese Grenze ist nicht semantische Vorsicht, sondern eine Eigenschaft des Registers: Es ist für Ressourcenverwaltung und Kontaktierbarkeit gebaut, nicht als vollständiges Eigentums- oder Geschäftsregister.

Die sauberste Formulierung lautet deshalb: Öffentliche Registry-Materialien assoziieren DFINFRA mit AS210860. Eine weitergehende Behauptung müsste jeweils durch zusätzliche Quellen belegt werden. Dazu gehören etwa ein nachvollziehbarer Kontrollnachweis, eine unabhängige organisatorische Zuordnung, eine zeitlich dokumentierte Betriebsaktivität oder ein Dienst, dessen Mechanismus und Nutzerbezug öffentlich prüfbar sind.

Warum Routing-Signale nicht zu einem Geschäftsmodell werden dürfen

IRR-Route-Objekte, RPKI-Daten, RIPEstat-Beobachtungen, RIS-Messungen und Drittanbieter-Aggregatoren erfassen verschiedene technische Sachverhalte. Die IRR-Suche nach Origin kann deklarierte Routing-Objekte auffinden. Die RIPEstat-Übersicht, die Daten zu angekündigten Präfixen und der Routing-Status können den technischen Beobachtungsraum strukturieren. Sie machen daraus aber nicht automatisch einen Beleg für einen Endkundendienst, bezahlten Transit, eine bestimmte Organisation oder eine dauerhaft verfügbare Infrastruktur.

Auch eine RPKI-Autorisierung beantwortet eine eng umrissene Frage: ob ein bestimmter Origin für einen Präfix innerhalb der jeweiligen Autorisierungslogik zulässig ist. Sie beantwortet nicht, wer den Dienst verkauft, wer die physische Infrastruktur betreibt oder welche Ausfallsicherheit Kunden tatsächlich erhalten. Die Cloudflare-RPKI-Daten sind daher als technische Evidenz einzuordnen, nicht als Geschäfts- oder Eigentumsnachweis.

Nachbarschaften sind Beobachtungen, keine Verträge

Die RIPEstat-Daten zu ASN-Nachbarn, die Looking-Glass-Daten und Messungen aus dem RIPE RIS können zeigen, dass bestimmte Pfade oder Sichtbarkeiten von Messpunkten aus beobachtet wurden. Ein beobachteter AS-Pfad kann auf Routing-Sichtbarkeit oder eine technische Abhängigkeit hindeuten. Er beweist jedoch nicht, ob das benachbarte ASN Transitprovider, Peer, Kunde, Schwesterorganisation oder Backup-Pfad ist.

Dasselbe gilt für Drittanbieter wie bgp.tools, Cloudflare Radar, CAIDA AS Rank, BGP HE und BGPView. Ihre Darstellungen können nützlich sein, um Messungen zu vergleichen, Zeitpunkte zu bestimmen und Widersprüche zu erkennen. Sie ersetzen aber keine Erklärung der Beziehung zwischen den beteiligten Netzen. Ein Upstream-Label in einem Aggregator ist nicht automatisch ein unterschriebener Transitvertrag.

Selbstangaben brauchen eine zweite Quelle

PeeringDB ist für die Untersuchung möglicher physischer und organisatorischer Präsenz besonders interessant, weil dort Netzwerke, Einrichtungen und Internet Exchanges beschrieben werden können. Die PeeringDB-Netzwerkdaten, die ASN-Ansicht und mögliche Interconnection-Daten sind jedoch operator-maintained: Sie beruhen auf Angaben der beteiligten Betreiber. Die PeeringDB-Dokumentation beschreibt den Charakter dieser Daten, ändert aber nichts an der Beweisgrenze.

Eine PeeringDB-Angabe ist deshalb eine relevante Selbstbeschreibung, aber kein unabhängiger Nachweis. Sie wird stärker, wenn eine Exchange, ein Facility-Betreiber, ein Colocation-Anbieter, ein Messpunkt oder eine öffentlich dokumentierte Dienstleistung dieselbe Präsenz unabhängig bestätigt. Erst die Übereinstimmung mehrerer Quellen kann aus einer Selbstauskunft einen belastbaren Hinweis auf einen operativen Fußabdruck machen.

Der notwendige Beweisverbund

Ein defensibler Befund müsste mindestens sechs Ebenen verbinden. Erstens müsste die Registry-Identität zeitlich und organisatorisch nachvollziehbar sein. Zweitens müsste technische Autorität über Ressourcen, Routing oder Konfiguration belegt werden. Drittens müsste beobachtetes Routing mit Zeitstempeln, Collectors und Messgrenzen dokumentiert werden. Viertens müsste eine physische oder Exchange-Präsenz unabhängig bestätigt werden, sofern eine solche behauptet wird. Fünftens müsste der konkrete Dienstmechanismus sichtbar sein: Transit, Peering, Hosting, Transport, Schutzdienst, Unternehmensnetz oder etwas anderes.

Sechstens müsste eine operative oder kommerzielle Folge zurechenbar sein, etwa eine dokumentierte Kundenabhängigkeit, ein Incident, eine Wiederherstellungsentscheidung oder eine vertraglich beschriebene Leistung.

Die Quellenlage schließt diese Prüfung nicht grundsätzlich aus. Sie schließt aber eine vorzeitige Schlussfolgerung aus. Die derzeit zusammengetragenen öffentlichen Quellen liefern Kandidaten für jeden Teil der Untersuchung, ohne im vorliegenden Evidenzpaket aktuelle Präfixzahlen, benannte Upstreams, benannte Peers, eine Facility, eine konkrete ROA, einen unabhängig dokumentierten Dienstmechanismus oder eine Kundenfolge zu behaupten.

Ein praktikables Untersuchungsprotokoll

Eine belastbare Untersuchung sollte mit einem Stichtag und einem Beobachtungsfenster beginnen. Für jedes Routing-Signal müssten Quelle, Collector, Zeitpunkt, Präfix, Origin und Sichtbarkeitsgrenze erhalten bleiben. Für jedes Registry-Attribut müsste festgehalten werden, ob es eine administrative Angabe, eine technische Autorisierung oder eine unabhängige Bestätigung ist. Für jede Peering- oder Facility-Angabe müsste die Herkunft als Selbstangabe, Betreiberbestätigung oder externe Beobachtung gekennzeichnet werden.

Danach sollte die Untersuchung nach Widersprüchen suchen. Ein ASN, das in einem Register aktiv erscheint, kann im Routing nur sporadisch sichtbar sein. Ein Route Object kann existieren, ohne dass ein Präfix aktuell angekündigt wird. Eine RPKI-Autorisierung kann gültig sein, ohne dass daraus eine aktive Kundenleistung folgt. Ein PeeringDB-Eintrag kann eine Absicht oder eine veraltete Konfiguration spiegeln. Widersprüche sind kein Grund, die schwächere Quelle zu verwerfen; sie sind ein Grund, die Behauptung enger zu formulieren.

Für Abhängigkeiten ist außerdem die Richtung entscheidend. Eine beobachtete Nachbarschaft zeigt eine Beziehung im Pfad, aber nicht automatisch, wer von wem abhängig ist. Dafür wären wiederholte Beobachtungen, konkrete Präfixe, Ausfall- oder Umschaltverhalten und — soweit öffentlich möglich — eine dokumentierte Rolle der beteiligten Betreiber erforderlich. Ohne diese Elemente bleibt „Abhängigkeit“ eine Hypothese über Topologie, nicht ein festgestellter wirtschaftlicher oder betrieblicher Sachverhalt.

Schlussfolgerung

Die derzeitige Evidenz stellt eine methodische Grenze klarer dar als einen abgeschlossenen Betriebsbefund. Sie verbindet DFINFRA öffentlich mit AS210860 auf Registerebene und beschreibt mehrere technische Messpunkte, mit denen sich ein operativer Fußabdruck weiter untersuchen ließe. Sie beweist jedoch nicht, dass DFINFRA einen bestimmten Dienst für Kunden betreibt, ein Netz wirtschaftlich kontrolliert, bestimmte Upstreams bezahlt, eine bestimmte physische Präsenz unterhält oder eine bestimmte Kontinuitätsgarantie bietet.

Der nächste belastbare Schritt wäre deshalb kein stärkeres Etikett, sondern ein zeitgebundener Beweisverbund: administrative Identität, technische Autorität, beobachtetes Routing, unabhängige Präsenz, konkreter Dienstmechanismus und zurechenbare Folge. Solange diese Kette nicht geschlossen ist, bleibt die verantwortbare Aussage begrenzt: Es gibt eine öffentliche Registry-Assoziation und technische Beobachtungspunkte, aber keinen unabhängig dokumentierten Nachweis eines bestimmten operativen oder kommerziellen Fußabdrucks.

Öffentliche Quellen konsultiert

Weitere Informationen zum untersuchten Verzeichniseintrag: DFINFRA im Verzeichnis.