# Un souci de résolution de domaine coupe les réservations d’un restaurant

> Le site d'un restaurant reste injoignable pendant trois heures sans qu'aucun fichier ni aucune ligne de code n'ait bougé. La cause se trouve ailleurs.

- Auteur : WordPress Développement
- Publié le : 2020-02-19
- Mis à jour le : 2020-02-19
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/incident-dns-reservations-restaurant-injoignable/

## L’essentiel

- Le DNS peut casser un site sans toucher au serveur
- dig et un second résolveur suffisent à isoler la cause
- Un TTL trop long prolonge inutilement la panne

Trois heures et quart : c'est le temps pendant lequel le formulaire de réservation d'un restaurant du centre de Nantes est resté injoignable pour une partie des visiteurs, alors que rien n'avait été modifié ni sur le serveur ni dans le thème WordPress la veille. Le gérant appelle, persuadé que « le site est en panne ». Le développeur, lui, se connecte sans le moindre souci et voit une page d'accueil qui s'affiche normalement.

Ce genre de décalage — ça fonctionne chez l'un, pas chez l'autre — est presque toujours un signal qui pointe vers la résolution de nom plutôt que vers l'hébergement lui-même. Encore faut-il savoir où regarder, et dans quel ordre, pour ne pas perdre de temps à redémarrer des services qui n'ont rien à se reprocher.

## Le signalement : un numéro qui sonne dans le vide

Le premier réflexe consiste à distinguer une panne réelle d'un problème de perception. Le site répond-il en HTTP direct sur l'adresse IP du serveur ? Si oui, l'hébergement fonctionne et le problème se situe en amont, entre le navigateur du visiteur et cette adresse IP. C'est précisément ce qui s'est produit ici : une requête `curl` vers l'IP du serveur, avec un en-tête `Host` forcé, renvoyait une page tout à fait valide.

- Le site répond en accédant directement à l'IP du serveur
- Certains visiteurs voient le site, d'autres non, selon leur fournisseur d'accès
- Aucun message d'erreur cohérent dans les journaux Nginx ou PHP-FPM

## Ce que révèle une requête DNS classique

La commande `dig` permet de vérifier, résolveur par résolveur, ce que chacun renvoie pour le domaine concerné. Sur ce dossier, une requête vers le résolveur public de Google renvoyait bien l'adresse IP attendue, tandis qu'une requête vers le résolveur d'un opérateur français renvoyait une réponse vide, avec un code `SERVFAIL`.

```
dig +short reservation-exemple.fr @8.8.8.8
203.0.113.42

dig +short reservation-exemple.fr @194.2.0.20
;; communications error to 194.2.0.20#53: timed out
```

Ce contraste confirmait que le problème ne venait ni du serveur web ni du thème, mais bien d'un incident affectant un ou plusieurs serveurs faisant autorité pour la zone, ou un résolveur intermédiaire chez un opérateur.

> L'essentiel à retenir : Le DNS peut casser un site sans toucher au serveur ; dig et un second résolveur suffisent à isoler la cause ; Un TTL trop long prolonge inutilement la panne

## La cause réelle : un incident chez l'hébergeur du DNS, pas chez l'hébergeur web

Il est fréquent, en particulier pour les petites structures, que le domaine soit géré par le registrar et que la zone DNS pointe vers des serveurs de noms distincts de l'hébergement web. Dans ce dossier, la zone était hébergée chez le registrar, et celui-ci traversait un incident réseau ponctuel sur une partie de son infrastructure, sans lien avec le serveur qui faisait tourner WordPress.

Le site en lui-même n'avait donc jamais cessé de fonctionner. Ce sont les demandes de résolution qui, pour une partie du trafic, n'aboutissaient plus. Un visiteur utilisant le résolveur de son opérateur historique tombait sur un échec ; un visiteur utilisant un résolveur public s'en sortait sans le moindre problème.

> Sur ce type de dossier, la première vérification n'est jamais « le serveur est-il en panne ? » mais « le nom de domaine se résout-il, et de la même façon partout ? ». Deux commandes suffisent à trancher, avant de réveiller qui que ce soit d'astreinte.

## Que faire pendant l'incident, côté hébergement du site

Une fois la cause identifiée comme externe, la marge de manœuvre côté hébergement web est réduite mais pas nulle. Il reste possible de :

- Vérifier qu'un enregistrement secondaire de type NS existe et fonctionne, si la zone est répartie sur plusieurs fournisseurs
- Documenter l'horodatage précis de l'incident pour la communication avec le client
- Vérifier que le certificat TLS reste valide pour éviter un second problème une fois la résolution rétablie

## Réduire l'exposition à ce type de panne

Ce dossier a débouché sur deux changements concrets. D'abord, l'abaissement du TTL des enregistrements DNS critiques à 300 secondes au lieu d'une valeur par défaut souvent fixée à plusieurs heures : en cas de bascule vers un autre fournisseur DNS, la propagation devient nettement plus rapide. Ensuite, la mise en place d'une deuxième paire de serveurs de noms, chez un fournisseur distinct du registrar, pour que la zone reste interrogeable même en cas d'incident isolé.

## En résumé, ce que ce dossier enseigne

Un site qui semble « en panne » n'est pas toujours en panne : la résolution de nom constitue une couche à part entière, distincte de l'hébergement web, et un incident à ce niveau peut rendre un site injoignable pour une partie seulement des visiteurs, ce qui brouille le diagnostic si l'on ne pense pas à tester plusieurs résolveurs. Garder `dig` à portée de main, et connaître la différence entre registrar et hébergeur DNS, permet de couper court à des heures de fausses pistes.