Zusammenfassung

  • Die verfügbaren öffentlichen Quellen reichen in diesem Durchlauf nicht aus, um einen konkreten Ausfall, einen Rückzug von Routen, einen Wiederherstellungszeitpunkt, einen Failover-Pfad oder eine Auswirkung auf Dienste zu belegen.
  • Ein belastbarer Kontinuitätsnachweis müsste Routing-Sichtbarkeit, unabhängige Erreichbarkeit, Pfadänderungen und eine identifizierbare Betreiberhandlung in einer gemeinsamen Zeitachse verbinden.

Die sichtbare Spur ist nicht die Betriebskontrolle

Bei Internet-Infrastruktur können mehrere Evidenzschichten nebeneinander bestehen, ohne dieselbe Aussage zu tragen. Ein Eintrag im RIR- oder IRR-Umfeld beschreibt eine registrierte Ressource oder eine politische beziehungsweise administrative Zuordnung. Ein BGP-Kollektor zeigt, welche Ankündigungen er von seinen Beobachtungspunkten aus gesehen hat. PeeringDB und Topologiedaten können Beziehungen und mögliche Anschlusswege sichtbar machen. Keine dieser Ebenen beweist für sich allein, wer eine Infrastruktur im operativen Sinn steuert oder wer bei einer Störung eine Wiederherstellung veranlasst.

Für DFINFRA und AS210860 ist diese Trennung besonders wichtig. Die bisherige Berichterstattung hat die öffentliche Verbindung mit dem autonomen System als Untersuchungsansatz behandelt, nicht als Nachweis von Eigentum, Betrieb, Routenhoheit, Kundenversorgung oder wirtschaftlichem Nutzen. Die vorliegende Untersuchung setzt deshalb einen anderen Schwerpunkt: Sie fragt, ob die Kontinuität des Systems anhand einer beobachtbaren Kette geprüft werden kann.

Was ein Kontinuitätsereignis zeigen müsste

Ein belastbarer Test beginnt mit einem definierten Ausgangspunkt. Zuerst müsste feststehen, welche Präfixe AS210860 in einem bestimmten Zeitraum ankündigte. Die RIPEstat-Daten zur Routing-Historie können Intervalle sichtbar machen, in denen Präfixe von teilnehmenden Route Collectors beobachtet wurden. Die BGP-Updates können anschließend prüfen, ob an einem verdächtigen Zeitpunkt Withdrawals, neue Announcements oder eine Wiederankündigung auftraten: Routing-History-Daten von RIPEstat und BGP-Updates für AS210860.

Das wäre aber zunächst nur ein Signal aus der Routing-Beobachtung. Ein Verschwinden aus den verfügbaren Kollektoren bedeutet weder automatisch einen globalen Ausfall noch den Verlust der Anwendungserreichbarkeit. Deshalb müsste die Routing-Spur mit einer unabhängigen Messung verbunden werden. IODA kann Hinweise auf Veränderungen der Routing-Sichtbarkeit oder des Active Probing liefern, sofern für AS210860 eine ausreichende Abdeckung besteht: IODA-Beobachtung für AS210860.

Danach müsste die Untersuchung klären, was sich tatsächlich verändert hat. Die Daten zu angekündigten Präfixen können die relevante Präfixmenge eingrenzen. ASN-Nachbarschaften können zeigen, welche extern beobachteten Verbindungen im fraglichen Zeitraum sichtbar waren: angekündigte Präfixe und ASN-Nachbarn. Mehrere Nachbarn können mit Multihoming vereinbar sein und damit eine mögliche präventive Resilienz erklären. Topologische Vielfalt beweist jedoch keinen erfolgreichen Failover. Sie zeigt eine mögliche Struktur, nicht den Nachweis, dass der Verkehr während eines Ereignisses tatsächlich über einen alternativen Weg lief.

Reachability ist eine weitere Evidenzschicht

RIPE Atlas kann zusätzliche Messpunkte liefern, wenn geeignete Sonden und Messungen vorhanden sind. Die Sondenlisten für IPv4 und IPv6 können helfen, potenziell relevante Messpunkte zu identifizieren: RIPE-Atlas-Sonden für IPv4 und RIPE-Atlas-Sonden für IPv6. Auch hier gilt eine enge Grenze: Der Verlust einer Sonde beweist keinen Ausfall des gesamten autonomen Systems. Eine aussagekräftige Messung müsste Zeitpunkt, Zielpräfix, Messmethode, räumliche Verteilung und Ergebnis zusammenführen.

Die entscheidende Kette lautet daher nicht einfach „Route verschwunden, Dienst ausgefallen“. Sie lautet vielmehr: Ein bestimmtes Präfix verliert in einem definierten Zeitfenster seine Sichtbarkeit; unabhängige Messungen zeigen gleichzeitig eine passende Verschlechterung der Erreichbarkeit; danach erscheint eine zeitlich passende Wiederankündigung oder Pfadänderung; schließlich gibt es einen belastbaren Hinweis auf die Handlung eines identifizierbaren Betreibers. Erst diese Kombination würde aus einzelnen Signalen eine Kontinuitätsgeschichte machen.

Was Register- und Topologiedaten leisten können

PeeringDB, das RIPE-aut-num-Objekt und referenzierte Route-Objekte helfen, die administrative und technische Umgebung von AS210860 zu beschreiben. Ergänzend können bgp.tools, CAIDA AS Rank und Hurricane Electric BGP weitere Ansichten auf Routing- und Topologiedaten liefern: PeeringDB, RIPE-aut-num-Objekt, RIPE-Route-Objekte, bgp.tools, CAIDA AS Rank und Hurricane Electric BGP.

Diese Quellen sind nützlich, weil sie die Untersuchungsfläche präzisieren. Sie können helfen, Ressourcen, Präfixe, Nachbarn, Routing-Policies und öffentlich dokumentierte Beziehungen zu vergleichen. Sie beantworten aber nicht automatisch die operative Frage: Wer erkannte eine Störung? Wer entschied über eine Änderung? Wer schaltete einen alternativen Pfad? Wer reparierte die betroffene Komponente? Eine administrative Zuordnung oder eine Sichtbarkeit im Routing darf nicht in eine unbelegte Behauptung über Kontrolle umgewandelt werden.

Der derzeitige Befund ist eine Evidenzgrenze

In diesem Durchlauf wurden keine dynamischen Antworten der genannten Quellen als vollständige, zeitgestempelte Ereigniskette gesichert. Deshalb ist kein konkreter Ausfall von AS210860 belegt. Ebenso sind kein bestätigter Routenrückzug, kein Wiederherstellungszeitpunkt, kein Failover-Pfad, keine Probeunterbrechung und keine Auswirkung auf einen Dienst nachgewiesen.

Das ist nicht dasselbe wie der Nachweis, dass kein Ereignis stattgefunden hat. Es bedeutet, dass die vorhandene Evidenz die Behauptung nicht trägt. Collector-Sichtbarkeit ist nicht globale Erreichbarkeit; Erreichbarkeit ist nicht automatisch Dienstverfügbarkeit; ein Registereintrag ist nicht Betriebskontrolle; und eine mögliche technische Resilienz ist nicht der Nachweis eines erfolgreichen Failovers.

Der nächste überprüfbare Test

Ein neuer Test sollte zunächst eine feste Zeitspanne und eine vollständige Präfixliste definieren. Für jedes Präfix müssten Routing-Historie und BGP-Updates auf Withdrawals und Wiederankündigungen geprüft werden. Parallel wären unabhängige Erreichbarkeits- oder Probing-Daten erforderlich. Anschließend müssten beobachtete Pfadänderungen mit der Präfix- und Nachbarschaftsentwicklung abgeglichen werden.

Der letzte Teil wäre die Attribution. Ein Betreiberhinweis, ein technischer Incident-Bericht oder eine unabhängig dokumentierte operative Handlung müsste zeitlich und sachlich zu den Messdaten passen. Erst dann ließe sich diskutieren, ob Prävention, Erkennung oder Wiederherstellung DFINFRA oder einem anderen identifizierbaren Betreiber zugerechnet werden kann.

Bis dahin bleibt die belastbare Aussage enger: Die öffentlichen Daten liefern Ansatzpunkte für eine Kontinuitätsprüfung von AS210860. Sie belegen in diesem Durchlauf weder einen Ausfall noch eine erfolgreiche Wiederherstellung und weisen keine operative Kontrolle von DFINFRA nach.