Panne de résolveur DNS chez un hébergeur : diagnostiquer sans accès serveur

Symptôme : un client signale que son site est « en panne » depuis le matin. L’équipe technique vérifie immédiatement les journaux d’accès du serveur, la charge processeur, l’état du pool PHP-FPM — tout est parfaitement normal, et pire encore, aucune requête entrante ne correspond même approximativement aux plages horaires signalées par le client comme problématiques.

Cet article ne revient pas sur la configuration de la zone DNS elle-même, sujet distinct déjà traité par ailleurs. Il détaille le diagnostic centré sur la résolution DNS récursive côté hébergeur, un angle souvent négligé quand un site semble injoignable sans qu’aucun signe ne remonte côté serveur.

Symptôme : aucune trace côté serveur, mais un site « en panne »

C’est le signal le plus caractéristique de ce type de panne : si le problème se situait sur le serveur lui-même (surcharge, erreur applicative, pare-feu mal configuré), les journaux d’accès porteraient une trace de requêtes échouées ou d’erreurs 5xx. Ici, rien de tel : le serveur ne reçoit tout simplement jamais certaines requêtes, ce qui oriente immédiatement le diagnostic vers une étape antérieure à l’arrivée de la requête sur l’infrastructure — la résolution du nom de domaine lui-même.

Un visiteur dont le fournisseur d’accès utilise un résolveur DNS récursif défaillant ne recevra jamais de réponse à sa requête de résolution, et son navigateur affichera une erreur générique de type « ce site est inaccessible », indiscernable en apparence d’une véritable panne serveur.

Diagnostic : confirmer l’hypothèse avec des outils distribués

Le diagnostic ne peut pas se faire depuis un unique poste de travail : une requête dig exemple.fr lancée depuis le bureau de l’agence utilisera le résolveur DNS local de l’agence, qui n’a probablement aucun rapport avec celui utilisé par les visiteurs qui rencontrent le problème. Il faut un outil capable d’interroger la résolution DNS depuis plusieurs points géographiques et plusieurs résolveurs distincts simultanément.

Des services en ligne comme DNSChecker ou l’outil dig combiné à des résolveurs publics explicitement ciblés (dig @8.8.8.8 exemple.fr, dig @1.1.1.1 exemple.fr, dig @9.9.9.9 exemple.fr) permettent de comparer les résultats obtenus depuis différents résolveurs récursifs. Sur cet incident précis, la comparaison a révélé que les résolveurs de deux fournisseurs d’accès régionaux spécifiques renvoyaient une absence de réponse (timeout) pour ce domaine précis, quand tous les autres résolveurs testés répondaient normalement et instantanément.

Correctif : rien à faire côté infrastructure du site

C’est la particularité la plus frustrante de ce type d’incident : le problème ne se situait ni sur le serveur, ni sur la zone DNS elle-même (vérifiée comme parfaitement valide et cohérente auprès du registrar), ni sur les serveurs de noms faisant autorité pour le domaine, qui répondaient normalement à toute requête directe. La défaillance se situait entièrement du côté des résolveurs récursifs de deux fournisseurs d’accès tiers, hors du périmètre de toute action possible côté agence ou côté hébergeur du site.

• Documenter précisément l’incident avec les résultats de résolution obtenus depuis chaque résolveur testé.
• Contacter le support technique des fournisseurs d’accès concernés en fournissant ces preuves précises.
• Informer le client que le problème ne relève pas de son hébergement, avec les éléments factuels pour appuyer cette explication.

Prévention : une supervision qui teste plusieurs résolveurs

Cet incident a conduit l’équipe à ajouter une sonde de supervision spécifique, distincte de la simple vérification de disponibilité HTTP habituelle : une vérification périodique de la résolution DNS du domaine depuis plusieurs résolveurs publics différents, capable de détecter une défaillance de ce type avant qu’un client ne la signale lui-même.

for resolveur in 8.8.8.8 1.1.1.1 9.9.9.9; do
  reponse=$(dig +short @"$resolveur" exemple.fr)
  if [ -z "$reponse" ]; then
    echo "Echec de resolution via $resolveur"
  fi
done

Un site parfaitement sain peut malgré tout sembler injoignable pour une partie du monde. Le diagnostic ne s’arrête jamais au serveur : il doit toujours remonter jusqu’au chemin de résolution emprunté par le visiteur.

En résumé

Face à un site signalé « en panne » sans aucune trace dans les journaux serveur, la résolution DNS récursive côté visiteur mérite d’être vérifiée systématiquement avant d’écarter toute autre hypothèse. Ce type de panne, invisible depuis l’infrastructure gérée par l’agence, ne se confirme qu’avec des outils de résolution distribués interrogeant plusieurs résolveurs depuis plusieurs points du réseau.