Cloudflare-1.1.1.1-Störfall vom 14. Juli 2025

 (blog.cloudflare.com)
1 Punkte von GN⁺ 2025-07-17 | 1 Kommentare | Auf WhatsApp teilen
  • Cloudflare verursachte am 14. Juli 2025 während einer Änderung der Service-Topologie einen vollständigen 62-minütigen Ausfall des öffentlichen DNS-Resolvers 1.1.1.1
  • Die große Mehrheit der weltweiten Nutzer war direkt betroffen und konnte das Internet zeitweise nicht nutzen
  • Die Ursache des Ausfalls war eine Fehlkonfiguration in einem internen Legacy-System und stand weder mit einem externen Angriff noch mit einem BGP-Hijacking in Zusammenhang
  • Der Ausfall wurde durch das Zusammenwirken kumulierter fehlerhafter Konfigurationsänderungen und eines netzwerkweiten Resets ausgelöst
  • Als Maßnahmen zur Vermeidung künftiger Vorfälle plant Cloudflare die Einführung eines schrittweisen Deployment-Systems sowie die Ablösung des Legacy-Konfigurationssystems

Überblick

Am 14. Juli 2025 verursachte Cloudflare während einer Änderung der Service-Topologie eine globale Netzwerkstörung beim öffentlichen DNS-Resolver 1.1.1.1. Dadurch erlebten Nutzer von 1.1.1.1 und den Gateway-DNS-Diensten 62 Minuten lang keine Internetverbindung oder erhebliche Serviceverschlechterungen. Ursache war ein Konfigurationsfehler in einem internen Legacy-System, nicht ein externer Angriff oder BGP-Hijacking.

Umfang und Auswirkungen des Ausfalls

  • Zwischen 21:52 UTC und 22:54 UTC war der 1.1.1.1-Resolver weltweit praktisch nicht verfügbar
  • Die meisten globalen Kunden konnten keine Domainnamen mehr auflösen, wodurch die Internetnutzung selbst unmöglich wurde
  • Die Situation während des Ausfalls konnte in Cloudflare Radar beobachtet werden
  • Ursache war eine Fehlkonfiguration in einem Legacy-System, das die Infrastruktur zur Verwaltung der Ankündigung von Cloudflare-eigenen IP-Adressen im Internet steuert
  • Der gesamte Traffic, der Cloudflare über den 1.1.1.1-Kanal erreichte, war kritisch betroffen

Ursache und Hintergrund des Vorfalls

  • Cloudflare nutzt für globale Dienste wie den DNS-Resolver Anycast-Routing
  • Dienste werden in verschiedenen Regionen bereitgestellt, einige Services mit Anforderungen an Datenlokalisierung sind jedoch auf bestimmte Regionen beschränkt
  • Am 6. Juni wurde bei einer Konfigurationsänderung zur Vorbereitung eines späteren DLS-Dienstes (Datenlokalisierung) der 1.1.1.1-Resolver-IP-Bereich unbeabsichtigt in das neue DLS aufgenommen
    • Dieser Fehler wurde nicht sofort wirksam und hatte zunächst keine Auswirkungen, sodass kein Alarm ausgelöst wurde
  • Am 14. Juli wurde eine Änderung angewendet, die einen Offline-Standort zu Testzwecken zur DLS-Topologie hinzufügte
    • Dadurch wurde die Netzwerkkonfiguration global zwangsweise aktualisiert, wodurch der bestehende Fehler sichtbar wurde
    • Die 1.1.1.1-Prefixes wurden aus Rechenzentren weltweit zurückgezogen, was zur Unterbrechung des Dienstes führte

Timeline des Ausfalls (Kurzfassung)

  • 2025-06-06 17:38: Konfigurationsänderung für den DLS-Dienst enthält 1.1.1.1-Prefixes (keine Auswirkung, Fehler bleibt verborgen)
  • 2025-07-14 21:48: Konfigurationsänderung aktualisiert die netzwerkweite Konfiguration; der globale Rückzug der 1.1.1.1-Prefixes beginnt
  • 2025-07-14 21:52: Globaler DNS-Traffic bricht stark ein
  • 2025-07-14 22:01: Interner Alarm, Vorfall wird erklärt
  • 2025-07-14 22:20: Rollback auf die vorherige Konfiguration, Beginn der Service-Wiederherstellung
  • 2025-07-14 22:54: Traffic normalisiert sich, Alarm wird aufgehoben, Vorfall beendet

Betroffene IPs und Protokolle

  • Betroffener Bereich: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 sowie weitere breite IPv4- und IPv6-Prefixes
  • Bei Anfragen über UDP, TCP, DoT (DNS over TLS) wurde ein starker Traffic-Rückgang beobachtet
  • DoH (DNS over HTTPS) war kaum betroffen, da es häufig auf der Domain cloudflare-dns.com basiert

Technische Beschreibung des Ausfalls

Ausfall des 1.1.1.1-Resolver-Dienstes

  • Am 6. Juni wurde bei einer vorbereitenden Konfigurationsänderung für DLS ein Fehler in die Prefixes eingefügt
  • Am 14. Juli wurde zu Testzwecken ein Offline-Standort hinzugefügt, wodurch die netzwerkweite Konfiguration aktualisiert wurde
  • Dabei wurden die Prefixes des 1.1.1.1-Resolvers weltweit auf einen einzelnen Offline-Standort beschränkt und der Dienst dadurch zurückgezogen

Analyse der technischen Ursache

  • Cloudflare betreibt derzeit Legacy-Systeme und neue strategische Systeme parallel und synchronisiert Routing-Ankündigungen nach Adressraum

  • Das Legacy-System erfordert manuelle Updates und bietet keine schrittweise Ausbringung, was die Fehlerwahrscheinlichkeit erhöht

    • Es gab Peer Review und Prüfungen durch andere Engineers, aber keine Struktur, die eine schrittweise Ausbringung wie Canary-Deployments garantiert

  • Der neue Ansatz ist topologiezentriert statt hartkodiert und führt Mechanismen für schrittweise Änderungen und Monitoring ein

  • Um 22:01 wurde ein Alarm für den DNS-Resolver ausgelöst

  • In den internen BGP-Routing-Tabellen wurde bestätigt, dass alle Resolver-Routen verschwunden waren

  • Nach dem Rückzug der Prefixes versuchte Tata Communications India (AS4755), das Subnetz 1.1.1.0/24 per BGP anzukündigen

    • Das ähnelte zwar vorübergehend einem Prefix-Hijack, stand aber nicht in direktem Zusammenhang mit dem Vorfall

Wiederherstellung und Folgemaßnahmen

  • Um 22:20 UTC erfolgte ein Rollback auf die vorherige Konfiguration sowie die erneute Ankündigung der Prefixes
    • Etwa 77 % des Traffics wurden sofort wiederhergestellt
    • Einige Edge-Server wurden automatisch zurückgesetzt und mussten über ein manuelles Änderungsmanagement-System erneut eingespielt werden
    • Aus Netzwerksicherheitsgründen erfolgt normalerweise ein schrittweises Rollout, in diesem Vorfall wurde nach Verifikation jedoch schnell ausgerollt
  • Um 22:54 kehrten alle Standorte zum Normalbetrieb zurück

Geplante Verbesserungen

  • Einführung eines schrittweisen Deployment-Systems (Stage Deployment): Abschaffung des Legacy-Deployments, Einführung einer gesundheitsbasierten automatischen Rollback-Struktur
  • Beschleunigte Ablösung der Legacy-Systeme: Entfernung riskanter manueller Konfigurations- und Deployment-Verfahren, bessere Dokumentation und stärkere Testabdeckung

Fazit

Der Ausfall des Cloudflare-1.1.1.1-DNS-Resolvers wurde durch einen internen Konfigurationsfehler verursacht. Cloudflare will künftig mit voller Priorität Stabilitätsverbesserungen und Maßnahmen zur Verhinderung ähnlicher Vorfälle umsetzen. Das Unternehmen entschuldigte sich bei den Kunden und will die Maßnahmen zur Minimierung vergleichbarer Ereignisse weiter verstärken.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-17
Hacker-News-Kommentare

  • Wenn der 1.1.1.1-Resolver (DNS) für viele Nutzer nicht funktioniert, bedeutet das praktisch, dass fast keine Internetdienste mehr erreichbar sind. Aber sind auf den meisten Geräten nicht normalerweise zwei DNS-Server konfiguriert? Ich frage mich, ob der zweite auch ausgefallen ist, und falls nicht, warum nicht auf ihn umgeschaltet wurde

    • Cloudflare empfiehlt, sowohl 1.1.1.1 als auch 1.0.0.1 als DNS-Server zu konfigurieren. Wegen des Konfigurationsfehlers, der diesen Ausfall verursacht hat, wurden jedoch Cloudflares BGP-Ankündigungen für beide Präfixe 1.1.1.0/24 und 1.0.0.0/24 gestoppt
    • Unter Android kann man unter Einstellungen → Netzwerk & Internet → Private DNS meines Wissens nur einen einzigen "Private DNS provider hostname" eintragen. Und ich verstehe nicht, warum dort keine IP-Adresse wie 1.1.1.1 akzeptiert wird, sondern zwingend ein Hostname wie one.one.one.one verlangt wird. Wenn man einen DNS-Server festlegt, ist eine Konfiguration per IP doch viel sinnvoller
    • Zwei Einträge sind besser als keiner, aber nicht perfekt. Wenn eine Seite ausfällt, wird meist nicht verfolgt, welche noch korrekt funktioniert, sodass man typischerweise lange Wartezeiten und sporadische Probleme erlebt. Das gilt weiterhin, solange man keine anspruchsvollere Konfiguration wie einen lokalen cachdenden DNS-Proxy mit mehreren Upstreams verwendet
    • Wenn man meint, über DNS mitreden zu können, sollte man meiner Meinung nach seinen eigenen Dienst betreiben. Die Root-Domain . funktioniert seit Jahrzehnten gut; der Hauptgrund für Probleme bei 1.1.1.1 ist nicht DNS selbst, sondern Anycast. Cloudflare (und auch Google usw.) bestehen auf "Vanity"-IP-Adressen — um solche IPs nutzen zu können, braucht man Anycast, und das eigentliche Problem ist nicht DNS, sondern Anycast. Ich empfehle, mehr als einen Anbieter auszuwählen und zu konfigurieren
    • Die von Cloudflare empfohlene Konfiguration sieht vor, 1.0.0.1 als sekundären DNS-Server als Backup zu verwenden, aber bei diesem Vorfall war auch dieser Server betroffen

  • Es ist interessant, dass der Traffic zu 1.1.1.1 bei einem Ausfall von ungefähr 20 Minuten nur um etwa 20 % zurückging. Erstaunlich, dass Cloudflare weiter an so simplen und alten Problemen scheitert (das war weder das erste Mal noch wahrscheinlich das letzte). Googles 8.8.8.8 und 8.8.4.4 hatten weltweit fast ein Jahrzehnt lang (1) keine einzige Sekunde Ausfallzeit. (1: Es gab einige regionale Probleme, aber das lag am Internet; selbst wenn verschiedene Google-Dienste schwere Störungen hatten, lief DNS selbst weiter normal.)

    • Nicht nur Verfügbarkeit, auch Geschwindigkeit und Privatsphäre sind bei DNS wichtig. Nutzer in Europa könnten statt US-Unternehmen (mit CLOUD Act) auch etwas aus der Liste europäischer alternativer DNS-Anbieter wählen
    • Auf die Meinung, solche Engineering-Probleme in einer Netzwerkumgebung von der Größe und Komplexität Cloudflares müssten sich doch leicht lösen lassen, wurde erklärt, dass es sich realistisch um Probleme handelt, die nur 0,001 % der Branche überhaupt erleben
    • Cloudflare hat zwar eine vernünftige Kultur beim Umgang mit Vorfällen, aber es fehlen Anreize, proaktive Präventionsmaßnahmen aktiv zu fördern
    • Die erwähnten 20 % bedeuten, dass einige Clients/Resolver den DNS-Server nach mehreren Antwortfehlern vorübergehend als ausgefallen markieren, damit Nutzer nicht bei jeder Anfrage 500 Timeouts abwarten müssen. Langfristig kehrt das Volumen laut Traffic-Grafik wieder zum Normalzustand zurück
    • Ich stimme zu, dass viele Leute Google DNS nicht verwenden möchten

  • Ich bin überrascht, dass es mehr als 5 Minuten dauerte, bis die Auswirkungen erkannt wurden, obwohl der Traffic des Hauptprotokolls auf 10 % fiel und dort blieb. Ich habe noch nie ein System in dieser Größenordnung betrieben, hätte aber erwartet, dass so etwas sofort einen Alarm auslöst. Mich würde interessieren, ob Fachleute das für angemessen halten

    • Zwischen Erkennungsgeschwindigkeit und Fehlalarmrate gibt es einen ständigen Zielkonflikt. Monitoring-Systeme wie Nagios oder Icinga lösen normalerweise erst nach drei aufeinanderfolgenden Fehlschlägen ein Ereignis aus, weil kurzzeitige Fehler häufig sind. Wenn es zu viele Alarme gibt, stumpfen die Zuständigen ab und reagieren eher mit "Warten wir kurz ab". Ich habe zwar keinen globalen Dienst wie Cloudflare selbst betrieben, aber eine verlässliche Erkennung nach 8 Minuten überrascht mich nicht
    • Wenn solche Grafiken wie früher in einem NOC an der Wand hingen, hätte wahrscheinlich jemand einmal hingeschaut, "komisch" gesagt und wäre sofort losgerannt
    • Ich denke, der Dienst war zu Beginn der Auswirkungen nicht vollständig ausgefallen, insbesondere wenn das Ganze am Anfang eines globalen Rollouts stand, und es hat gedauert, bis die Auswirkungen messbar wurden
    • Wenn man den Alarm innerhalb einer Minute auslösen lässt, testet man am Ende nur die Performance der Alarm-Infrastruktur. Die eigentliche Frage ist, ob Datenerfassung und Berechnung im Minutentakt überhaupt zuverlässig möglich sind
    • Wenn ein Dienst zur Metrikaggregation abstürzt, können Kennzahlen verzögert ankommen und wie ein 100-%-Einbruch aussehen, bis das System neu ausgerollt ist. Wenn man schon nach 1 Minute benachrichtigt, werden unnötig viele Leute um 2 Uhr morgens geweckt, und bei Wiederholungen werden die Alarme am Ende immer lockerer — deshalb pendelt sich so etwas oft bei etwa 5 Minuten ein

  • Guter zusammenfassender Beitrag. Interessant fand ich den Punkt, dass DoH (DNS over HTTPS) meist über die Domain cloudflare-dns.com angesprochen wird (manuell konfiguriert oder im Browser) und deshalb, weil keine IP-Adresse verwendet wird, relativ wenig von der Störung betroffen war. Ich war gestern betroffen; obwohl DoH auf meinem Router aktiviert war, ließ sich gar nichts auflösen, und ein Wechsel auf 8.8.8.8 löste das Problem

    • Ich frage mich, wie DoH dabei funktioniert. Man muss ja die IP von cloudflare-dns.com kennen, und der Router könnte dafür 1.1.1.1 verwendet haben
    • Heute habe ich eine neue Domain eingerichtet, und für etwa 20 Minuten war sie nur in Firefox auf einem Laptop erreichbar. Googles DNS-Tool zeigte an, dass die Domain aktiv sei, und auf dem AWS-Server funktionierte auch SSH, aber in meinem lokalen Netzwerk gingen keine DNS-Lookups. Ich habe den Cache geleert und alles Mögliche probiert, aber nur dieser Firefox-Browser war separat so konfiguriert, dass er Cloudflare DoH verwendete
    • Ich stimme nicht zu. Die eigentliche Ursache wird durch pedantische Begriffe unnötig verschleiert, sodass selbst erfahrene Administratoren verwirrt werden. Der Begriff "legacy" ist nicht klar und wirkt eher abstrakt und intransparent. Bei einem Satz wie "Legacy-Komponenten nutzen kein schrittweises Deployment, und Cloudflare wird einen modernen Ansatz mit schrittweisem Deployment und Rollback einführen" versteht man zwar ungefähr, was gemeint ist, aber es gibt keinen Grund, das so schwer verständlich zu formulieren
    • Mein Unifi-Router scheint bei automatischem DoH gleichzeitig Cloudflare und Google zu verwenden. Ich habe keine Auswirkungen bemerkt, also lief Cloudflare DoH entweder weiter oder es wurde sofort zu Google gewechselt
    • Insgesamt eine gute Zusammenfassung, aber die Zeitleiste am Anfang des Beitrags stimmt tatsächlich nicht mit den Fakten überein

  • Mit dnsmasq kann man mehrere DNS-Server gleichzeitig konfigurieren und dann den verwenden, der am schnellsten antwortet. Selbst wenn ein Dienst ausfällt, merkt man davon fast nichts

    • Wenn man all-servers ohne die Einstellung strict-order verwendet, sendet dnsmasq automatisch Wiederholungsanfragen an alle Server. Wenn man jedoch systemd-resolved nutzt, wird nur der Reihe nach erneut versucht, daher ist es wichtig, Server verschiedener Anbieter abwechselnd einzutragen. Wenn man wie im Beispiel zusätzlich IPv4 und IPv6 kombiniert, wird das Failover noch schneller. Bei Quad9 ist auf der genannten IP standardmäßig Filterung aktiviert, bei den beiden anderen nicht, daher können sich die Auflösungsergebnisse unterscheiden. Wenn einem persönlich die DNSSEC-Validierung wichtig ist, sollte man keine validierenden und nicht validierenden Resolver mischen (die im Beispiel genannten DNS-Server unterstützen aber alle DNSSEC)
    • Gibt es eine privatere Konfiguration, wenn man nicht möchte, dass Big-Tech-Unternehmen (Cloudflare, Google usw.) alle DNS-Anfragen sehen, und man auch kein DoH will? Eine Liste vertrauenswürdiger kleinerer DNS-Anbieter in dnsmasq klingt gut, aber ich frage mich, ob es unhöflich ist, bei jeder Anfrage mehrere DNS-Anbieter gleichzeitig zu belasten. Ich weiß auch nicht, wo man eine stabile, datenschutzorientierte DNS-Liste finden könnte
    • Mehrere DNS-Anbieter haben unterschiedliche Richtlinien und Prioritäten, daher betrachte ich zwei davon nicht als austauschbar. Ich würde eher nur einen auswählen und den DNS des ISP als Backup verwenden
    • Mit systemd-resolved kann man standardmäßig DoT und DNSSEC nutzen und damit ein ähnliches Verhalten erreichen. Wenn man zentralisiertes DNS vollständig vermeiden will, kann man einen Tor-Daemon betreiben und einen DNS-Resolver im Netzwerk bereitstellen. Mehrere Resolver sind ebenfalls möglich
    • Auch ohne die Einstellung all-servers sendet dnsmasq regelmäßig Anfragen als Race an die einzelnen Server (standardmäßig alle 20 Sekunden erneut). Selbst bei einer plötzlichen Störung dürfte man daher nicht länger als ein paar Sekunden betroffen sein

  • Selbst ein Ausfall von rund 1 Stunde entspricht auf Monatsbasis 0,13 % und auf Jahresbasis 0,0114 %. Ich frage mich, welches SLO Cloudflare für diesen Dienst ansetzt. Ich habe zwar diesen Link gefunden, aber der gilt nur für kostenpflichtige Dienste. Durch diesen Ausfall fällt die Verfügbarkeit im Juli in den Bereich "< 99.9% but >= 99.0%", und in diesem Fall bekäme man 10 % der Nutzungsgebühr erstattet

    • Um den Ruf der Marke zu wahren, vermute ich 99,9 % pro Jahr oder mehr

  • Interessant ist, dass der Traffic selbst nach dem Vorfall nicht vollständig auf den Normalwert zurückkehrte. Ich verwende seit Kurzem auf OpenWrt luci-app-https-dns-proxy, um gleichzeitig Anfragen an Cloudflare und Google DNS zu senden, und habe die Störung deshalb nicht bemerkt, weil DoH fast nicht betroffen war (wenn DoH ebenfalls ausgefallen wäre, wäre automatisch zu Google gewechselt worden)

    • Warum sich der Traffic nicht sofort nach dem Vorfall vollständig erholte, wird weiter hinten im Artikel genauer behandelt. Offenbar benötigten einige Server direkte Eingriffe
    • Wenn es zu einer Störung kommt, funktioniert das Internet oft gar nicht mehr, und viele machen dann erst einmal etwas anderes. Ich vermute, dass in dieser Zeit nur sehr wenige Leute tatsächlich ihren DNS-Anbieter wechseln
    • Da Clients DNS-Auflösungsergebnisse vorübergehend cachen, werden nach einer Störung eine Weile lang teilweise noch alte Werte verwendet

  • Ich finde es erstaunlich, dass sowohl 1.1.1.1 als auch 1.0.0.1 von derselben Änderung betroffen waren. Für DNS-Backups sollte man jetzt wohl einen komplett anderen Anbieter verwenden, etwa 8.8.8.8 oder 9.9.9.9

    • Beide Adressen werden in Wirklichkeit vom selben Dienst bereitgestellt. Sie wurden nie als voneinander unabhängige Backups beworben
    • DNS wurde ursprünglich dafür entworfen, den nächstgelegenen Resolver zu verwenden. Es ist gut, mehrere Anbieter, Backbones und Regionen sinnvoll zu streuen (und wenn möglich nicht nur Anycast-Adressen zu verwenden). Allerdings kann man in so einem Fall wegen der Eigenschaften von DNS auch auf unerwartete Probleme stoßen
    • So war die Situation im Grunde schon immer
    • Ich habe bereits OpenDNS, Quad9 und Cloudflare gemischt und auf zwei Pi-hole-Instanzen konfiguriert. Die meisten meiner Geräte verwenden diese beiden Pi-hole jeweils als DNS
    • Genau genommen ist schon das Konzept eines "DNS-Backups" wenig sinnvoll. Die meisten Clients wählen einfach zufällig eine der Adressen und verwenden sie; wenn eine Seite ausfällt, wird nicht automatisch sauber auf die andere umgeschaltet. Das Verhalten entspricht also oft nicht den Erwartungen

  • Cloudflares interne Topologie entwickelt sich dahin, dass sich "legacy"- und "strategic"-Systeme gegenseitig synchronisieren. Das ist ein Beitrag, der den aktuellen Stand sowohl für Techniker als auch für Nichtfachleute klar erklärt. Der Migrationsprozess wird dabei sogar interessant dargestellt. Beeindruckend fand ich die Entschuldigung für die durch den Vorfall entstandenen Unannehmlichkeiten und die Botschaft, künftig stärker an Verbesserungen und an der Vermeidung von Wiederholungen zu arbeiten. Eine solche Haltung eines Unternehmens schätze ich sehr

    • "legacy" ist ein Begriff, den vor allem Techniker verwenden, während "strategic" eher aus Marketing oder von nichttechnischen Führungskräften kommt; wenn man beides mischt, kann das beide Seiten eher verwirren und nerven

  • Ich finde es erstaunlich, dass trotz mehrerer Engineers, die das Rebranding überprüft haben, niemand bemerkt hat, dass 1.1.1.0/24 zur Rerouting-Liste hinzugefügt wurde. Ich frage mich, welcher menschliche Fehler — oder ob Böswilligkeit — zu so etwas geführt haben könnte. Für DLS (Domain List Service) scheint eine hartcodierte Ausnahme sinnvoll, die verhindert, dass 1.1.1.1/32 und 1.0.0.1/32 auf einen einzelnen Standort festgelegt werden

    • Vielleicht war es einfach ein Fall von "Wenn Jerry das gemacht hat, wird es schon passen"
    • Ich neige generell eher dazu, "die Tools statt die Menschen" verantwortlich zu machen. Je nach Systemstruktur oder Art der Generierung von Konfigurationsdateien kann ein solcher Fehler leicht durchrutschen, besonders wenn der Diff automatisch erzeugt wird. Am Ende wird auch ein Code-Review von Menschen gemacht, daher ist diese Art von Scheitern ein Verfahrensproblem. Realistisch braucht man, um wirklich große Ausfälle zu verhindern, eine Verteidigungsstrategie mit mehreren Stufen und mehrfachen Schutzmechanismen