Quand un domaine « ne résout plus », le navigateur affiche souvent qu’il ne trouve pas le serveur. Cette phrase couvre trois échecs DNS différents, plus des pannes qui ne sont pas du DNS. On commence par le code de la requête, pas par un changement d’enregistrement au hasard.
Lire le code, pas le message du navigateur
Interrogez un résolveur public, puis le serveur de noms de la zone. Les commandes de base sont dans tester le DNS d’un domaine.
| Réponse | Sens | Piste |
|---|---|---|
| Une IP | Le DNS fonctionne. | Cherchez HTTP, certificat, pare-feu. Le nom n’est pas « en panne DNS ». |
| NXDOMAIN | Le nom n’existe pas pour ce résolveur. | Domaine expiré, NS retirés, ou sous-domaine jamais créé. exemple.fr peut exister alors que www renvoie NXDOMAIN. |
| SERVFAIL | Pas de réponse validée. | NS injoignables, zone refusée, ou DNSSEC cassé. Voir DNSSEC. |
| Délai (timeout) | Aucun serveur n’a répondu à temps. | NS faux, pare-feu devant le DNS, ou délégation vers des noms eux-mêmes cassés. |
nslookup exemple.fr 1.1.1.1 puis nslookup -type=NS exemple.fr 1.1.1.1. Si les NS renvoyés ne sont pas ceux du prestataire actuel, vous éditez la mauvaise zone, ou le registrar pointe encore vers l’ancien couple de serveurs.
Les causes qui reviennent
Domaine expiré ou en rédemption. Le registrar a cessé de publier la délégation. Le site web et le DNS disparaissent ensemble, même si le serveur d’hébergement tourne encore. La date à regarder est celle du nom de domaine, pas celle du certificat. Renouveler l’hébergement ne republie pas les NS.
Délégation incohérente. Le registrar liste ns1.ancien.example alors que la zone vivante est chez un autre prestataire. Les résolveurs suivent le registrar. Corrigez les NS au registrar, puis attendez le TTL de cette délégation. Ce n’est pas le même délai qu’un changement d’enregistrement A : vérifier la propagation.
DNSSEC resté à moitié. Un DS est publié au registrar, mais la nouvelle zone n’est pas signée avec la clé correspondante. Les résolveurs validants renvoient SERVFAIL, d’autres répondent encore. Comparez 1.1.1.1 et une requête directe au NS. Si seul le résolveur public échoue, ne « réparez » pas l’enregistrement A : réparez la chaîne DNSSEC.
Serveurs de noms injoignables. Les noms NS existent dans la délégation mais n’ont pas d’adresse (glue manquant) ou ne répondent pas sur le port 53. Le timeout est alors le symptôme, y compris pour la messagerie, puisque le MX est dans la même zone.
Mauvais nom. La panne ne touche que www, ou seulement l’apex. Testez les deux, plus le nom utilisé dans les certificats et les liens canoniques.
Ce qu’il ne faut pas faire en premier
Ne transférez pas le domaine, ne changez pas les NS et n’activez pas DNSSEC pendant le diagnostic. Chaque geste ajoute un TTL. Notez d’abord : réponse d’autorité, réponse de 1.1.1.1, liste des NS au registrar, date d’expiration du domaine, présence d’un DS.
Une fois une IP obtenue des deux côtés, le DNS n’est plus le sujet. Contrôlez la page. Un test d’URL montre le code HTTP et le certificat de l’hôte que le nom désigne. Un certificat refusé avec une IP correcte est un problème TLS : le navigateur peut afficher un échec de connexion que l’on prend à tort pour un DNS mort.
Prévenez avec le fait établi (« le nom ne se résout plus : NXDOMAIN depuis 9 h 10 »), pas avec une cause devinée. Tant que la ligne d’autorité et la ligne du résolveur public ne sont pas notées, n’annoncez ni « le registrar a coupé » ni « l’hébergeur est tombé ».
Vérifiez aussi le courrier si la zone entière est en cause. Un MX dans la même zone tombe en même temps que le site. À l’inverse, un site qui s’ouvre et un mail qui échoue pointe vers le MX ou vers le serveur de messagerie, pas vers l’enregistrement A du site.