# Panne de résolution DNS chez un registrar : nos sites disparus deux heures > Aucun serveur n'était tombé, pourtant des dizaines de domaines sont devenus injoignables. Récit d'un incident DNS chez un registrar tiers et des leçons qui en restent. - Auteur : Clément Hadrot - Publié le : 2022-05-30 - Mis à jour le : 2022-05-30 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/panne-resolution-dns-registrar-incident/ ## L’essentiel - Les serveurs fonctionnaient, seule la résolution DNS avait disparu - Un registrar unique concentre un risque invisible au quotidien - La diversification des serveurs de noms limite ce risque 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. > L'essentiel à retenir : Les serveurs fonctionnaient, seule la résolution DNS avait disparu ; Un registrar unique concentre un risque invisible au quotidien ; La diversification des serveurs de noms limite ce risque ## 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.