Un mardi après-midi ordinaire, les premières alertes sont tombées presque simultanément : une douzaine de sites clients injoignables, puis une vingtaine, tous gérés par un même registrar pour la gestion de leurs noms de domaine. Le réflexe habituel — vérifier les serveurs — n’a rien donné : CPU normal, MySQL disponible, nginx répondait parfaitement en local. Le problème ne venait pas de chez nous.
Il venait des serveurs de noms (nameservers) du registrar lui-même, victimes d’une panne de résolution DNS qui rendait injoignables tous les domaines dont la zone dépendait d’eux, quel que soit l’hébergeur du site derrière. Un domaine peut avoir le meilleur serveur web du monde : si personne ne peut résoudre son nom en adresse IP, il est invisible.
Le déroulé de l’incident, minute par minute
15h40 : premiers signalements clients par email, tous formulés de la même façon — « le site ne charge plus, page blanche du navigateur ». 15h52 : vérification de nos serveurs, tout est vert. 16h05 : un test dig exemple.fr depuis un poste externe au réseau de l’agence renvoie un timeout au lieu d’une réponse. 16h10 : confirmation que tous les domaines touchés partagent le même registrar et les mêmes serveurs de noms par défaut.
16h20 : recherche du statut officiel du registrar, qui ne publiait alors aucune information publique sur une page de statut — un choix qui a considérablement allongé notre délai de diagnostic, faute de confirmation externe rapide. 17h15 : premiers signes de rétablissement progressif, la résolution redevenant fonctionnable pour certains domaines avant d’autres, signe d’une propagation en cours plutôt que d’un retour instantané. 17h45 : dernier domaine du lot de nouveau résolu normalement.
Pourquoi ce type de panne est particulièrement pernicieux
Une panne serveur se voit immédiatement dans les outils de supervision classiques : charge, disponibilité HTTP, tout clignote au rouge. Une panne de résolution DNS chez un tiers, elle, ne déclenche souvent aucune alerte côté hébergement, puisque le serveur répond parfaitement à qui parvient à le joindre. Sans un test de résolution DNS externe et régulier, l’incident reste invisible depuis l’intérieur de l’infrastructure surveillée.
Autre particularité : la résolution DNS dépend du cache de chaque résolveur DNS le long du chemin. Certains visiteurs, dont le fournisseur d’accès avait mis le résultat en cache avant la panne, continuaient à charger les sites normalement pendant que d’autres, interrogeant un résolveur au cache expiré, tombaient sur une erreur. Ce comportement inégal a compliqué le diagnostic : plusieurs clients juraient que « ça marchait chez eux ».
Depuis cet incident, notre check de disponibilité inclut systématiquement une résolution DNS depuis un réseau extérieur au nôtre, en plus du traditionnel ping HTTP sur le serveur.
Ce que nous avons changé depuis
La première leçon a été de cesser de dépendre exclusivement des serveurs de noms fournis par défaut par un registrar unique. Pour les domaines les plus critiques, nous recommandons désormais deux jeux de serveurs de noms secondaires chez un prestataire DNS distinct du registrar, une pratique standard appelée « secondary DNS », qui isole totalement la résolution d’une panne côté registrar.
- Ajout d’une sonde de résolution DNS externe dans notre outil de supervision, avec seuil d’alerte à la moindre erreur
- Documentation d’un contact de secours chez chaque registrar utilisé, pour éviter de chercher un formulaire de support en pleine panne
- Sensibilisation des clients : un registrar n’est pas qu’un guichet d’achat de domaine, c’est un maillon de disponibilité à part entière
Pour aller plus loin
Cet incident n’a affecté aucun serveur que nous administrons, et c’est précisément ce qui l’a rendu difficile à diagnostiquer sous pression : tout dépend d’un maillon externe qu’on oublie facilement d’auditer. Un parc de sites bien hébergé reste vulnérable tant que la chaîne DNS complète — registrar compris — n’a pas été pensée avec la même rigueur que le serveur lui-même.
