Quand l'infrastructure a cédé : comment une panne DNS a paralysé la moitié d'Internet

Lundi 20 octobre, à 6h30, des millions de personnes à travers le monde se sont réveillées face à une panne d'Internet. Les applications bancaires étaient hors service, les sonnettes connectées se sont bloquées et même les plateformes de signalement des pannes étaient inaccessibles.

Ce qui semblait être une coupure totale de la connectivité était en réalité un problème plus subtil et alarmant : une zone spécifique d'AWS, us-east-1, a subi une défaillance de résolution DNS. Cette panne a révélé la fragilité de l'infrastructure numérique dont nous dépendons tous et a mis en lumière notre dépendance au protocole DNS, un protocole auquel la plupart des gens ne pensent même pas. Il ne s'agissait pas d'une simple panne ; c'était une leçon.

L'épine dorsale que nous ignorons : pourquoi le DNS est la première étape

Chaque interaction en ligne, de l'ouverture d'un site web à la connexion à une application ou à l'appel d'une API, commence par une question tacite : « Où puis-je accéder à ce service ? » Le système de noms de domaine (DNS) répond à cette question fondamentale. On l'appelle littéralement l'épine dorsale d'Internet. Le DNS est le mécanisme qui traduit les noms de domaine compréhensibles par l'humain (comme example.com) en adresses IP routables automatiquement (comme 192.0.2.44 ou 2606:4700:4700::1111).

Le DNS en termes simples et techniques :

En résumé, le DNS est l'annuaire d'adresses d'Internet. Il ne s'agit pas d'un annuaire physique, mais d'un réseau hiérarchique complexe et distribué à l'échelle mondiale, composé de :

Serveurs de noms racine.

Serveurs de TLD (comme .com ou .net).

Serveurs de noms faisant autorité (qui contiennent les enregistrements DNS).

Résolveurs récursifs (souvent gérés par les fournisseurs d'accès à Internet ou les services DNS publics).

Techniquement, le DNS fonctionne via les protocoles UDP et TCP sur le port 53 et utilise un modèle requête-réponse sans état.

Les résolveurs utilisent des mécanismes de cache basés sur la durée de vie (TTL) attribuée à chaque enregistrement.

Lorsqu'une panne DNS survient, l'impact est immédiat et catastrophique :

Votre application ne trouve plus sa base de données.

Le CDN ne parvient plus à distribuer les fichiers.

Les API sont incapables de se connecter aux services requis.

L'infrastructure sous-jacente peut encore fonctionner, mais sans adresse IP, elle devient totalement inaccessible ; autrement dit, les ressources d'infrastructure disparaissent d'Internet.

Un désert sans repères.

Lors de la panne majeure d'AWS, la défaillance ne provenait pas des services de calcul ou de stockage eux-mêmes, comme DynamoDB, mais plutôt d'une erreur de résolution DNS pour ces services.

Le processus normal est le suivant :

L'application a besoin de données.

Requête DNS.

Résolution de l'adresse IP.

Connexion établie.

Les données sont renvoyées au serveur.

Lors de la panne, la deuxième étape a échoué. Les applications tentant d'accéder à dynamodb.us-east-1.amazonaws.com n'ont pas reçu d'adresse IP, ce qui a entraîné un délai d'attente dépassé. La base de données fonctionnait, mais elle est devenue un désert sans repères.

Cette défaillance d'adresse a entraîné des pannes généralisées :

Interruption des sessions de connexion
Erreurs 500/503
Gel des API et des applications
Panne des listes de tâches

Le confort au détriment de la résilience et de la robustesse du système

Cet incident a révélé que la fragilité des systèmes modernes n'est pas imputable au fournisseur de cloud, mais plutôt à nos choix lors de la conception de notre infrastructure numérique. Nous avons privilégié le confort à grande échelle, au détriment de la résilience et de la fiabilité.

La plupart des organisations ont souvent, involontairement, créé un point de défaillance unique pour l'ensemble de leur système, par exemple :

Un seul fournisseur de cloud.

Une seule région (souvent us-east-1).

Un seul serveur DNS.

Cette dépendance centralisée a créé une chaîne dangereuse de dépendances. Lorsque le DNS tombe en panne, tout s'arrête. Même les systèmes de surveillance, conçus pour détecter les pannes, ont planté. Les panneaux de contrôle, les systèmes d'alerte et les outils de remédiation automatique n'ont pas pu atteindre leurs destinataires car eux aussi dépendent du DNS.

Lorsque l'infrastructure principale a cédé, toute visibilité a été perdue. La panne a non seulement perturbé les services, mais a également révélé à quel point nos systèmes de secours reposent sur une seule et fragile couche de l'infrastructure d'Internet.

Réinventer la résilience : Solutions DNS avancées

Les leçons tirées d'incidents comme celui-ci ont incité le secteur à considérer le DNS comme une infrastructure critique, et non comme un détail mineur.

Des entreprises telles que Cloudflare, Google et Quad9 ont repensé le DNS pour résoudre ses problèmes fondamentaux : centralisation, latence et fragilité.

Les innovations de Cloudflare illustrent l'approche moderne du DNS :

DNS Anycast global : Achemine les requêtes vers le nœud disponible le plus proche et, en cas de défaillance d'un centre de données, le trafic est immédiatement redirigé.

Résolveur 1.1.1.1 : Un service DNS public axé sur la vitesse et la confidentialité.

Prise en charge de DNSSEC : Fournit une authentification chiffrée des réponses.

DNS secondaire et répartition de charge : Garantissent la redondance entre différentes régions et différents fournisseurs.

Basculement basé sur l'état de santé : Redirige automatiquement le trafic vers d'autres serveurs que ceux en panne. Les fournisseurs DNS avancés ne se contentent plus de résoudre des noms de domaine ; ils garantissent désormais la continuité de service et préviennent les pannes en cascade.

Leçons à retenir : La panne d’AWS n’a pas détruit le cloud, mais a brisé l’illusion de résilience. Puisque « l’espoir ne fait pas la stratégie », les équipes de développement doivent élaborer des stratégies pour assurer la continuité de service même en cas de panne majeure, en prenant les précautions et les mesures nécessaires.

Mesures de résilience et de fiabilité à court terme : Mettre en œuvre une mise en cache côté client avec des valeurs TTL longues. Utiliser des disjoncteurs pour les services externes. Configurer des alertes de panne DNS.

Mesures de résilience et de fiabilité à long terme : Adopter une architecture multirégionale par défaut. Maintenir des fournisseurs DNS de secours. Développer des stratégies de dégradation progressive. Utiliser l’ingénierie du chaos pour tester les scénarios de panne DNS.