It's always DNS ! (quand même les géants trébuchent)

🌐 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 (É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.

Vous souhaitez essayer happyDomain ?

Vous pouvez, au choix l'essayer :

1. En ligne : créez votre compte utilisateur sur https://happydomain.org/.
2. Sur votre serveur : téléchargez les fichiers binaires ici : https://get.happydomain.org/master/. Vous en trouverez pour Linux, aussi bien pour les machines et serveurs classiques (amd64), que pour les Raspberry Pi récentes telles armv7 ou arm64 et plus anciennes comme armhf.
3. Vous pouvez aussi lancer notre image Docker :

   docker container run -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain

   L’option NO_AUTH contourne la création de compte utilisateur, ce qui est idéal pour tester. Bien sûr, bannissez-là dans la vie courante.
   Rendez-vous ensuite sur http://localhost:8081/ pour commencer à gérer vos domaines !

Vous pouvez nous aider à aller plus loin !

happyDomain progresse et nous avons besoin de vos talents pour le rendre encore plus simple et plus utile.

Utilisateurs, administrateurs, néophytes, donnez votre avis pour orienter les prochaines fonctionnalités en proposant ou en votant pour les prochaines fonctionnalités.

Développeurs, traducteurs, rédacteurs, concepteurs d’écrans, testeurs, rejoignez l’équipes des joyeuxDNS ! Vous nous trouverez sur notre dépôt Git ici.