Add new article

content/its-always-dns-quand-meme-les-geants-trebuchent.fr.md

@@ -0,0 +1,138 @@
+---
+title: "It's always DNS ! (quand même les géants trébuchent)"
+date: 2025-10-21
+author: "Frédéric Grither"
+tags: ["DNS", "AWS", "CloudComputing", "Incident Analysis", "Infrastructure", "DevOps", "SysAdmin", "Panne"]
+description: "Retour sur la panne d’AWS du 20 octobre 2025 : une défaillance DNS a paralysé AWS US-EAST-1 et une partie d'internet. Analyse technique, enjeux de centralisation et leçons pour les experts du cloud."
+---
+
+## 🌐 It's always DNS ! (quand même les géants trébuchent)
+
+Le 20 octobre 2025, **Amazon Web Services (AWS)** a connu une panne majeure dans l’une de ses plus importantes ferme de serveurs, située en Virginie du Nord (`us-east-1`).
+L’incident a touché une constellation de services : **Docker Hub**, **Canva**, plusieurs plateformes de VOD, des jeux en ligne, ainsi qu’une multitude d’entreprises plus modestes.
+Même les sites du **gouvernement britannique** et du **fisc anglais** ont été affectés — ce qui amène une question légitime : pourquoi des services publics britanniques sont-ils hébergés... aux Etats-Unis ?
+
+
+### 🧩 La cause ? Toujours la même coupable : le DNS.
+
+Eh oui, la fameuse phrase **« It’s always DNS »** n’a jamais été aussi vraie.
+Amazon, fidèle à sa politique de transparence, a publié un rapport détaillé qui permet de retracer le déroulé de l’incident, les difficultés d’investigation, les étapes de la résolution et les délais de rétablissement.
+
+C’est un double tranchant :
+- d’un côté, cette transparence expose une faiblesse d’Amazon et pourrait nuire à son image ;
+- de l’autre, elle renforce la confiance, en montrant l'humilité et en permettant à toute la communauté d’en tirer des leçons concrètes.
+
+
+### 🏢 Une leçon d’échelle et de dépendance
+
+En parcourant la liste des **141 services impactés**, on mesure l’ampleur du portefeuille d'AWS et, par extension, le degré de dépendance du numérique mondial à une seule entreprise.
+Cette centralisation crée une **vulnérabilité systémique** : quand AWS éternue, Internet s’enrhume. Au lit et dodo...
+
+Elle montre aussi la **force de réaction** d’Amazon, capable de mobiliser en quelques minutes des systèmes de surveillance, des ingénieurs et des procédures de reprise à grande échelle.
+
+
+### 🕑 Une chronologie instructive
+
+L’incident débute vers **00h11 (PDT)** et il faut **près de deux heures** pour identifier la cause :
+
+> “Based on our investigation, the issue appears to be related to DNS resolution of the DynamoDB API endpoint in US-EAST-1.”
+
+Une heure et demie plus tard, AWS annonce que le problème est « pleinement atténué » :
+
+> “The underlying DNS issue has been fully mitigated, and most AWS Service operations are succeeding normally now.”
+
+Résultat : environ **3h30** pour diagnostiquer et corriger une erreur de résolution DNS sur une région critique.
+Vu la taille de l’infrastructure, c’est à la fois long et court : long pour un service planétaire, court au regard de la complexité d’un **DNS interne distribué** à cette échelle. J'ajoute : "à cette heure de la nuit" où les humains sont censés dormir, bref moins efficaces.
+
+Pour les passionnés de DNS, cela soulève plusieurs questions :
+- Quelle architecture de redondance existait sur les serveurs d’autorité internes ?
+- Quelles sondes ou indicateurs de surveillance ont détecté, ou manqué, l’anomalie ?
+- Quelle a été la stratégie de résolution (basculement, vidage de cache, réinjection d’enregistrements, propagation forcée) ?
+
+Une analyse méticuleuse *par la suite* — à la manière du secteur aéronautique — serait précieuse pour la communauté.
+
+
+### 😄 “It’s always DNS” — même chez Amazon
+
+Le rapport se conclut par une phrase qui a fait sourire les administrateurs réseau :
+
+> “If you are still experiencing an issue resolving the DynamoDB service endpoints in US-EAST-1, we recommend flushing your DNS caches.”
+
+Autrement dit : *“Redémarrez votre DNS (et ça devrait marcher).”*
+Une réponse qui illustre bien la réalité des pannes DNS : simples en apparence, redoutables dans leurs effets en cascade.
+
+
+### 🧠 Qu’en retenir ?
+
+Cette panne nous rappelle trois évidences de fond :
+
+1. **Le DNS reste un maillon critique** de toute architecture Internet et son invisibilité apparente le rend d’autant plus dangereux. D'accord, en tant qu'experts du DNS, nous avons un biais de confirmation puisque c'est notre sujet.
+
+2. **La centralisation extrême** crée une dépendance systémique : quand un acteur comme Amazon connaît un incident de cette complexité, tout un pan du numérique s’en trouve paralysé.
+
+3. **La transparence après-incident** s'avère un atout majeur : elle transforme une défaillance en opportunité d’apprentissage collectif.
+Comme pour le secteur aéronautique, faut-il un organisme d'enquête puissant et factuel ou bien les grandes entreprises sont-elles capables d'exposer **toutes** leurs faiblesses au détriment de l'ego ?
+
+
+Personnellement, j’étais en train de publier une image Docker lorsque tout a cessé de répondre.
+J’ai d’abord cru — une fois de plus — que j’avais tout cassé.
+
+Mais non. Pas cette fois. *Ouf.*
+
+
+> **Source :** [AWS Health Dashboard – Incident Report](https://health.aws.amazon.com/health/status?eventID=arn:aws:health:us-east-1::event/MULTIPLE_SERVICES/AWS_MULTIPLE_SERVICES_OPERATIONAL_ISSUE/AWS_MULTIPLE_SERVICES_OPERATIONAL_ISSUE_BA540_514A652BE1A)
+> *(Événement “Increased Error Rates and Latencies”, Région US-EAST-1, 20 octobre 2025)*
+
+
+## 🧭 Analysons davantage de technique, avec ce que nous savons à chaud.
+Comment une panne DNS interne peut faire tomber un cloud mondial ?
+
+### 1️⃣ Le rôle du DNS interne
+
+Amazon Web Services ne s’appuie pas seulement sur le DNS public.
+Chaque service (EC2, Lambda, DynamoDB, etc.) utilise un **DNS interne distribué**, permettant la résolution des noms internes, par exemple `dynamodb.us-east-1.amazonaws.com`, vers des IP internes ou virtuelles, gérées par des équilibreurs de charges.
+
+Quand ce DNS interne rencontre un problème, disons une corruption de cache, un défaut de réplication ou une erreur dans les enregistrements d’autorité, les services ne peuvent plus dialoguer entre eux, même si le réseau physique reste nominal.
+
+
+### 2️⃣ L’effet domino typique
+
+Ici, le service **DynamoDB** a été le premier touché.
+Or, de nombreux autres services AWS en dépendent :
+
+- **EC2** pour stocker et lire ses métadonnées de lancement
+- **Lambda** pour la gestion des environnements d’exécution
+- **CloudWatch**, **SQS**, **IAM**, etc., qui utilisent DynamoDB comme dorsale de métadonnées ou de configuration.
+
+Résultat : une panne DNS sur un point de terminaison interne a entraîné une **cascade d’erreurs logicielles** sur des services critiques.
+Lorsque DynamoDB ne répond plus, EC2 ne peut plus démarrer d’instances, Lambda ne peut plus invoquer de fonctions et la chaîne s’effondre.
+
+
+### 3️⃣ Pourquoi est-ce si difficile à détecter ?
+
+Le DNS interne est un composant silencieux :
+- il **ne “s'arrête” jamais totalement**,
+- mais il peut **répondre de manière incohérente**, selon les caches, les zones ou les serveurs locaux.
+
+Ce type d’erreur partielle provoque des symptômes diffus : latences, dépassements de délais, erreurs `5xx`, comportements aléatoires, etc. d’où la difficulté à isoler rapidement la cause.
+
+
+### 4️⃣ La résolution classique
+
+AWS a probablement appliqué les mesures suivantes :
+
+- Réinitialisation des caches DNS internes sur les nœuds critiques
+- Réinjection des enregistrements d’autorité corrompus
+- Propagation accélérée via des Time To Live forcés à court terme
+- Relance manuelle des services dépendants de DynamoDB
+- *Réduction* temporaire des créations d’instances EC2 pour stabiliser le système
+
+Une séquence complexe, d’autant plus difficile à piloter qu’elle se déroule en temps réel, dans un environnement distribué à l’échelle mondiale.
+
+
+### 5️⃣ La leçon d’architecture
+
+Cet incident rappelle une vérité intemporelle :
+👉 **le DNS est un service d’infrastructure, pas un service d’accompagnement.**
+
+Il doit être dupliqué, supervisé, testé en charge et vérifié comme un cœur de réseau.