Zusammenfassung

  • Die öffentliche Verbindung von DFINFRA mit AS210860 ist eine Untersuchungsspur, aber kein eigenständiger Beleg für Eigentum, Betrieb oder wirtschaftliche Kontrolle.
  • Eine belastbare Zuordnung müsste Registerdaten, Pflege- und Änderungsrechte, IRR- und RPKI-Autorisierung, tatsächlich beobachtete Routen, dauerhafte Konnektivität sowie einen Betreiber- oder Unternehmensnachweis miteinander verbinden.
  • In diesem Recherchelauf wurden die relevanten Endpunkte nicht live abgerufen. Deshalb lassen sich aktuelle Präfixe, Nachbarn, Upstreams, ROAs, Peering-Beziehungen, juristische Einheiten oder Kundenwirkungen nicht als verifiziert darstellen.

Die eigentliche Frage ist die Kontrollkette

Ein AS-Nummer-Eintrag beantwortet zunächst eine enge Verwaltungsfrage: Welche Bezeichnung, Organisation, Kontaktangaben, Maintainer und Routing-Policy sind in der zuständigen Datenbank hinterlegt? Das ist wichtig, aber es beschreibt noch nicht zwingend die Person oder Gesellschaft, die Router betreibt, Verträge mit Transit-Anbietern schließt oder Kundenverkehr wirtschaftlich steuert. Der öffentliche RIPE-aut-num-Eintrag für AS210860 ist der naheliegende Ausgangspunkt für diese Prüfung, weil er genau diese registrierten Attribute und ihre Zeitstempel zusammenführt (RIPE Database: AS210860).

Die Untersuchung muss deshalb mehrere Aussagen trennen:

  1. Registerzuordnung: Welcher Name und welche Organisation sind mit AS210860 verbunden?
  2. Datenbank- und Änderungsrechte: Wer kann die Objekte pflegen oder verändern?
  3. Routenregistrierung: Welche Route- oder route6-Objekte nennen AS210860 als vorgesehenen Ursprung?
  4. Beobachtete Originierung: Welche Präfixe wurden von Messpunkten als von AS210860 ausgehend gesehen?
  5. Kryptografische Autorisierung: Gibt es eine passende RPKI-ROA, die AS210860 als Origin für ein Präfix autorisiert?
  6. Technischer Betrieb: Gibt es dauerhafte Verbindungen, Upstreams, Peering oder eine andere belastbare technische Rolle?
  7. Kommerzielle Bedeutung: Lässt sich ein Betreiber, Dienst, Kunde, Vertrag, Preis- oder Cashflow-Effekt identifizieren?

Diese Aussagen können zusammenpassen, müssen es aber nicht. Ein Name im Register kann veraltet sein. Ein Maintainer kann administrative Rechte besitzen, ohne Eigentümer eines Adressblocks zu sein. Eine RPKI-Autorisierung kann einen Origin autorisieren, ohne den Routerbetreiber oder den Konzern dahinter zu identifizieren. Und eine beobachtete Verbindung kann Transit, Peering, einen Route-Server, eine Kundenbeziehung oder eine temporäre Fehlkonfiguration darstellen.

Der RIPE-Eintrag ist ein Anfang, kein Eigentumsnachweis

Die RIPE-Datenbank und eine Suche nach DFINFRA können zeigen, welche öffentlichen Objekte den Namen verwenden, welche Organisationen oder Kontakte verknüpft sind und welche Maintainer eingetragen wurden (RIPE-Suche nach DFINFRA). Das schafft eine überprüfbare Identitäts- und Verwaltungsspur. Es beantwortet aber nicht automatisch die Frage, ob hinter dem Datensatz eine juristische Person mit nachweisbarer Geschäftstätigkeit steht.

Für eine belastbare Zuordnung wären mindestens drei zusätzliche Prüfungen erforderlich. Erstens müsste die Organisation anhand eines unabhängigen Primärdokuments identifiziert werden, etwa einer Unternehmensregistrierung, einer Einreichung, einem Vertrag oder einer offiziellen Betreiberseite. Zweitens müsste nachvollziehbar sein, ob diese Organisation tatsächlich technische Entscheidungen für AS210860 trifft. Drittens müsste eine Verbindung zu einem Dienst, Standort, Netz, Kundenverhältnis oder Zahlungsstrom bestehen.

Auch die inverse Suche nach Route- und route6-Objekten ist nützlich. Sie kann zeigen, welche Objekte AS210860 als vorgesehenen Origin nennen und welche Maintainer diese Objekte verwalten (inverse RIPE-Suche nach AS210860). Ein solches Route-Objekt ist jedoch eine deklarative Datenbankinformation. Die RIPE-Dokumentation zur Autorisierung des Route-Object-Space beschreibt die Pflege- und Schutzmechanismen, nicht den wirtschaftlichen Eigentumstitel an einem Präfix (RIPE-Dokumentation zum Schutz von Route-Object-Space). Ein veraltetes oder falsch gepflegtes Objekt kann die öffentliche Spur überleben, ohne die aktuelle Betriebsrealität abzubilden.

IRR und RPKI beantworten verschiedene Fragen

IRR-Objekte und RPKI-ROAs werden häufig gemeinsam als Beleg für legitime Routingkontrolle behandelt. Das ist zu grob. Ein IRR-Objekt kann ausdrücken, dass ein bestimmter Origin für eine Route in einer Routingdatenbank eingetragen wurde. Es ist jedoch kein kryptografischer Beweis, dass der Eintrag aktuell ist, dass der Präfixinhaber ihn autorisiert hat oder dass der Betreiber die zugehörige physische Infrastruktur kontrolliert.

Eine ROA beantwortet eine engere, technische Frage: Ist ein bestimmtes ASN berechtigt, einen Präfix oder einen Teilbereich davon zu originieren? Der Standard beschreibt die Autorisierung eines AS als Origin eines Präfixes (RFC 6482). Die aktuellen RPKI-Daten sind als zusätzlicher Prüfpunkt relevant (RPKI-Daten). Daraus folgt nicht automatisch, wer die Router betreibt, wem das Unternehmen gehört oder wer Upstream-Verträge und Kundenbeziehungen kontrolliert. Die RPKI-Auswertung kann deshalb die technische Beweiskette stärken, aber sie ersetzt keine Betreiber- und Unternehmensprüfung.

Für AS210860 müsste eine zeitgestempelte Prüfung mindestens vier Werte zusammenführen: den Präfix, die maximale Länge, den autorisierten Origin und die Gültigkeitsdauer der ROA. Anschließend müsste geprüft werden, ob dieselbe Zuordnung in beobachteten BGP-Daten erscheint und über einen relevanten Zeitraum stabil bleibt. Ein einzelner gültiger Eintrag oder eine einzelne Übereinstimmung würde noch keine dauerhafte Kontrolle beweisen.

BGP-Sichtbarkeit ist nicht gleich globale Erreichbarkeit

RIPEstat kann Übersichten zu einem ASN, angekündigten Präfixen, Routingstatus, Nachbarn und historischen Veränderungen liefern (RIPEstat AS-Übersicht, angekündigte Präfixe, Routingstatus, Nachbarn, Routinghistorie). Unabhängige Beobachtungsdienste wie bgp.tools und BGP.he bieten weitere Perspektiven (bgp.tools für AS210860, BGP.he für AS210860).

Diese Quellen beantworten jedoch zunächst die Frage, was ihre Messpunkte gesehen haben. Kein einzelner Collector sieht das gesamte Internet. Unterschiede können aus zeitlicher Verzögerung, Filterung, lokaler Sichtbarkeit, Route-Servern oder Messpunktabdeckung entstehen. Ein angekündigtes Präfix kann außerdem kurzlebig sein, während ein stabiler Dienstbetrieb eine längere und konsistente Spur hinterlassen müsste.

Die ökonomisch relevante Prüfung wäre daher nicht nur: „Wurde eine Route gesehen?“ Sie lautet: Über welchen Zeitraum wurde sie gesehen, von welchen unabhängigen Messpunkten, mit welchem Origin, welchen Nachbarn und welcher Pfadlänge? Blieb die Zuordnung nach Änderungen stabil? Gab es eine wiederkehrende betriebliche Rolle oder nur einen einzelnen Zustand im Kontrollpfad?

Die AS-Pfad-Nachbarschaft kann technische Konnektivität stützen. Sie unterscheidet aber nicht automatisch zwischen bezahltem Transit, kostenfreiem Peering, einem Kundenverhältnis, einem Route-Server-Pfad oder einem vorübergehenden Route-Leak. Dafür wären zusätzliche Betreiberangaben, Peering-Daten, Standortinformationen oder Vertragsbelege nötig.

Dritte Datenquellen können die Kette verstärken

PeeringDB kann Hinweise auf ein öffentlich erklärtes Netzwerkprofil, Peering-Standorte oder Kontakte liefern (PeeringDB-Netzwerkabfrage für AS210860). Upstream- und Nachbarschaftsdaten können die technische Einordnung ergänzen (BGPView-Upstreams für AS210860, CAIDA AS-Rank für AS210860, Cloudflare Radar für AS210860). Weitere Dienste können Informationen über ASN-Zuordnung oder beobachtete Hosts beisteuern (IPinfo für AS210860, Censys-Hosts nach AS210860).

Doch auch hier gilt: Ein übereinstimmender Datensatz ist stärker als ein ASN-Name allein, aber nicht automatisch ein Beweis für wirtschaftliche Kontrolle. Ein PeeringDB-Eintrag kann selbst gemeldete Informationen enthalten. Ein Host-Scan kann eine technische Zuordnung zeigen, ohne den Betreiber, den Vertragspartner oder die Eigentümerstruktur zu belegen. Upstream-Daten können eine Verbindung plausibel machen, sagen aber nicht zwingend, wer für den Dienst bezahlt oder die Preisgestaltung bestimmt.

Die stärkere Beweiskette wäre eine Übereinstimmung über mehrere Ebenen: dieselbe identifizierbare Organisation in den RIPE-Objekten, eine zeitlich passende und stabile BGP-Originierung, passende IRR- und gegebenenfalls RPKI-Autorisierung, konsistente Upstream- oder Peering-Beziehungen sowie ein von diesem Betreiber kontrollierter Dienst oder ein primäres Unternehmensdokument. Je mehr dieser Elemente unabhängig zusammenfallen, desto weniger hängt die Schlussfolgerung an einer einzelnen Registerbezeichnung.

Der kommerzielle Test beginnt erst nach der technischen Zuordnung

Für Investoren, Kunden und Wettbewerber ist die zentrale Frage nicht, ob AS210860 irgendwo sichtbar ist. Sie lautet: Verändert diese Infrastruktur Marktposition, Kontinuität, Preise, Verhandlungsmacht oder Cashflow?

Ein belastbarer kommerzieller Effekt könnte sich beispielsweise zeigen, wenn DFINFRA und AS210860 gemeinsam mit einem kundenorientierten Dienst, einem Rechenzentrums- oder Transitvertrag, einem Netzstandort, einer öffentlichen Ausschreibung, einer Betreiberwebsite oder einer primären Unternehmensmeldung verbunden werden. Eine solche Verbindung müsste zeitlich und organisatorisch nachvollziehbar sein. Der bloße Umstand, dass zwei Namen in öffentlichen Netzwerkdaten gemeinsam erscheinen, reicht dafür nicht.

Eine Unternehmenssuche kann Kandidaten oder Namensähnlichkeiten liefern, aber sie ersetzt keine Identifizierung anhand unabhängiger Kennungen. Die OpenCorporates-Abfrage nach DFINFRA ist deshalb nur ein weiterer Suchpunkt, nicht das Ergebnis einer verifizierten Eigentumsprüfung (OpenCorporates-Suche nach DFINFRA). Ohne Registrierungsnummer, Jurisdiktion, Primärdokument oder eine eindeutige Verbindung zu den Netzwerkobjekten darf aus einem möglichen Treffer keine juristische oder wirtschaftliche Zuordnung abgeleitet werden.

Dasselbe gilt für Infrastruktur- und Dienstleistungsdaten. Ein beobachteter Host kann eine technische Präsenz anzeigen. Er beantwortet nicht automatisch, ob DFINFRA den Host betreibt, ihn mietet, ihn für einen Kunden verwaltet oder lediglich in einem Datenbestand genannt wird. Für einen Cashflow-Effekt müsste zusätzlich ein Geschäftsmodell erkennbar sein: Wer zahlt wem, für welche Leistung, mit welcher Abhängigkeit und welcher Ausweichmöglichkeit?

Was diese Recherche derzeit nicht behaupten kann

Dieser Recherchelauf hat die genannten öffentlichen Endpunkte nicht live abgerufen. Daher sind keine aktuellen Routing-, IRR-, RPKI-, Peering-, Unternehmensregister- oder kommerziellen Ergebnisse verifiziert. Es gibt in diesem Bericht keinen belastbaren aktuellen Nachweis für ein angekündigtes Präfix, einen bestimmten Upstream, eine gültige ROA, eine aktive Peering-Beziehung, einen gehosteten Dienst, einen Kunden oder eine juristische Eigentümerstruktur.

Das ist keine Aussage, dass solche Belege nicht existieren. Es ist eine Aussage über den Status der Beweislage. Die Untersuchung kann die richtige Prüfarchitektur bestimmen, aber sie kann die letzte Verbindung zwischen DFINFRA, AS210860, einem identifizierbaren Betreiber und einem wirtschaftlichen Effekt in diesem Lauf nicht schließen.

Diese Begrenzung ist gerade bei Netzwerkressourcen wichtig. Öffentliche Daten sind oft zeitabhängig, werden von verschiedenen Organisationen gepflegt und beantworten jeweils nur einen Ausschnitt der Kontrollfrage. Ein Registereintrag, ein Routingobjekt, eine ROA, ein BGP-Pfad und ein Scanresultat dürfen nicht zu einer scheinbar eindeutigen Geschichte addiert werden, wenn ihre Identitäten, Zeitpunkte oder Betreiber nicht übereinstimmen.

Der nächste überprüfbare Zustand

Die These einer dauerhaften operativen Bedeutung würde deutlich stärker, wenn ein zeitgestempeltes Evidenzpaket dieselbe identifizierbare Organisation über mehrere Ebenen hinweg verbindet: den AS210860-aut-num-Eintrag und zugehörige Registry-Objekte, tatsächlich beobachtete BGP-Ankündigungen, passende IRR- und/oder RPKI-Autorisierung, dauerhafte Konnektivität sowie einen vom Betreiber kontrollierten Dienst oder einen primären Unternehmensnachweis.

Ein widersprüchliches Paket würde die Zuordnung schwächen. Dazu gehörten etwa aktive Routen mit nicht übereinstimmenden Registranten- und Betreiberidentitäten, eine nur kurzzeitige oder isolierte Sichtbarkeit, fehlende Autorisierung, ein unabhängiger Betreiber in Peering- oder Standortdaten oder ein Unternehmensnachweis ohne technische Verbindung zu AS210860.

Damit verschiebt sich die Analyse von der Frage „Gehört AS210860 zu DFINFRA?“ zu einer präziseren und wirtschaftlich relevanteren Frage: Welche identifizierbare Partei kann Routen originieren, pflegen, ändern oder zurückziehen – und welcher nachweisbare Dienst, Kunde, Kontinuitäts- oder Cashflow-Effekt folgt daraus?

Bis diese Kette mit aktuellen, voneinander unabhängigen Belegen geschlossen ist, bleibt DFINFRA–AS210860 eine plausible Untersuchungsspur, aber kein verifizierter Nachweis für Eigentum, Betrieb oder Marktstellung.