Zusammenfassung

  • Ein Bereinigungsprozess übermittelte pending_delete ohne Wert. Die Addressing API verstand dies als Abfrage aller BYOIP-Präfixe; der Prozess löschte Präfixe und abhängige Dienstbindungen.
  • Etwa 1.100 Präfixe wurden zurückgezogen. Rund 800 ließen sich durch erneute Ankündigung wiederherstellen; bei etwa 300 fehlte zusätzlich die Edge-Dienstkonfiguration, sodass eine spätere globale Wiederherstellung nötig war. Die Route war nur eine Ebene des Dienstes.

Die zweite Wiederherstellungsuhr

Cloudflares Bericht zum 20. Februar 2026 lässt sich als BGP-Ausfall zusammenfassen. Der entscheidende Teil begann jedoch, als Routen zurückkehrten: Bei manchen Kundenpräfixen war die Ankündigung wieder da, während Cloudflares Edge-Systeme nicht mehr wussten, welcher Dienst den Verkehr für diese Adressen übernehmen sollte. Die Route kam vor dem Dienst zurück.

Eine öffentliche IP-Adresse ist keine Anwendung. Ein Präfix kann dem Kunden registriert sein, für die Ankündigung durch einen Anbieter freigegeben, in dessen Adressdatenbank erfasst, per BGP angekündigt, an ein Produkt gebunden und auf Edge-Systemen konfiguriert sein. Diese Zustände hängen zusammen, sind aber nicht gleichbedeutend. Eine von außen sichtbare Route beweist nicht, dass Pakete beim richtigen Kundendienst landen.

Laut Cloudflares Postmortem sollte ein regelmäßig ausgeführter Bereinigungsauftrag die Entfernung von Präfixen automatisieren, die Kunden aus BYOIP löschen lassen wollten. Der Auftrag fragte die API mit pending_delete ohne Wert ab. In der beschriebenen Serverimplementierung filterte der Parameter nur dann auf ausstehende Löschungen, wenn sein Textwert nicht leer war. Ohne Wert gab die API daher alle BYOIP-Präfixe zurück. Der Auftrag behandelte alle Ergebnisse als Löschkandidaten und entfernte abhängige Objekte, darunter Dienstbindungen.

Cloudflare zufolge gab es weder einen Angriff noch böswillige Aktivität. Das Addressing-API-Release war um 17:46 UTC abgeschlossen; zehn Minuten später startete der Bereinigungsauftrag. Ingenieure fanden den Prozess und stoppten ihn um 18:46 UTC. In dieser Stunde wurden etwa 1.100 Präfixe zurückgezogen. Cloudflare beziffert dies auf 25 Prozent der weltweit angekündigten 4.306 BYOIP-Präfixe. Der Bericht nennt außerdem eine Sicht von 6.500 Präfixen zu einem Peer. Das ist ein anderer Nenner und darf nicht mit der globalen BYOIP-Zahl verwechselt werden.

Die Änderung wurde schrittweise ausgerollt und erreichte deshalb nicht alle Kunden, bevor sie gestoppt wurde. Das begrenzte den Wirkungsbereich, ersetzt aber keinen Wiederherstellungsplan.

Angekündigt heißt nicht bedient

Cloudflares Produktdokumentation unterscheidet BGP-Ankündigung und Dienstbindung. Die Route zieht den Verkehr für ein Präfix ins Cloudflare-Netz; die Bindung ordnet ihn Produkten wie CDN, Spectrum oder Magic Transit zu. Beim CDN kann eine Adresszuordnung hinzukommen. Löscht eine Automatisierung sowohl das Präfix als auch seine Bindungen, bringt eine erneute Ankündigung den Verkehr möglicherweise zurück ins Anbieternetz, ohne den Produktpfad am Edge wiederherzustellen.

Darum war die Selbsthilfe im Dashboard nur für einen Teil der Fälle geeignet. Um 19:19 UTC forderte Cloudflare Kunden auf, ihre Präfixe erneut anzukündigen. Gegen 20:20 waren etwa 800 wiederhergestellt. Rund 300 ließen sich nicht durch Umschalten der Ankündigung reparieren, weil auch ihre Dienstkonfigurationen von Edge-Systemen entfernt worden waren. Kunden konnten eine Bindung, die in ihrer Kontokonfiguration nicht mehr existierte, nicht selbst neu anlegen. Ingenieure mussten den Zustand wiederherstellen und eine globale Konfigurationsänderung ausrollen; dieser Schritt endete um 23:03 UTC.

Cloudflare gab eine Gesamtdauer von sechs Stunden und sieben Minuten an.

Der öffentliche Bericht nennt weder die Zahl betroffener Kunden noch Regionen, Umsatzverluste oder SLA-Gutschriften. Er beschreibt aber unterschiedliche Pfade: nur die Route war zurückgezogen, manche Bindungen waren entfernt oder alle Dienstbindungen fehlten. Hinter derselben Bezeichnung „BYOIP-Ausfall“ lagen verschiedene Verantwortliche und Wiederherstellungszeiten.

Auch die Website one.one.one.one zeigte HTTP-403-Fehler. Cloudflare betont, dass die DNS-Auflösung über den öffentlichen Resolver 1.1.1.1 einschließlich DNS over HTTPS nicht beeinträchtigt war. Der sichtbare Website-Fehler belegte Auswirkungen auf eine BYOIP-gestützte Weboberfläche, nicht den Ausfall des Resolvers. Diese Unterscheidung hält die Fehleranalyse auf der richtigen Ebene.

Konfiguration ist Teil der Netzinfrastruktur

Cloudflare beschreibt die Addressing API als maßgeblichen Adressdatensatz, dessen Änderungen ins globale Netzwerk übernommen wurden. Kundenanfragen lösten Datenbanken und Abläufe aus, die Ankündigungen und Produktbindungen änderten. Laut Bericht dienten dieselben gespeicherten Daten sowohl als Sollkonfiguration des Kunden als auch als Auslöser operativer Aktionen. Das erschwerte den manuellen Rollback: Ingenieure mussten Datenbank-Snapshots wiederherstellen, statt Soll- und Istzustand gegeneinander zu prüfen.

Auch die Testlücke war konkret. Staging- und Mockdaten reichten für diesen Fall nicht aus. Das Team hatte den Selbstbedienungspfad getestet, den ein Kunde selbst durchläuft, nicht aber einen separaten Task-Runner, der ohne ausdrücklichen Kundenauftrag Daten änderte. Ein manuell angestoßener API-Pfad kann sicher sein, während ein geplanter Auftrag mit derselben API Schaden anrichtet. Wer nur die Oberfläche testet, modelliert die Identität und Rechte der Automatisierung nicht mit.

Cloudflares angekündigte Maßnahmen gingen deshalb über eine Parameterkorrektur hinaus: einheitlichere API-Schemata, eine Trennung von konfiguriertem und operativem Zustand, schrittweise und gesundheitsüberwachte Auslieferung von Konfigurations-Snapshots, automatischer Stopp oder Rollback sowie Schutzschalter bei schnellen oder großflächigen Präfixrücknahmen. Das Unternehmen nannte außerdem die Gesundheit von Kundendiensten als mögliches Stoppsignal. Der Bericht aus dem Februar kündigt diese Arbeiten an; er belegt nicht, dass sie später vollständig umgesetzt wurden.

BYOIP soll dem Kunden eine vertraute IP-Identität erhalten und zugleich die Nutzung eines Anbieternetzes ermöglichen. Betrieblich bleiben die Rollen verteilt: Der Kunde kann den Block besitzen und die Ankündigung erlauben, während der Anbieter die Steuerung betreibt, die Routen zurückzieht, Produkte zuordnet und Konfigurationen auf Edge-Systeme verteilt. Ein portabler Vermögenswert kann weiterhin von einem Zustand abhängen, den sein Eigentümer allein nicht wiederherstellen kann.

Das ist kein Argument gegen verwaltetes Routing. Es ist ein Grund, Kontinuität an der Dienstgrenze zu definieren. Cloudflares Dokumentation zur dynamischen Ankündigung sagt, eine erfolgreiche API-Antwort bestätige lediglich die Registrierung des Auftrags; die Route brauche zusätzliche Zeit zur Verbreitung. Der BYOIP-Leitfaden verlangt außerdem, Dienstbindungen vor einer Produktionsankündigung fertigzustellen. Eingangsbestätigung und laufender Dienst sind zwei unterschiedliche Nachweise.

Was ein Kontinuitätsversprechen nachweisen muss

Kunden müssen nicht nur wissen, ob ein Anbieter Präfixe ankündigen kann, sondern welcher Zustand ausgefallen ist und wer ihn reparieren darf. Ein Wiederherstellungsplan sollte mindestens vier Zeitpunkte getrennt erfassen: den Stopp des schädlichen Auftrags, die erneute Sichtbarkeit der Route aus externen Netzen, die Wiederherstellung der Dienstbindungen und Edge-Konfiguration sowie den erfolgreichen Anwendungstest. Jeder Schritt hat einen eigenen Verantwortlichen und eine eigene Uhr.

Ein aussagekräftiger Abnahmetest lässt die Route bestehen, entfernt aber die Dienstbindung. Erkennt der Anbieter den Unterschied? Kann er die Konfiguration eines einzelnen Kunden wiederherstellen, ohne die gesamte Datenbank riskant zurückzusetzen? Stoppt der Rollout bei fehlender Dienstgesundheit oder nur bei sinkender Routenzahl? Was darf der Kunde während einer Schreibsperre noch ändern und wie lange gilt sie?

Ein alternativer Ankündigungsweg kann Teil der Kundenplanung sein, ersetzt aber nicht grundsätzlich die Wiederherstellung beim Anbieter. Cloudflares Betriebshinweise warnen vor überlappenden Ankündigungen und verlangen eine bewusste Steuerung der Routenpräferenz. Ein Ausweichweg hilft nur, wenn Ursprungsautorisierung, Verkehrsbehandlung und Dienstverhalten gemeinsam getestet wurden. Pakete zu einem Netz ohne Anwendungskonfiguration umzuleiten, verschiebt den Fehler lediglich.

Die Schlussfolgerung ist messbar: Eine Adresse benennt eine Ressource; eine Route behauptet Erreichbarkeit; eine Dienstbindung bestimmt die Verarbeitung; ein laufender Dienst ist das Ergebnis. Kontinuitätsberichte sollten diese Ebenen nicht in einer grünen Statusanzeige zusammenziehen. Die Rückkehr des Präfixes war ein Fortschritt, aber nicht das Ende der Wiederherstellung.

Quellen