Incident de panne de Cloudflare 1.1.1.1 du 14 juillet 2025

• Cloudflare a subi, le 14 juillet 2025, une panne totale de 62 minutes sur son resolver DNS public 1.1.1.1 lors d’un changement de topologie de service
• La majorité des utilisateurs mondiaux ont été directement touchés et ont constaté une impossibilité d’utiliser Internet
• La cause de l’incident était une mauvaise configuration d’un système legacy interne, sans lien avec une attaque externe ou un détournement BGP
• La panne a été déclenchée par la combinaison d’un cumul de modifications de configuration erronées et d’une réinitialisation à l’échelle du réseau
• Parmi les mesures de prévention de récidive, Cloudflare prépare l’introduction d’un système de déploiement progressif et l’abandon du système de configuration legacy

---

Vue d’ensemble

Le 14 juillet 2025, Cloudflare a provoqué une panne réseau mondiale du resolver DNS public 1.1.1.1 lors d’un changement de topologie de service. À cause de cet incident, les utilisateurs de 1.1.1.1 et du service Gateway DNS ont subi pendant 62 minutes une indisponibilité d’Internet ou une forte dégradation du service. L’incident était dû à une erreur de configuration d’un système legacy interne, et non à une attaque externe ni à un détournement BGP.

Étendue et impact de la panne

• Entre 21:52 UTC et 22:54 UTC, le resolver 1.1.1.1 a été pratiquement indisponible dans le monde entier
• La majorité des clients mondiaux n’ont pas pu résoudre les noms de domaine, rendant l’usage même d’Internet impossible
• La situation de panne peut être vérifiée via Cloudflare Radar
• La cause de la panne provenait d’un paramétrage erroné dans le système legacy qui gère l’infrastructure annonçant sur Internet les adresses IP détenues par Cloudflare
• L’ensemble du trafic atteignant Cloudflare via le canal 1.1.1.1 a subi un impact critique

Cause et contexte de l’incident

• Cloudflare utilise le routage Anycast pour ses services mondiaux comme le resolver DNS
• Les services sont fournis depuis différentes régions, mais certains services soumis à des exigences de localisation des données sont limités à des zones spécifiques
• Le 6 juin, lors d’un changement de configuration préparatoire à un futur service DLS (data localization), la plage IP du resolver 1.1.1.1 a été incluse par erreur dans le nouveau DLS
  • Cette erreur n’a pas eu d’effet immédiat et n’a donc déclenché aucune alerte
• Le 14 juillet, une modification ajoutant un site hors ligne à la topologie DLS à des fins de test a été appliquée
  • Cette modification a forcé un rafraîchissement de la configuration réseau globale, révélant l’erreur existante
  • Les préfixes 1.1.1.1 ont été retirés des datacenters du monde entier, interrompant le service

Chronologie de l’incident (résumé)

• 2025-06-06 17:38 : inclusion des préfixes 1.1.1.1 dans une modification de configuration pour le service DLS (sans impact immédiat, erreur latente)
• 2025-07-14 21:48 : un changement de configuration déclenche un rafraîchissement global de la configuration réseau, début du retrait mondial des préfixes 1.1.1.1
• 2025-07-14 21:52 : chute brutale du trafic DNS mondial
• 2025-07-14 22:01 : alerte interne et déclaration de l’incident
• 2025-07-14 22:20 : rollback vers la configuration précédente et début de la procédure de rétablissement du service
• 2025-07-14 22:54 : retour du trafic à la normale, levée de l’alerte et fin de l’incident

IP et protocoles affectés

• Périmètre impacté : larges préfixes IPv4 et IPv6, dont 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48
• Forte baisse du trafic observée sur les requêtes utilisant UDP, TCP et DoT (DNS over TLS)
• DoH (DNS over HTTPS) a été peu affecté, car il repose souvent sur le domaine cloudflare-dns.com

Explication technique de la panne

Panne du service resolver 1.1.1.1

• Une erreur dans les préfixes a été introduite le 6 juin lors d’un changement de préconfiguration pour DLS
• Le 14 juillet, l’ajout d’un site hors ligne à des fins de test a provoqué une mise à jour des paramètres à l’échelle du réseau
• Dans ce processus, les préfixes du resolver 1.1.1.1 ont été limités mondialement à un unique site hors ligne, entraînant le retrait du service

Analyse de la cause technique

• Cloudflare exploite actuellement en parallèle un système legacy et un nouveau système stratégique, en synchronisant les annonces de routage par espace d’adressage

• Le système legacy repose sur des mises à jour manuelles et l’absence de progressivité dans les déploiements, ce qui augmente le risque d’erreur

  • Il y avait bien une peer review et une relecture par d’autres ingénieurs, mais aucune structure ne garantissait une mise en production progressive comme un déploiement canari

• La nouvelle approche est centrée sur la topologie plutôt que sur le hardcoding, avec prise en charge des changements progressifs et mise en place d’un système de monitoring

• À 22:01, une alerte sur le DNS resolver est déclenchée

• Il est confirmé que toutes les routes du resolver ont disparu de la table de routage BGP interne

• Après le retrait des préfixes, le sous-réseau 1.1.1.0/24 a fait l’objet d’une tentative d’annonce BGP par Tata Communications India (AS4755)

  • Cela ressemblait à un détournement temporaire de préfixe, mais n’avait pas de lien direct avec l’incident

Procédure de rétablissement et actions de suivi

• À 22:20 UTC, rollback vers la configuration précédente et réannonce des préfixes
  • Environ 77 % du trafic a été rétabli immédiatement
  • Certains serveurs edge se sont réinitialisés automatiquement, nécessitant une nouvelle application via le système manuel de gestion des changements
  • Le réseau applique normalement un rollout progressif pour des raisons de sécurité, mais dans cet incident l’application a été accélérée après validation
• À 22:54, tous les sites étaient revenus à un état normal

Axes d’amélioration à venir

• Mise en place d’un système de déploiement progressif (Stage Deployment) : abandon du mode de déploiement legacy, avec introduction d’un mécanisme de rollback automatique basé sur l’état de santé
• Accélération de l’abandon du système legacy : suppression des configurations manuelles risquées et des méthodes de déploiement associées, renforcement de la documentation et de la couverture de test

Conclusion

La panne du resolver DNS 1.1.1.1 de Cloudflare a été causée par une erreur de configuration interne. Cloudflare indique mobiliser tous ses efforts pour améliorer la fiabilité et prévenir la récurrence de ce type d’incident. L’entreprise présente ses excuses aux clients pour les désagréments causés et prévoit de continuer à renforcer les mesures destinées à limiter au maximum des situations similaires à l’avenir.

[GN⁺]

Commentaires sur Hacker News

• Pour beaucoup d’utilisateurs, lorsque le résolveur 1.1.1.1 (DNS) ne fonctionne pas, cela signifie qu’ils ne peuvent accéder à presque aucun service Internet. Mais en général, on ne configure pas deux serveurs DNS sur tous les appareils ? Je me demande si le second était lui aussi en panne, ou sinon pourquoi le basculement ne s’est pas fait

  • Cloudflare recommande de configurer à la fois 1.1.1.1 et 1.0.0.1 comme serveurs DNS. Mais à cause de l’erreur de configuration à l’origine de cette panne, les annonces BGP de Cloudflare pour les préfixes 1.1.1.0/24 et 1.0.0.0/24 ont toutes deux été interrompues
  • Sur Android, dans Paramètres > Réseau et Internet > DNS privé, on ne peut saisir qu’un seul « nom d’hôte du fournisseur DNS privé » (à ma connaissance). Et je ne comprends pas pourquoi on n’accepte pas l’IP (1.1.1.1) et qu’on exige une adresse (one.one.one.one). Il serait bien plus logique de configurer un serveur DNS via son IP
  • En lister deux vaut mieux que n’en avoir aucun, mais ce n’est pas parfait. Quand l’un tombe, comme on ne suit pas lequel fonctionne correctement, on se retrouve en général avec de longues latences et des problèmes intermittents. C’est pareil sauf si on utilise une configuration plus avancée, comme un proxy DNS local avec cache et plusieurs upstreams
  • Si vous pensez pouvoir parler de DNS, je vous conseille d’exploiter votre propre service. Le domaine racine . fonctionne bien depuis des décennies, et la principale raison pour laquelle ça casse sur 1.1.1.1, ce n’est pas le DNS lui-même mais l’anycast. Cloudflare (et Google, etc.) s’entêtent avec des adresses IP « vanity » — pour rendre possible l’usage de telles IP, il faut de l’anycast, et le vrai problème n’est pas le DNS mais l’anycast. Je recommande de choisir et configurer plus d’un fournisseur
  • La configuration recommandée par Cloudflare consiste à garder 1.0.0.1 comme DNS secondaire de secours, mais lors de cet incident ce serveur a également été affecté

• Il est intéressant de voir qu’au cours d’une panne d’environ 20 minutes, le trafic de 1.1.1.1 n’a baissé que d’environ 20 %. Il est étonnant que Cloudflare continue à se faire piéger par un problème aussi simple et ancien (ce n’est pas la première fois, et probablement pas la dernière). Les 8.8.8.8 et 8.8.4.4 de Google n’ont pratiquement connu, à l’échelle mondiale, aucune seconde d’indisponibilité depuis presque 10 ans. (1 : il y a bien eu quelques problèmes régionaux, mais c’était la faute d’Internet, et même lorsque divers services Google subissaient de graves pannes, le DNS lui-même continuait de fonctionner normalement.)

  • Ce n’est pas seulement la disponibilité qui compte : pour le DNS, la vitesse et la confidentialité sont aussi importantes. Pour les utilisateurs européens, on peut utiliser la liste d’alternatives DNS européennes plutôt qu’une entreprise américaine (soumise au CLOUD Act)
  • À l’idée qu’on devrait pouvoir résoudre facilement ce genre de problème d’ingénierie dans un environnement réseau d’une telle ampleur et complexité que celui de Cloudflare, il est rappelé qu’en pratique il s’agit de problèmes que seuls 0,001 % du secteur rencontrent
  • La culture de réponse aux incidents chez Cloudflare est raisonnable, mais il lui manque des incitations fortes à promouvoir activement les mesures préventives en amont
  • Ce chiffre de 20 % signifie que certains clients/résolveurs, après plusieurs échecs de réponse, mettent temporairement le serveur DNS hors service, ce qui évite aux utilisateurs d’attendre 500 timeouts à chaque requête. À plus long terme, le volume revient à la normale sur le graphique de trafic
  • Je suis d’accord pour dire que beaucoup de gens ne veulent pas utiliser Google DNS

• Il est surprenant qu’il ait fallu plus de 5 minutes pour détecter l’impact (alors même que le trafic du protocole principal tombait à 10 % et s’y maintenait). Je n’ai jamais exploité de système de cette taille, mais je m’attendais à ce qu’une alerte soit immédiate. Je me demande si les experts trouvent cela raisonnable

  • Il existe une tension permanente entre rapidité de détection et taux de faux positifs. Les systèmes de supervision comme Nagios ou Icinga exigent en général 3 échecs consécutifs avant de déclencher un événement, car les erreurs temporaires sont fréquentes. Si les alertes sont trop nombreuses, les équipes finissent par s’y habituer et à réagir par « attendons un peu ». Je n’ai pas moi-même exploité un service mondial comme Cloudflare, mais une détection fiable en 8 minutes ne me surprend pas
  • À l’époque des anciens NOC (centres d’exploitation réseau), si un tel graphique avait été affiché sur un mur, quelqu’un y aurait jeté un œil, aurait dit « c’est bizarre » et se serait immédiatement précipité dessus
  • Je pense qu’au moment où l’impact a commencé, le service n’était probablement pas complètement hors service (surtout au début d’un déploiement mondial), et qu’il a fallu du temps avant que l’effet devienne mesurable
  • Faire sonner une alarme en moins d’une minute reviendrait surtout à tester les performances de l’infrastructure d’alerting. La vraie question est de savoir si la collecte et le calcul des données peuvent réellement être effectués de façon stable chaque minute
  • Quand le service d’agrégation des métriques plante, les indicateurs peuvent être retardés jusqu’au redéploiement du système, donnant l’impression d’une chute de 100 %. Si on envoie une alerte au bout d’une minute, on réveille inutilement beaucoup de gens à 2 h du matin, et si cela se répète, les alertes deviennent fatalement de plus en plus tolérantes — d’où cette tendance à se caler autour de 5 minutes

• Bon résumé. Il est intéressant de noter que DoH (DNS over HTTPS) passait majoritairement par le domaine cloudflare-dns.com (configuration manuelle ou navigateur), et qu’étant donné qu’il ne s’agit pas d’une adresse IP, il a été relativement moins touché par la panne. J’ai été affecté hier : même avec DoH activé sur le routeur, plus rien ne se résolvait, et le passage à 8.8.8.8 a réglé le problème

  • Je me demande comment DoH fonctionne. Il faut bien connaître l’IP de cloudflare-dns.com, et le routeur utilisait peut-être 1.1.1.1
  • Aujourd’hui, en configurant un nouveau domaine, seul Firefox sur un ordinateur portable y a eu accès pendant environ 20 minutes. L’outil Google DNS indiquait que le domaine était actif, SSH fonctionnait aussi depuis un serveur AWS, mais sur mon réseau local les requêtes DNS échouaient. J’ai vidé les caches et tout essayé, mais seul ce navigateur Firefox était configuré séparément pour utiliser le DoH de Cloudflare
  • Je ne suis pas d’accord. La vraie cause profonde est masquée par une terminologie pédante et floue, au point de semer la confusion même chez des administrateurs expérimentés. Le terme « legacy » n’est pas clair ; il paraît au contraire abstrait et opaque. Quand on lit « Les composants legacy n’utilisent pas de déploiement progressif, et Cloudflare va introduire une approche moderne permettant les déploiements progressifs et les rollbacks », on comprend l’idée, mais il n’y a pas besoin de l’écrire de façon aussi difficile à saisir
  • Mon routeur Unifi semble utiliser le DoH automatique, à la fois avec Cloudflare et Google. Je n’ai rien ressenti, donc soit le DoH de Cloudflare a continué à fonctionner, soit il a basculé immédiatement sur Google
  • Dans l’ensemble, c’est un bon résumé, mais la chronologie au début de l’article n’est en réalité pas exacte

• Avec dnsmasq, on peut configurer plusieurs serveurs DNS en parallèle et utiliser celui qui répond le plus vite. Même si un service tombe, on ne remarque presque rien

  • Sans le réglage strict-order, quand on utilise all-servers, dnsmasq renvoie automatiquement les requêtes à tous les serveurs. Mais si l’on utilise systemd-resolved, les nouvelles tentatives ne se font que dans l’ordre, donc il est important d’alterner des serveurs de fournisseurs différents. Comme dans l’exemple, si on combine aussi IPv4 et IPv6, le failover est plus rapide. Les IP concernées de Quad9 ont le filtrage par défaut activé, contrairement aux deux autres, donc les résultats de résolution peuvent différer. Personnellement, si l’on attache de l’importance à la validation DNSSEC (extensions de sécurité du DNS), il ne faut pas mélanger des résolveurs qui valident et d’autres qui ne valident pas (dans l’exemple, tous les DNS prennent en charge DNSSEC)
  • Je n’aime pas que tout mon historique DNS soit exposé aux géants de la tech (Cloudflare, Google, etc.), et je ne veux pas non plus de DoH. Je me demande s’il existe une configuration plus respectueuse de la vie privée. Utiliser dans dnsmasq une liste de petits DNS de confiance semblerait bien, mais je me demande si envoyer chaque requête à plusieurs fournisseurs DNS n’est pas mal vu. Je ne sais pas non plus où trouver une liste stable de DNS orientés confidentialité
  • Les différents fournisseurs DNS ont des politiques et des priorités différentes, donc je ne considère pas deux fournisseurs comme interchangeables. Je préférerais en choisir un seul et garder le DNS du FAI en secours
  • Avec systemd-resolved, on peut avoir par défaut DoT et DNSSEC, donc obtenir un comportement similaire. Pour éviter complètement le DNS centralisé, on peut faire tourner un daemon Tor et exposer un résolveur DNS sur le réseau. Plusieurs résolveurs sont aussi possibles
  • Même sans le réglage all-servers, dnsmasq met périodiquement les serveurs en concurrence sur les requêtes (nouvelle tentative toutes les 20 secondes par défaut). Même en cas de panne soudaine, l’impact ne durerait probablement pas plus de quelques secondes

• Même une panne d’environ 1 heure ne représente que 0,13 % sur un mois et 0,0114 % sur un an. Je me demande quel SLO (objectif de niveau de service) Cloudflare applique à ce service. J’ai bien trouvé ce lien, mais il ne concerne que les services payants. Avec cette panne, la disponibilité de juillet tombe dans la tranche « < 99.9% but >= 99.0% », ce qui donnerait droit à un remboursement de 10 % des frais d’utilisation

  • Je pense que, pour préserver la réputation de la marque, ils visent 99,9 % par an ou plus

• Il est intéressant que le trafic ne soit pas revenu complètement à la normale même après l’incident. J’utilise récemment luci-app-https-dns-proxy sur OpenWrt pour envoyer les requêtes à la fois vers Cloudflare et Google DNS, et comme DoH a été très peu affecté, je n’ai pas ressenti la panne (si DoH avait aussi cassé, ça aurait automatiquement basculé sur Google)

  • La seconde partie du texte explique davantage pourquoi le trafic ne s’est pas rétabli instantanément juste après l’incident. Il semble que certains serveurs aient nécessité une intervention manuelle
  • Quand une panne survient, il est fréquent qu’on fasse simplement autre chose pendant un moment parce qu’Internet ne marche plus. J’imagine que très peu de gens changent réellement de fournisseur DNS pendant ce laps de temps
  • Les clients mettent temporairement en cache les résultats DNS, donc pendant un certain temps après la panne, certains continuent aussi à utiliser les anciennes valeurs

• Il est surprenant que 1.1.1.1 et 1.0.0.1 aient tous deux été affectés par le même changement. Il faudrait désormais utiliser un fournisseur totalement différent comme secours DNS (par ex. 8.8.8.8, 9.9.9.9)

  • Les deux adresses sont en réalité fournies par le même service. Elles n’ont jamais été présentées comme des secours indépendants l’un de l’autre
  • Le DNS a été conçu au départ pour utiliser le résolveur le plus proche. Il vaut mieux répartir correctement entre plusieurs fournisseurs, dorsales et régions (et si possible éviter les adresses anycast). Mais dans ce cas, on peut aussi rencontrer des problèmes inattendus dus au fonctionnement même du DNS
  • De toute façon, cela a toujours été comme ça
  • J’utilise déjà un mélange d’OpenDNS, Quad9 et Cloudflare configuré sur deux Pi-hole. La plupart de mes appareils utilisent chacun ces deux Pi-hole comme DNS
  • En réalité, la notion même de « secours DNS » n’a pas beaucoup de sens. La plupart des clients choisissent simplement une adresse de manière arbitraire et l’utilisent, sans forcément basculer automatiquement vers l’autre si l’une tombe. On ne peut pas compter sur ce mécanisme comme on l’imagine

• La topologie interne de Cloudflare évolue de façon à synchroniser des systèmes « legacy » et « strategic ». C’est un texte qui explique clairement l’état des lieux de façon compréhensible à la fois pour les techniciens et les non-spécialistes. J’ai trouvé qu’il rendait même le processus de migration intéressant. Les excuses pour la gêne causée par l’incident, ainsi que le message insistant sur les améliorations à venir et la prévention des récidives, font bonne impression. J’apprécie beaucoup cette attitude de l’entreprise

  • « legacy » est un terme surtout employé par les techniciens, tandis que « strategic » relève plutôt du marketing ou des dirigeants non techniques ; mélanger les deux peut au contraire dérouter et agacer les deux camps

• Il est surprenant que, alors que plusieurs ingénieurs avaient examiné le rebranding, personne n’ait vu l’erreur consistant à ajouter 1.1.1.0/24 à la liste de reroutage. Je me demande quelle erreur humaine — ou quelle intention malveillante — a pu provoquer cela. Il faudrait probablement un traitement d’exception codé en dur dans le DLS (Domain List Service) pour empêcher de désigner 1.1.1.1/32 et 1.0.0.1/32 vers un seul emplacement

  • La cause est peut-être simplement la confiance du type « si Jerry l’a fait, c’est que ça doit être bon »
  • En général, j’ai tendance à blâmer les outils plutôt que les personnes. Selon la structure du système ou la manière dont les fichiers de configuration sont générés, ce type d’erreur peut facilement passer inaperçu (surtout si le diff est généré automatiquement). Au bout du compte, même la revue de code est faite par des humains, donc ce type d’échec relève d’un problème de procédure. En pratique, pour empêcher la mise hors ligne d’un très gros service, il faut une stratégie défensive avec plusieurs garde-fous à plusieurs niveaux