fren
Connexion

Diagnostiquer un problème DNS

3 min de lecture07 novembre 2026

Quand un nom ne répond pas, quatre couches peuvent être en cause : le poste client, le résolveur, la délégation et la zone. La méthode consiste à interroger de plus en plus près de la source, et à lire le code de réponse plutôt qu'à deviner.

Qualifier la panne

Commencez par distinguer un échec de résolution d'un échec de connexion :

Bash
getent hosts votre-domaine.fr
curl -v https://votre-domaine.fr/ 2>&1 | head -n 20

« Could not resolve host » désigne le DNS. Un « connection timed out » après résolution désigne le réseau ou le service. Un code HTTP 502 ou 504 désigne l'application derrière le serveur web.

Interroger le DNS correctement

Bash
dig votre-domaine.fr A
dig votre-domaine.fr AAAA
dig votre-domaine.fr NS
dig votre-domaine.fr MX
dig votre-domaine.fr TXT

Ajoutez +short pour une réponse lisible, et interrogez un serveur précis avec @ :

Bash
dig @1.1.1.1 A votre-domaine.fr +short
dig @ns1.fournisseur.fr A votre-domaine.fr +short
dig +trace votre-domaine.fr

Si l'autorité répond correctement et qu'un résolveur public ne voit pas la même chose, vous êtes face à un cache ou à une délégation. dig +trace montre où la chaîne s'arrête. dig +norecurse @ns1.fournisseur.fr montre la délégation sans demander la résolution complète.

nslookup reste utile pour un contrôle rapide, mais dig affiche le statut, les drapeaux et la section autorité, indispensables au diagnostic.

Lire les codes de réponse

Statut Signification Piste
NOERROR avec réponse enregistrement trouvé service ou pare-feu à vérifier
NOERROR sans réponse le nom existe, pas ce type NODATA : AAAA ou MX absent
NXDOMAIN le nom n'existe pas faute de frappe, domaine supprimé, mauvaise zone
SERVFAIL le serveur n'a pas pu répondre DNSSEC cassé, autorité injoignable, zone invalide
REFUSED requête refusée liste d'accès du serveur DNS
Timeout pas de réponse NS injoignable, UDP 53 filtré

Les drapeaux renseignent aussi : aa indique une réponse faisant autorité, ad une validation DNSSEC réussie. Une réponse ad absente n'est pas forcément une erreur si le résolveur ne valide pas.

Problèmes locaux et de zone

  • /etc/hosts peut court-circuiter le DNS : vérifiez-le en premier.
  • /etc/resolv.conf ou resolvectl status montre les résolveurs réellement utilisés. Sous systemd-resolved, 127.0.0.53 est un relais local normal.
  • Un VPN ou Docker (127.0.0.11) peut imposer son propre résolveur.
  • Un domaine de recherche mal configuré transforme mon-site en mon-site.interne : utilisez un point final pour un nom absolu.
  • Videz le cache local avant de conclure.

Pour contourner le DNS et tester le serveur directement :

Bash
curl -sI --resolve votre-domaine.fr:443:[VOTRE_IPV6] https://votre-domaine.fr/ | head -n 5

Côté zone, vérifiez que vous modifiez la bonne zone : dig NS votre-domaine.fr +short doit renvoyer les serveurs de votre fournisseur DNS actuel. Si ce sont ceux d'un ancien prestataire, vos changements ne s'appliquent pas.

Cherchez ensuite les erreurs classiques : CNAME à l'apex, deux enregistrements SPF, MX pointant vers un nom sans A, CAA trop strict, AAAA obsolète. Pour DNSSEC, un DS publié chez l'extension sans DNSKEY correspondante provoque un SERVFAIL global : retirez le DS ou complétez la chaîne.

Confirmer la correction

Interrogez l'autorité, puis deux résolveurs publics, puis testez l'application réelle. Un enregistrement corrigé mais un cache de 24 heures signifie une attente pouvant aller jusqu'à un jour : baissez le TTL avant la prochaine intervention.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi