Zusammenfassung

  • Am 20. Februar 2026 zog Cloudflares interne Automatisierung nach einer Änderung an der Addressing API etwa 1.100 von Kunden eingebrachte IP-Präfixe zurück.
  • Cloudflares einleitende Darstellung nennt 17:48 UTC und eine Dauer von sechs Stunden und sieben Minuten; die detaillierte Zeitleiste setzt die Auswirkungen dagegen von 17:56 bis 23:03 UTC an. Diese Angaben bleiben als interne Abweichung der Quelle getrennt stehen.
  • Der Vorfall war laut Cloudflare kein Angriff. Es gibt auch keinen Beleg für einen BGP-Hijack, ein Versagen der Ursprungsvalidierung oder ein Route Leak.
  • Die Rücknahme der auslösenden Änderung stoppte weitere Mutationen, stellte aber bereits veränderte Datensätze, Dienstbindungen und ausgerollte Netzkonfigurationen nicht vollständig wieder her.
  • Nach Angaben des Unternehmens waren gegen 20:20 UTC ungefähr 800 Präfixe wiederhergestellt; für rund 300 weitere Präfixe waren zusätzliche Wiederherstellungswege bis 23:03 UTC erforderlich.
  • Registereinträge, IRR-Objekte, ROAs und Letters of Agency dokumentieren Zuständigkeit oder Erlaubnis. Sie beweisen weder eine gegenwärtige Routenankündigung noch die Erreichbarkeit eines gebundenen Dienstes.
  • Belastbare Kontrolle verlangt präzise Dry-Runs, abhängigkeitssensitive Löschsperren, begrenzte Änderungskohorten, repräsentative Canaries, einen unabhängigen Rollback und die Abstimmung aller Zustands- und Beobachtungsebenen.
  • Die zum Beitrag gehörende Darstellung ist als allgemeine dokumentarische Szene des Netzwerkbetriebs zu verstehen. Sie zeigt weder eine Cloudflare-Einrichtung noch den tatsächlichen Ort oder Ablauf des Vorfalls.

Ein Ausfall der Zustandskette

Cloudflares Bring-Your-Own-IP-Angebot, kurz BYOIP, ermöglicht es Kunden, eigene IP-Adressbereiche über das globale Netz des Anbieters ankündigen und für dort bereitgestellte Dienste verwenden zu lassen. Das Modell verbindet zwei Sphären, die im Alltag leicht als eine einzige erscheinen. Auf der einen Seite stehen formale Nachweise darüber, wem ein Nummernblock zugeordnet ist und welcher Betreiber ihn ankündigen darf.

Auf der anderen Seite steht der laufende technische Zustand: Ein Dienst muss an die richtigen Adressen gebunden sein, die Plattform muss eine Ankündigung beabsichtigen, Router müssen diese Absicht umsetzen, und andere Netze müssen die Route tatsächlich empfangen und für die Weiterleitung auswählen können.

Der Vorfall vom 20. Februar 2026 unterbrach diese Kette nicht an ihrem formalen Anfang. Cloudflare beschrieb keinen Verlust der Eigentums- oder Autorisierungsnachweise der betroffenen Kunden. Stattdessen veränderte eine interne Änderung an der Verwaltung kundenbezogener Adressräume den operativen Lebenszyklus aktiver Präfixe. Ein Bereinigungsprozess interpretierte Datensätze so, dass weiterhin benötigte Präfixe zurückgezogen wurden. Bei einem Teil der Betroffenen verschwanden außerdem Adressierungseinstellungen von Edge-Systemen.

Damit ging es nicht allein um einen falschen Wert in einer Verwaltungsoberfläche, sondern um eine Diskrepanz zwischen gespeicherter Plattformabsicht, Dienstzuordnung, ausgerollter Konfiguration und öffentlicher Routensicht.

Diese Unterscheidung ist für die Verantwortungsfrage zentral. Eine Änderung kann technisch erfolgreich ausgeführt worden sein und dennoch einen falschen realen Zustand erzeugen. Ebenso kann ein Rollback den auslösenden Programmablauf stoppen, ohne alle bereits veränderten Objekte zu rekonstruieren. Wer Netzressourcen automatisiert verwaltet, braucht deshalb mehr als eine Transaktionsmeldung oder einen grünen Status im Steuerungssystem.

Er muss zeigen können, dass die betroffenen Präfixe noch an die richtigen Dienste gebunden sind, dass ihr vorgesehener Ankündigungsstatus korrekt ist, dass die Router diesen Zustand ausführen und dass unabhängige Beobachter die erwarteten Routen sehen.

Chronologie und Quellenabweichung

Cloudflares öffentliche Aufarbeitung enthält zwei Zeitangaben, die nicht zu einer einzigen vermeintlich präzisen Darstellung verschmolzen werden dürfen. In der einleitenden Erzählung heißt es, der Ausfall sei ab 17:48 UTC erlebt worden und habe sechs Stunden und sieben Minuten gedauert. Die detaillierte Zeitleiste kennzeichnet die Auswirkungsphase dagegen von 17:56 bis 23:03 UTC. Die angegebene Dauer passt zur zweiten Zeitspanne, nicht aber ohne Weiteres zum früheren Beginn aus der Einleitung. Der öffentliche Bericht erklärt diese Abweichung nicht abschließend.

Für eine verantwortbare Darstellung bedeutet das, beide Aussagen mit ihrer jeweiligen Einordnung zu erhalten. 17:48 UTC ist die Zeit aus Cloudflares eröffnender Beschreibung; 17:56 UTC ist der Beginn der in der detaillierten Zeitleiste ausgewiesenen Auswirkung. 23:03 UTC ist dort das Ende. Es wäre irreführend, aus den unterschiedlichen Angaben eigenmächtig einen neuen Startzeitpunkt oder eine neue Dauer zu errechnen. Gerade ein Beitrag über operative Beweisführung sollte eine Unschärfe der Primärquelle nicht durch scheinbare Genauigkeit verdecken.

Nach Cloudflares Darstellung löste eine Änderung an der Addressing API die fehlerhafte Zustandsverarbeitung aus. Diese API fungierte im beschriebenen Betriebsmodell als maßgebliche Datenquelle für Kundenadressen. Ein nachgelagerter Bereinigungsprozess traf daraufhin Entscheidungen, durch die aktive BYOIP-Präfixe zurückgezogen wurden. Bevor die auslösende Änderung gestoppt wurde, waren etwa 1.100 Präfixe betroffen. Die Zahl ist eine Näherungsangabe des Unternehmens und sollte nicht als vollständig unabhängige oder auf das einzelne Präfix genau geprüfte Messung behandelt werden.

Das Zurücknehmen der Änderung beendete weitere fehlerhafte Mutationen. Es machte jedoch nicht sämtliche bereits vorgenommenen Änderungen rückgängig. Dieser Unterschied erklärt, weshalb die Erholung mehrere Pfade benötigte. Einige Kunden konnten ihre Präfixe über Selbstbedienungsfunktionen erneut ankündigen. Cloudflare stellte daneben Daten aus einer Datenbankwiederherstellung zurück, rekonstruierte Dienstbindungen und verteilte eine globale Maschinenkonfiguration. Gegen 20:20 UTC waren nach Angaben des Unternehmens ungefähr 800 Präfixe wiederhergestellt.

Für die verbleibenden rund 300 waren zusätzliche Maßnahmen notwendig, die sich bis 23:03 UTC erstreckten.

Diese Staffelung ist kein nebensächliches Detail. Sie zeigt, dass die betroffene Zustandsmenge nicht homogen war. Wäre lediglich ein einzelnes, vollständig reversibles Ankündigungsflag verändert worden, hätte ein unabhängiger Rollback dieses Flag für die gesamte Kohorte wiederherstellen können. Tatsächlich mussten unterschiedliche Wiederherstellungswege verwendet werden. Das spricht dafür, die Wiederherstellung nicht als bloße Umkehr eines Befehls zu betrachten, sondern als Rekonstruktion einer verteilten Zustandskette.

Die öffentliche Chronologie belegt dabei nicht jeden internen Schritt. Sie nennt weder sämtliche Entscheidungspunkte noch jede betroffene Datenstruktur oder den genauen Zustand jedes Routers. Auch die ungefähren Gruppen von 800 und 300 Präfixen dürfen nicht als Beleg dafür gelesen werden, dass alle Präfixe innerhalb einer Gruppe identisch betroffen waren. Zulässig ist die engere Feststellung: Cloudflare berichtet eine erste größere Wiederherstellungswelle und einen verbleibenden Bestand, für den weitere Pfade erforderlich waren.

Was BYOIP technisch zusammenführt

Ein eigenes IP-Präfix über einen externen Betreiber anzukündigen setzt mehrere Nachweise und mehrere operative Objekte voraus. Zunächst muss die Zuteilung oder Registrierung des Nummernraums nachvollziehbar sein. Regionale Internetregister stellen dafür Registerinformationen bereit. Internet Routing Registries können Route-Objekte enthalten, die eine beabsichtigte Beziehung zwischen einem Präfix und einem Ursprungs-AS dokumentieren. In der Resource Public Key Infrastructure kann ein Route Origin Authorization, kurz ROA, kryptografisch ausdrücken, welches autonome System einen bestimmten Präfixbereich originieren darf.

Diese Nachweise sind wichtig, aber ihre Aussage bleibt begrenzt. Ein gültiges ROA sagt nicht, dass eine Route im Augenblick angekündigt wird. Es sagt auch nicht, ob ein bestimmter Cloud-Dienst an die Adressen gebunden ist. Ein IRR-Objekt kann die beabsichtigte Routingbeziehung dokumentieren, ohne den Zustand eines laufenden Routers abzubilden. Ein Letter of Agency hält die Erlaubnis fest, dass Cloudflare Adressraum eines Kunden ankündigen darf; er ist kein Echtzeitbeweis dafür, dass diese Ankündigung derzeit existiert oder dass ankommender Verkehr die richtige Anwendung erreicht.

Cloudflares heutige BYOIP-Dokumentation beschreibt eine Produktlogik, in der ein Präfix einem Konto zugeordnet, auf Eigentums- und Routingnachweise geprüft, mit Diensten verbunden und durch ein BGP-Präfixobjekt repräsentiert wird. Dieses Objekt beginnt im zurückgezogenen Zustand. Ein autorisierter Vorgang kann es in den angekündigten Zustand überführen, worauf Cloudflare das Präfix über sein Netz bekannt gibt. Diese Dokumentation liefert ein nützliches Vokabular für die Kontrollanalyse.

Sie beweist jedoch nicht, dass die verborgene Implementierung im Februar in jedem Detail genauso aufgebaut war oder dass jede heute dokumentierte Sicherung damals bestand.

Auch Präfixdelegationen vergrößern den Kontrollraum. Ein Konto kann einem anderen die Nutzung eines Adressbereichs ermöglichen, während bestimmte Verwaltungs- oder Dienstbindungsrechte beim übergeordneten Konto verbleiben. Dadurch entstehen mehrere legitime Beziehungen zu demselben Nummernraum. Eine Automatisierung, die nur nach einem Kontoeintrag oder einem isolierten Objektstatus fragt, kann aktive Abhängigkeiten übersehen. Ein vermeintlich ungenutzter Datensatz kann weiterhin eine Dienstbindung, eine Delegation oder eine laufende Ankündigung tragen.

Address Maps bilden eine weitere Ebene. Sie verknüpfen Adressen mit den Antworten und Diensten, die über die Plattform bereitgestellt werden sollen. Selbst wenn ein Präfix korrekt angekündigt wird, beweist das noch nicht, dass Verkehr an den vorgesehenen Dienst gelangt. Umgekehrt kann eine vollständig konfigurierte Dienstbindung nutzlos sein, wenn die Route zurückgezogen wurde und Pakete die Plattform nicht mehr erreichen. Autorisierung, Attraktion des Verkehrs und Verarbeitung des Verkehrs sind unterschiedliche Funktionen.

Der Begriff „Präfixstatus“ muss deshalb präzisiert werden. Er kann mindestens den Registerstatus, die Kontoaufnahme, die Delegation, die Dienstbindung, den beabsichtigten BGP-Zustand, die auf Router oder Edge-Systeme ausgerollte Konfiguration und die von außen beobachtete Route meinen. Eine Plattform darf diese Bedeutungen nicht stillschweigend auf ein einzelnes Feld reduzieren. Wenn eine Bereinigung entscheidet, ein Präfix sei inaktiv, muss sie erklären können, auf welcher Ebene diese Inaktivität festgestellt wurde und welche abhängigen Ebenen noch aktiv sind.

Fünf getrennte Beweise

Die erste Beweisebene betrifft die Verfügungs- und Ankündigungsbefugnis. Dazu gehören Registerinformationen, IRR-Objekte, ROAs, das korrekte Ursprungs-AS und gegebenenfalls ein Letter of Agency. Diese Ebene beantwortet Fragen wie: Ist der Kunde dem Präfix nachvollziehbar zugeordnet? Ist Cloudflare zur Ankündigung ermächtigt? Darf das vorgesehene autonome System die Route originieren? Sie beantwortet nicht, ob der Betreiber die Route tatsächlich sendet.

Die zweite Ebene ist der Plattform- und Dienstkontext. Hier geht es um Konto, Delegation, Address Map und konkrete Servicebindung. Ein Präfix kann für CDN- oder Sicherheitsdienste, Spectrum, Dedicated Egress oder Magic Transit benötigt werden. Die Bindung erklärt, welchen Zweck die Plattform mit dem angezogenen Verkehr erfüllen soll. Fehlt sie, kann die Route zwar sichtbar sein, doch die anschließende Verarbeitung bleibt falsch oder unvollständig.

Die dritte Ebene ist die beabsichtigte Ankündigung. Ein Steuerungssystem muss festhalten, ob das Präfix gegenwärtig angekündigt oder zurückgezogen sein soll. Dieser Sollzustand benötigt eine nachvollziehbare Herkunft: Wer hat ihn gesetzt, auf welcher Berechtigungsgrundlage, für welchen Dienst und mit welcher erwarteten Dauer? Ein bloß vorhandenes Präfixobjekt sagt nicht automatisch, welcher BGP-Zustand gewollt ist.

Die vierte Ebene ist die ausgerollte Konfiguration. Router und Edge-Systeme müssen den vorgesehenen Zustand erhalten und ausführen. Zwischen einer akzeptierten API-Änderung und dem laufenden Netz können Warteschlangen, Konfigurationsgeneratoren, Validierungen und Rolloutschritte liegen. Ein erfolgreich gespeicherter Sollwert beweist deshalb nicht, dass alle relevanten Systeme ihn übernommen haben. Genauso beweist ein zurückgerollter Datenbankwert nicht, dass bereits entfernte Konfigurationen wieder auf den Maschinen vorhanden sind.

Die fünfte Ebene ist die externe Beobachtung. Route Collectors, verteilte Messpunkte und kundenseitige Erreichbarkeitstests können zeigen, ob andere Netze die erwartete Route sehen und ob Verkehr den Dienst erreicht. Auch diese Ebene ist nicht allwissend. Eine Route kann an einigen Beobachtungspunkten sichtbar und an anderen noch nicht konvergiert sein. Dennoch ist externe Telemetrie unverzichtbar, weil sie die Lücke zwischen interner Absicht und öffentlicher Wirkung prüft.

Keine dieser Ebenen darf als Ersatz für die anderen dienen. Ein gültiges ROA bestätigt keine aktuelle Ankündigung. Ein sichtbarer BGP-Pfad bestätigt keine korrekte Dienstbindung. Ein interner „advertised“-Wert bestätigt nicht, dass Router die Route exportieren. Ein erfolgreicher HTTP-Test an einem Standort beweist nicht die globale Wiederherstellung. Verantwortlichkeit entsteht erst durch eine nachvollziehbare Beziehung zwischen den Beweisen.

Auswirkungen: Unerreichbarkeit vor der Anwendung

Wenn Cloudflare ein Kundenpräfix nicht mehr ankündigt, hört das Netz des Unternehmens auf, Verkehr für diesen Adressraum anzuziehen. Abhängig davon, ob eine alternative Route existiert, kann der Verkehr einen anderen Weg nehmen oder keine brauchbare Route mehr finden. Für Nutzer äußert sich das typischerweise als Verbindungsfehler oder Zeitüberschreitung. Der Fehler kann auftreten, bevor eine Anfrage überhaupt die Anwendung oder den Ursprungsserver erreicht.

Das unterscheidet den Vorfall von einem gewöhnlichen Anwendungsfehler. Ein Ursprungsserver kann gesund sein und dennoch keine Anfragen erhalten. DNS kann einen korrekten Namen in eine korrekte Adresse auflösen, während der Netzpfad zu dieser Adresse fehlt. Eine Dienstbindung kann in einer Datenbank existieren, obwohl Router das zugehörige Präfix nicht mehr ankündigen. Die Fehlerdomänen überlappen in ihrer Wirkung, sind aber technisch getrennt.

Cloudflare ordnete die Auswirkungen mehreren Diensten zu, die von den betroffenen Ankündigungen abhingen. Dazu gehörten CDN- und Sicherheitsangebote, Spectrum, Dedicated Egress sowie Magic-Transit-Konfigurationen. Daraus dürfen keine ungenannten Kunden oder konkreten Geschäftsverluste abgeleitet werden. Der öffentliche Bericht liefert eine technische Reichweite, aber keine Grundlage für erfundene Kundennamen, Schadenssummen oder individuelle Vertragsfolgen.

Eine besonders wichtige Abgrenzung betrifft 1.1.1.1. Die öffentliche Website des Angebots verzeichnete Fehler, während der Resolverdienst weiterhin DNS-Anfragen beantwortete. Website und Resolver dürfen daher nicht als einheitlich ausgefallener Dienst dargestellt werden. Diese Trennung zeigt zugleich, wie irreführend ein einzelner Marken- oder Domainstatus sein kann: Unterschiedliche Komponenten können verschiedene Adressräume, Routen und technische Abhängigkeiten nutzen.

Die Auswirkungen sind auch nicht als Ursprungspfadmanipulation zu beschreiben. Cloudflare berichtete, dass das eigene Kontrollsystem legitime Kundenpräfixe zurückzog. Es gibt auf Grundlage der eingefrorenen Fakten keinen Beleg dafür, dass ein fremdes autonomes System diese Präfixe übernahm, dass eine unzulässige Ursprungsankündigung die Validierung passierte oder dass Verkehr über ein unerlaubtes Transitszenario weitergegeben wurde. Es handelte sich nicht um einen nachgewiesenen BGP-Hijack, ein Route Leak oder einen Angriff.

Warum der Revert nicht die Wiederherstellung war

Ein Revert kann zwei sehr unterschiedliche Ziele haben. Er kann erstens die weitere Ausführung einer fehlerhaften Änderung stoppen. Zweitens kann er versuchen, alle Wirkungen bereits ausgeführter Mutationen zu beseitigen. Der Cloudflare-Vorfall zeigt, dass das erste Ziel erreicht werden kann, während das zweite offenbleibt. Nachdem der auslösende Wechsel zurückgenommen war, wurden keine neuen Präfixe auf demselben Weg verändert. Bereits zurückgezogene Präfixe, entfernte Einstellungen und beschädigte Beziehungen mussten jedoch gesondert rekonstruiert werden.

Das ist ein klassisches Problem zustandsbehafteter Automatisierung. Wird lediglich Programmcode auf eine frühere Version gesetzt, bleiben von der neueren Version veränderte Daten bestehen. Wird eine Datenbank auf einen früheren Stand gebracht, können zwischenzeitliche legitime Änderungen verlorengehen oder andere Systeme weiterhin eine neuere Konfiguration tragen. Wird eine Routerkonfiguration erneut verteilt, fehlt möglicherweise die Dienstbindung, aus der sie generiert werden sollte. Jede Ebene kann daher einen eigenen Wiederherstellungsmechanismus und einen eigenen Beweis des Erfolgs benötigen.

Die von Cloudflare beschriebenen Wiederherstellungswege spiegeln diese Vielfalt. Kundenseitige erneute Ankündigung konnte einen Teil der Präfixe wieder aktivieren. Eine Datenbankwiederherstellung adressierte gespeicherte Zustände. Die Wiederherstellung von Dienstbindungen schloss Beziehungen zwischen Adressraum und angebotener Funktion. Ein globaler Rollout von Maschinenkonfigurationen brachte operative Systeme erneut in den gewünschten Zustand. Keine dieser Maßnahmen allein erklärt die gesamte Erholung.

Kundenselbstbedienung kann in einer Krise wertvoll sein. Sie verkürzt unter Umständen die Zeit bis zur erneuten Ankündigung und gibt Kunden eine unmittelbare Handlungsmöglichkeit. Sie darf aber nicht zur hauptsächlichen Beweislast des Kunden werden. Der Betreiber hat die fehlerhafte Mutation ausgelöst und verfügt über die umfassendere Sicht auf Konten, Bindungen und Netzwerkzustände. Er muss deshalb selbst feststellen können, welche Präfixe betroffen sind und ob ihre vollständige Zustandskette wieder konsistent ist.

Eine Wiederherstellung ist auch nicht beendet, sobald ein internes Feld wieder „advertised“ anzeigt. Erforderlich sind mindestens die erneute Prüfung der Dienstbindung, der erzeugten Konfiguration, der Routerausführung und der externen Routensicht. Wenn die Anwendung zusätzlich über bestimmte Edge-Einstellungen verfügt, müssen auch diese rekonstruiert und geprüft werden. Erst die Übereinstimmung dieser Ebenen begründet die Aussage, dass das Präfix wieder betriebsbereit ist.

Protokollgrenzen und falsche Diagnosen

BGP definiert, wie autonome Systeme Erreichbarkeitsinformationen austauschen und Routen zurückziehen. Ein Withdrawal teilt Nachbarn mit, dass ein zuvor angebotener Pfad nicht länger verfügbar ist. Diese Protokollwirkung erklärt, weshalb ein legitimer Betreiber durch das Zurückziehen eigener Kundenpräfixe Erreichbarkeit verlieren kann, ohne dass ein Angreifer beteiligt ist. Die BGP-Spezifikation beweist jedoch weder Cloudflares private Konfiguration noch die genaue interne Ursache des Vorfalls.

RPKI stellt eine Infrastruktur bereit, mit der Aussagen über Nummernressourcen und autorisierte Ursprünge kryptografisch abgesichert werden können. Route Origin Validation vergleicht eine empfangene BGP-Ankündigung mit dieser Autorisierung. Das RPKI-to-Router-Protokoll transportiert Validierungsinformationen zu Routern. Diese Mechanismen begrenzen bestimmte Arten falscher Ursprungsankündigungen. Sie erzwingen aber nicht, dass ein berechtigter Betreiber ein Präfix ständig ankündigt.

Ein gültiges ROA kann daher zeitgleich mit einem vollständigen Rückzug der Route bestehen. Aus Sicht der Ursprungsvalidierung gibt es dann keine ungültige Ankündigung; es fehlt vielmehr die erwartete Ankündigung. Diese negative Zustandsänderung ist für Erreichbarkeit ebenso bedeutend wie ein falscher Ursprung, fällt aber nicht unter dieselbe Beweiskategorie. Eine Sicherheitskontrolle für Ursprungsauthentizität ersetzt keine Lebenszykluskontrolle für Verfügbarkeit.

Auch ein Route Leak ist ein anderes Ereignis. Die einschlägigen Protokollarbeiten klassifizieren unerwünschte Weitergabe von Routinginformationen und beschreiben mit BGP Roles sowie Only-to-Customer Mechanismen zur Eindämmung bestimmter Leaks. Beim Februar-Vorfall ist jedoch kein unzulässiges Weitergeben eines Pfades belegt. Die dokumentierte Kernhandlung war der Rückzug legitimer Präfixe durch Cloudflares eigenes Steuerungssystem.

Diese Grenzziehung ist mehr als terminologische Genauigkeit. Falsche Diagnosen führen zu falschen Kontrollen. Gegen einen Hijack helfen Ursprungsautorisierung und Alarmierung über unerwartete Ursprünge. Gegen einen internen, aber formal autorisierten Rückzug braucht es dagegen Änderungsbegrenzung, Abhängigkeitsprüfung, Soll-Ist-Abgleich und Alarmierung über fehlende erwartete Routen. Wer jeden Routingausfall als RPKI-Problem bezeichnet, übersieht den Kontrollpfad, der hier tatsächlich versagte.

Die Addressing API als Verantwortungspunkt

Cloudflare bezeichnete die Addressing API im Zusammenhang mit dem Vorfall als maßgebliche Quelle für Kunden-IP-Adressen. Eine solche Quelle ist nicht nur ein Datenspeicher. Sie prägt nachgelagerte Entscheidungen darüber, welche Präfixe existieren, wem sie zugeordnet sind, welche Dienste sie benötigen und welchen Ankündigungszustand das Netz umsetzen soll. Fehlerhafte Klassifikation an diesem Punkt kann sich deshalb bis zur globalen Routensicht fortpflanzen.

Eine „Source of Truth“ sollte allerdings nicht mit der gesamten Wahrheit des laufenden Systems verwechselt werden. Sie kann den autoritativen Sollzustand enthalten, während Router einen abweichenden Istzustand ausführen. Sie kann eine Dienstbindung kennen, während eine Edge-Konfiguration fehlt. Sie kann einen zurückgezogenen Zustand anzeigen, obwohl externe Nachbarn noch alte Routen sehen. Der Begriff begründet also eine Zuständigkeit für die Sollbeschreibung, nicht die automatische Richtigkeit aller abgeleiteten Zustände.

Gerade Bereinigungsprozesse benötigen eine höhere Beweisschwelle als additive Änderungen. Das Anlegen eines neuen Objekts lässt bestehende Dienste häufig unberührt, während das Löschen oder Deaktivieren eines Präfixobjekts die Erreichbarkeit vieler abhängiger Funktionen zerstören kann. Eine Automatisierung darf „nicht gefunden“, „nicht direkt gebunden“ oder „in einem Teilindex inaktiv“ nicht ohne weitere Prüfung als Löschberechtigung interpretieren.

Vor einer destruktiven Mutation sollte das System eine Abhängigkeitskarte bilden. Diese muss Konto, Delegation, Dienstbindung, Address Map, gewünschten BGP-Status und aktive Netzkonfiguration einschließen. Gibt es einen Widerspruch, sollte der sichere Standard nicht die Löschung, sondern eine Sperre mit gezielter Untersuchung sein. Die Kosten eines falsch erhaltenen Datensatzes sind in vielen Fällen geringer als die Kosten eines fälschlich zurückgezogenen produktiven Präfixes.

Auch die Begründung jeder Entscheidung muss erhalten bleiben. Für jedes als löschbar oder zurückziehbar klassifizierte Präfix sollte nachvollziehbar sein, welche Regel gegriffen hat, welche Eingabedaten verwendet wurden und welche Abhängigkeiten geprüft wurden. Ohne diese Spur lässt sich nach einem Vorfall kaum feststellen, warum eine Kohorte ausgewählt wurde oder ob ein korrigierter Lauf dieselben Fehler wiederholen würde.

Präzise Dry-Runs statt bloßer Mengenschätzungen

Ein Dry-Run für Netzressourcen muss die exakten Objekte und Folgen einer Änderung zeigen. Die Aussage, ein Prozess werde „ungefähr tausend veraltete Datensätze“ bereinigen, reicht nicht. Erforderlich ist eine deterministische Liste der Präfixe, der aktuellen und vorgesehenen Zustände, der betroffenen Dienste, der geplanten Löschungen und der erwarteten Netzoperationen.

Für jeden Eintrag sollte der Dry-Run mindestens erklären, warum er zur Kohorte gehört, ob eine aktive Delegation besteht, welche Dienstbindungen vorhanden sind und ob das Präfix momentan intern oder extern als angekündigt erscheint. Wenn die Eingabedaten diese Fragen nicht beantworten können, ist der Lauf nicht bereit für eine destruktive Ausführung. Unsicherheit muss als Blocker sichtbar werden und darf nicht stillschweigend als Inaktivität gelten.

Ein wirksamer Dry-Run sollte außerdem gegen reale Telemetrie geprüft werden. Soll ein Präfix gelöscht werden, obwohl externe Beobachter es als aktiv sehen, liegt eine entscheidungsrelevante Abweichung vor. Soll es angeblich angekündigt bleiben, während der erzeugte Routerplan einen Withdrawal enthält, ist der Plan intern widersprüchlich. Die Vorschau muss somit nicht nur Datenbankdifferenzen, sondern auch erwartete Änderungen des laufenden Netzes erfassen.

Die Freigabe einer Änderung braucht eine stabile Identität der geprüften Kohorte. Wird zwischen Dry-Run und Ausführung die zugrunde liegende Datenmenge neu berechnet, kann die tatsächlich veränderte Gruppe von der geprüften Gruppe abweichen. Deshalb sollten Auswahl, Abhängigkeiten und vorgesehene Operationen versioniert oder anderweitig unverwechselbar gebunden sein. Eine Genehmigung für Kohorte A darf nicht automatisch für eine später entstandene Kohorte B gelten.

Begrenzte Kohorten und repräsentative Canaries

Eine globale Plattform sollte eine neue Lebenszyklusregel nicht sofort auf den gesamten potenziellen Bestand anwenden. Kleine, begrenzte Kohorten reduzieren die Schadensbreite und schaffen Zeit, falsche Annahmen zu erkennen. Die Begrenzung muss technisch durchgesetzt werden: durch eine maximale Objektzahl, einen prozentualen Anteil, festgelegte Konten oder einen kontrollierten geografischen beziehungsweise funktionalen Ausschnitt.

Die ersten Canaries müssen die Komplexität des Bestands abbilden. Ein Präfix ohne Delegation und mit einer einfachen Bindung ist kein ausreichender Test für Präfixe mit mehreren Diensten, delegierter Nutzung oder abweichenden Ankündigungszuständen. Repräsentative Canaries sollten verschiedene Präfixgrößen, Bindungsarten, Kontobeziehungen und aktuelle BGP-Zustände umfassen. Sie sollen nicht nur zeigen, dass der Normalfall funktioniert, sondern dass die gefährlichen Randfälle korrekt blockiert werden.

Nach jeder Canary-Phase braucht es eine Beobachtungspause, die zur Konvergenz und zum Verteilungspfad des Netzes passt. Die Plattform muss prüfen, ob unerwartete Withdrawals, Verlust von Dienstbindungen, fehlerhafte Edge-Konfigurationen oder externe Erreichbarkeitsänderungen auftreten. Erst danach darf die nächste Kohorte freigegeben werden. Ein schneller Durchlauf ohne ausreichendes Beobachtungsfenster macht aus Canaries bloße Formalität.

Ein automatischer Abbruch sollte nicht allein auf Fehlermeldungen des Änderungsprogramms reagieren. Ein Prozess kann alle Schreiboperationen erfolgreich abschließen und dennoch falsche Routen erzeugen. Abbruchsignale müssen deshalb auch aus unabhängigen Ebenen kommen: ungewöhnliche Rückzüge, Abweichungen zwischen Soll- und Routerzustand, Verlust aktiver Bindungen, fallende Erreichbarkeit oder ungewöhnliche kundenseitige Reaktivierungen.

Löschschutz und Abhängigkeitsbewusstsein

Für Nummernressourcen ist „Löschen“ selten eine lokale Operation. Ein Präfix kann mit Richtlinien, Dienstbindungen, Zertifikaten, Sicherheitsfunktionen, Tunnelkonfigurationen oder Weiterleitungsregeln verbunden sein. Die eingefrorenen Fakten belegen nicht jede denkbare interne Beziehung bei Cloudflare, doch sie belegen, dass Präfixzustand, Dienstbindungen und Edge-Konfigurationen im Vorfall nicht als vollständig unabhängige Größen behandelt werden konnten.

Ein robustes System sollte destruktive Operationen verweigern, solange aktive Abhängigkeiten bestehen. Die Sperre muss dabei auf der tatsächlich wirksamen Beziehung beruhen, nicht nur auf einem optionalen Metadatenfeld. Wird eine Bindung indirekt über Delegation oder eine Address Map hergestellt, muss auch dieser Pfad berücksichtigt werden. Unvollständige Indizes dürfen nicht zur Freigabe einer Löschung führen.

Sinnvoll ist eine mehrstufige Stilllegung: zunächst die Absicht markieren, dann neue Bindungen verhindern, bestehende Abhängigkeiten sichtbar machen, den Verkehr geordnet umleiten oder abfließen lassen und erst nach bestätigter Netzkonvergenz die Ankündigung zurückziehen. Cloudflares aktuelle Anleitung für einen sicheren BYOIP-Rückzug beschreibt auf Kundenseite ebenfalls ein geordnetes Vorgehen, bei dem eine gleich lange eigene Route bereitgestellt, die Konvergenz beobachtet und die Cloudflare-Ankündigung erst anschließend entfernt wird.

Diese aktuelle Anleitung darf nicht als Beweis dafür dienen, wie der interne Februar-Prozess implementiert war. Sie liefert jedoch eine klare Kontrollsprache: Ein Withdrawal ist eine folgenschwere Netzoperation, die eine vorbereitete alternative Route und beobachtete Konvergenz benötigen kann. Für interne Automatisierung muss der Maßstab mindestens ebenso streng sein, weil sie viele Präfixe gleichzeitig betreffen kann und über tieferen Zugriff auf Dienst- und Konfigurationszustände verfügt.

Ein unabhängiger Rollback

Ein Rollback ist nur dann belastbar, wenn er nicht von genau dem fehlerhaften Klassifikationspfad abhängt, der den Vorfall ausgelöst hat. Verwendet die Rücknahme dieselbe Logik und dieselben unvollständigen Indizes wie die ursprüngliche Änderung, kann sie dieselben Objekte übersehen. Ein unabhängiger Wiederherstellungspfad benötigt daher eine zuvor gesicherte Liste der veränderten Präfixe sowie deren vollständigen Vorzustand.

Dieser Vorzustand sollte Konto- und Delegationsbeziehungen, Dienstbindungen, Address Maps, vorgesehenen Ankündigungsstatus und die daraus erzeugten Konfigurationen enthalten. Zusätzlich ist eine Momentaufnahme externer Beobachtungen nützlich. Sie zeigt, welche Präfixe unmittelbar vor der Änderung sichtbar waren und aus welchen Ursprüngen sie angekündigt wurden. Der Rollback kann dann nicht nur Daten zurückschreiben, sondern die erwartete reale Wirkung überprüfen.

Für jede ausgeführte Mutation sollte eine inverse Operation definiert und getestet sein. Wurde ein Präfix zurückgezogen, muss die Wiederherstellung die Ankündigung erneut erzeugen können. Wurde eine Bindung gelöscht, muss sie mit ihren maßgeblichen Eigenschaften rekonstruierbar sein. Wurde Konfiguration von Edge-Systemen entfernt, muss ein kontrollierter Rollout sie wiederherstellen. Die bloße Rückkehr des Anwendungscodes zu einer früheren Version erfüllt diese Anforderungen nicht.

Entscheidend ist schließlich ein Abschlussbericht pro Objekt. Ein Präfix gilt nicht als wiederhergestellt, weil ein globaler Rollback beendet wurde. Es gilt als wiederhergestellt, wenn die vorgesehenen Beziehungen vorhanden sind, der Routerzustand dem Soll entspricht, externe Beobachter die erwartete Route sehen und der gebundene Dienst erreichbar ist. Ausnahmen müssen einzeln sichtbar bleiben, statt in einem aggregierten Erfolgswert zu verschwinden.

Übergreifende Abstimmung als Kernkontrolle

Die stärkste Lehre des Vorfalls ist die Notwendigkeit einer kontinuierlichen Reconciliation. Das Steuerungssystem sollte regelmäßig den registrierten und autorisierten Bestand mit Kontozuordnungen, Dienstbindungen, beabsichtigten BGP-Zuständen, ausgerollten Konfigurationen und externer Routensicht vergleichen. Diese Prüfung darf nicht erst nach einem Ausfall beginnen.

Ein solcher Abgleich muss beide Fehlerklassen erkennen: Eine Route kann fehlen, obwohl sie angekündigt sein sollte; sie kann aber auch sichtbar sein, obwohl sie zurückgezogen sein sollte. Ebenso kann eine Dienstbindung ohne Route oder eine Route ohne gültige Dienstbindung existieren. Jede Abweichung braucht eine eindeutige Klassifikation und einen verantwortlichen Wiederherstellungspfad.

Aggregierte Kennzahlen reichen nicht. Die Aussage, 99,9 Prozent der Präfixe seien konsistent, kann eine kleine Zahl hochkritischer Ausfälle verdecken. Für kundenbezogene Nummernressourcen muss die Plattform objektgenau wissen, welche Präfixe abweichen, seit wann, auf welchen Ebenen und mit welcher Kundenwirkung. Eine globale Kennzahl ist für Steuerung hilfreich, ersetzt aber nicht die Einzelbeweiskette.

Externe Beobachtung sollte organisatorisch und technisch von der Änderungsautomatisierung getrennt sein. Wenn derselbe interne Status sowohl die Änderung auslöst als auch ihren Erfolg bestätigt, kann ein gemeinsamer Fehler beide Seiten täuschen. Route Collectors, verteilte Messpunkte und unabhängige Erreichbarkeitstests liefern keine perfekte Wahrheit, reduzieren aber das Risiko einer vollständig selbstreferenziellen Kontrolle.

Kommunikation und überprüfbare Wiederherstellung

In einem Routingvorfall benötigen Kunden mehr als eine allgemeine Meldung, dass Dienste beeinträchtigt seien. Sie müssen erkennen können, ob ihr Präfix betroffen ist, ob Cloudflare es intern als angekündigt betrachtet und ob externe Beobachtungen diesen Status bestätigen. Eine präfixbezogene Statusanzeige kann deshalb ein wesentlicher Teil der Wiederherstellung sein.

Für betroffene Kunden sollte klar werden, ob Selbstbedienung empfohlen wird oder ob der Betreiber die Wiederherstellung zentral übernimmt. Wenn beide Wege parallel existieren, braucht es Schutz vor widersprüchlichen Operationen. Eine kundenseitige erneute Ankündigung darf nicht kurz darauf von einem noch laufenden fehlerhaften Prozess rückgängig gemacht werden. Ebenso darf sie nicht als Nachweis dienen, dass alle zugehörigen Bindungen und Edge-Einstellungen automatisch korrekt sind.

Die Kommunikation sollte den Unterschied zwischen gestoppter Ursache und abgeschlossener Wiederherstellung benennen. „Die Änderung wurde zurückgenommen“ ist nicht gleichbedeutend mit „alle Präfixe sind wieder erreichbar“. Ein genauer Status kann getrennt ausweisen, wie viele Präfixe nicht weiter mutiert werden, wie viele intern rekonstruiert sind, wie viele extern wieder sichtbar sind und wie viele Dienste eine zusätzliche Prüfung benötigen.

Cloudflare hat Verbesserungen angekündigt. Diese Ankündigungen sind für die Bewertung relevant, belegen aber noch nicht unabhängig, dass die neuen Kontrollen in allen Fällen wirksam sind. Belastbare Wirksamkeit würde wiederholbare Tests, dokumentierte Fehlerfälle, Ergebnisse begrenzter Rollouts und nachweisbare Abstimmung zwischen Daten- und Netzebene erfordern. Die öffentliche Faktenlage gestattet die Aussage, dass Kontrollen im konkreten Vorfall versagten und dass das Unternehmen Abhilfen beschrieb. Sie gestattet keine weitergehende Behauptung über deren vollständig verifizierten Erfolg.

Ein praktischer Rechenschaftsmaßstab

Ein Betreiber kann die Qualität seiner Präfixkontrollen zunächst daran messen, ob jede Änderung eine exakte, unveränderlich gebundene Objektliste besitzt. Für jedes Präfix müssen Ausgangszustand, Zielzustand, Begründung und Abhängigkeiten bekannt sein. Fehlt eines dieser Elemente, darf eine destruktive Massenänderung nicht beginnen.

Der zweite Maßstab ist die Begrenzung der Schadensbreite. Eine neue Regel sollte nur kleine Kohorten verändern können, bis repräsentative Canaries alle relevanten Ebenen passiert haben. Die Plattform muss eine technische Obergrenze durchsetzen und darf sich nicht allein auf eine menschliche Erwartung verlassen, der Lauf werde klein bleiben.

Der dritte Maßstab ist die Qualität des Löschschutzes. Aktive Dienstbindungen, Delegationen oder laufende Ankündigungen müssen eine Bereinigung blockieren oder in einen ausdrücklich genehmigten Stilllegungsprozess überführen. „Unbekannt“ darf nie automatisch „unbenutzt“ bedeuten.

Der vierte Maßstab ist die Unabhängigkeit des Rollbacks. Die Rücknahme muss eine gesicherte Vorzustandsliste verwenden, inverse Operationen für alle mutierten Ebenen besitzen und auch dann funktionieren, wenn die reguläre Steuerungslogik fehlerhaft ist. Regelmäßige Übungen sollten nicht nur das Stoppen eines Jobs, sondern die vollständige Rekonstruktion gelöschter Zustände prüfen.

Der fünfte Maßstab ist die übergreifende Verifikation. Nach jeder Änderung müssen Sollzustand, Dienstbindung, Routerausführung und externe Routensicht verglichen werden. Ein Abschluss ist erst zulässig, wenn Abweichungen entweder beseitigt oder als konkrete offene Fälle ausgewiesen sind.

Der sechste Maßstab ist die kundenseitige Nachvollziehbarkeit. Kunden sollten den Status ihrer Präfixe sehen, Änderungen zeitlich einordnen und belastbare Hinweise zur Wiederherstellung erhalten können. Selbstbedienung ist eine zusätzliche Resilienzfunktion, kein Ersatz für die Verantwortung des Betreibers.

Der siebte Maßstab ist die Qualität der Nachbereitung. Eine Aufarbeitung sollte Zeitangaben, Kohortengrößen, Mechanismus, Wiederherstellungswege und verbleibende Unsicherheiten trennen. Abweichende Zeitangaben wie im öffentlichen Bericht müssen sichtbar bleiben. Korrekte Rechenschaft bedeutet nicht, jede Unschärfe zu beseitigen, sondern sie so zu kennzeichnen, dass Leser ihre Bedeutung beurteilen können.