Quand le DNS échoue, un site web sain devient inaccessible. Le serveur tourne, l’application va bien, mais le navigateur du visiteur ne peut pas savoir où se connecter. Le navigateur signale quelque chose comme « serveur introuvable », et c’est tout ce qu’il dit.

Ce guide vous aide à déterminer de quel type d’échec il s’agit et où il se produit. Pour une explication simple des termes, consultez résolution DNS.

Lisez d’abord le symptôme

Une réponse DNS porte un état. Quatre issues couvrent la plupart des cas.

Ce que vous voyez Signification Causes habituelles
NXDOMAIN Le nom n’existe pas Une faute de frappe, un enregistrement ou une zone supprimés, une délégation manquante, un domaine expiré
Réponse vide, état NOERROR Le nom existe, mais n’a aucun enregistrement du type demandé Pas d’enregistrement AAAA sur un site uniquement IPv4. C’est souvent normal
SERVFAIL Le serveur n’a pas pu terminer la recherche Les serveurs de noms de la zone ne répondent pas ou répondent mal, une délégation cassée, une vérification DNSSEC échouée
Délai dépassé, pas de réponse Rien n’a répondu à temps Un réseau bloqué, un résolveur surchargé ou en panne, un pare-feu

La RFC 1035 définit les codes « échec du serveur » et « erreur de nom » (le nom n’existe pas). La RFC 8499 explique les noms courants SERVFAIL et NXDOMAIN. La réponse vide est parfois appelée NODATA. Ce n’est pas un état à part, seulement une réponse réussie sans contenu.

Testez avec dig

dig est l’outil standard sous Linux et macOS. Il affiche l’état dans la ligne d’en-tête.

dig example.com A
dig example.com AAAA

Cherchez la ligne status: dans la sortie. Pour ne garder que les adresses :

dig +short example.com A

Windows dispose de nslookup :

nslookup example.com

Interrogez un autre résolveur

Par défaut, vous interrogez le résolveur que votre réseau vous a attribué. Pour en interroger un autre, nommez-le après @ :

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Si votre résolveur habituel échoue et que les autres répondent, le problème vient du résolveur ou du chemin jusqu’à lui, pas de votre domaine. Si tous les résolveurs échouent, le problème se trouve dans votre zone ou votre délégation.

Interrogez les serveurs faisant autorité

Trouvez quels serveurs sont responsables du domaine, puis interrogez-les directement :

dig example.com NS +short
dig @ns1.your-dns-provider.example example.com A

Un serveur faisant autorité connaît la zone grâce à ses propres données. S’il renvoie la bonne adresse alors que les résolveurs publics ne le font pas, la réponse est probablement en cache quelque part, ou la délégation chez le bureau d’enregistrement pointe ailleurs. Si le serveur faisant autorité ne répond pas du tout, votre fournisseur DNS a un problème.

Suivez la chaîne

dig +trace part de la racine et suit chaque délégation :

dig +trace example.com

Il montre quelle étape cesse de répondre. Un parcours qui se termine par le registre ne donnant aucun serveur de noms pour votre domaine suggère un problème de délégation, souvent un enregistrement expiré.

Circonscrivez le problème

Travaillez de l’extérieur vers l’intérieur.

  1. D’autres réseaux le voient-ils ? Essayez avec un téléphone en données mobiles et un résolveur public. Si seul votre réseau échoue, regardez du côté des résolveurs locaux, d’un VPN ou d’un filtre.
  2. Le domaine a-t-il expiré ? Un enregistrement expiré est une cause courante de NXDOMAIN soudain. Vérifiez la date comme décrit dans Comment vérifier quand un domaine expire.
  3. La délégation a-t-elle changé ? Si les serveurs de noms ont été modifiés chez le bureau d’enregistrement, comparez les enregistrements NS du registre avec les serveurs où la zone se trouve réellement.
  4. Un enregistrement a-t-il changé ? Un enregistrement A, AAAA ou CNAME supprimé ou mal saisi donne une réponse vide ou erronée.
  5. La machine locale est-elle en cause ? Vérifiez le fichier hosts, videz le cache local et testez depuis un autre appareil.

Pourquoi une correction n’apparaît pas partout en même temps

Les résolveurs mettent les réponses en cache. Les réponses positives sont conservées pendant la durée de vie (TTL) de l’enregistrement. Les réponses négatives sont aussi mises en cache : la RFC 2308 décrit la mise en cache des réponses « le nom n’existe pas » et « pas de données », en utilisant la durée indiquée par l’enregistrement SOA de la zone. Un résolveur qui a entendu NXDOMAIN juste avant que vous ne créiez l’enregistrement peut continuer à le répéter jusqu’à la fin de cette durée.

Un SERVFAIL peut aussi être mis en cache, bien que la RFC 2308 demande que cette mise en cache ne dépasse pas cinq minutes.

Après une correction, testez donc d’abord auprès des serveurs faisant autorité. Ils montrent la vérité. Les résolveurs publics se mettent à jour à mesure que leurs caches expirent.

A et AAAA : une panne partielle qui se cache bien

Un enregistrement A contient une adresse IPv4 (RFC 1035). Un enregistrement AAAA contient une adresse IPv6 (RFC 3596). Un site peut avoir les deux, ou seulement A.

L’absence d’enregistrement AAAA est normale. Un enregistrement erroné ne l’est pas : un visiteur dont la connexion préfère IPv6 peut être envoyé vers une adresse où rien ne répond, tandis que les visiteurs en IPv4 voient un site qui fonctionne. Si les signalements « le site est en panne » ne viennent que de certains utilisateurs, comparez dig example.com A avec dig example.com AAAA.

Ce que vérifie UptimeWire

Une fois par heure, pour chaque site web, UptimeWire résout le nom d’hôte du site avec le résolveur système standard et examine la réponse :

  • La vérification réussit quand le nom se résout vers au moins une adresse publique.
  • Elle échoue quand le domaine n’existe pas (NXDOMAIN) ou quand le nom se résout uniquement vers des adresses privées.
  • Elle affiche inconnu quand le serveur de noms n’a pas répondu. Un DNS injoignable ne dit rien de sûr sur le domaine ; aucun avertissement n’est donc envoyé.

Quand la vérification passe de réussie à échouée, UptimeWire envoie un seul avertissement par e-mail et par Telegram, avec le motif. Un avertissement DNS n’est pas un incident et ne va pas aux canaux webhook ou de messagerie instantanée.

La vérification ordinaire du site web échoue aussi quand le nom ne peut pas être résolu, avec le motif « le nom de domaine n’a pas pu être résolu ». Après des échecs répétés, cette vérification peut ouvrir un incident.

UptimeWire ne détecte pas les modifications d’enregistrements DNS, ne suit pas la propagation, n’interroge pas d’autres types d’enregistrements comme MX ou TXT et ne valide pas DNSSEC. Il vous dit que le nom a cessé de se résoudre, pas pourquoi.

Liste de contrôle

  • Notez l’état exact : NXDOMAIN, réponse vide, SERVFAIL ou délai dépassé.
  • Interrogez deux résolveurs publics et les serveurs faisant autorité.
  • Vérifiez la date d’enregistrement et les serveurs de noms chez le bureau d’enregistrement.
  • Comparez les réponses A et AAAA.
  • Pensez au cache avant de décider qu’une correction n’a pas fonctionné.
  • Gardez une trace de ce qui a changé et de quand.