Blog

Comment vérifier les DNS d'un domaine : le guide complet

NS, A, AAAA, CNAME, MX, TXT, CAA : comment vérifier chaque enregistrement DNS avec dig ou un outil en ligne, et les erreurs de configuration les plus fréquentes.

Par Constantin Boulanger Publié le Mis à jour le 7 min de lecture

#dns #dig #guide #configuration

Un site qui ne s'affiche plus après une migration, des e-mails qui n'arrivent pas, un certificat qui refuse de se renouveler : dans une grande partie des cas, la réponse se trouve dans le DNS. Encore faut-il savoir le lire. Ce guide explique comment vérifier les DNS d'un domaine, enregistrement par enregistrement (NS, A, AAAA, CNAME, MX, TXT, CAA), avec la commande dig et des outils en ligne, et liste les erreurs que l'on rencontre le plus souvent.

Les outils nécessaires

  • macOS et Linux : dig est généralement disponible (paquet bind-utils ou dnsutils selon la distribution).
  • Windows : nslookup est intégré, et PowerShell propose Resolve-DnsName. Vous pouvez aussi installer dig via WSL.
  • Sans ligne de commande : notre outil DNS Lookup gratuit affiche les enregistrements A, AAAA, CNAME, MX, NS, TXT et SOA d'un domaine.

Lire une réponse de dig

dig exemple.fr A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51234
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
exemple.fr.   3600   IN   A   203.0.113.10

Trois éléments à regarder en priorité :

  • status : NOERROR (le nom existe), NXDOMAIN (le nom n'existe pas), SERVFAIL (le serveur n'a pas pu répondre, souvent un problème de délégation ou de DNSSEC).
  • ANSWER SECTION : les enregistrements eux-mêmes. Une réponse NOERROR sans section ANSWER signifie que le nom existe, mais sans enregistrement du type demandé.
  • TTL (ici 3600) : la durée en secondes pendant laquelle la réponse peut être gardée en cache.

Pour n'afficher que les valeurs, ajoutez +short.

Résolveur ou serveur faisant autorité ?

Par défaut, dig interroge le résolveur de votre machine, qui peut renvoyer une réponse en cache. Pour savoir ce qui est réellement publié, interrogez les serveurs de la zone :

dig +short NS exemple.fr
ns1.hebergeur-dns.net.
ns2.hebergeur-dns.net.

dig @ns1.hebergeur-dns.net exemple.fr A +norecurse

Dans la réponse d'un serveur faisant autorité, le drapeau aa (authoritative answer) est présent. Pour comparer avec des résolveurs publics : dig @1.1.1.1 exemple.fr A ou dig @8.8.8.8 exemple.fr A. Pour suivre toute la chaîne de résolution depuis la racine : dig +trace exemple.fr.

Vérifier chaque type d'enregistrement

NS : qui fait autorité pour le domaine

dig +short NS exemple.fr

Les serveurs de noms réellement utilisés sont ceux déclarés chez le registre, via votre registrar. Vérifiez qu'ils correspondent à ceux listés dans la zone, et que chacun répond :

for ns in $(dig +short NS exemple.fr); do
  echo "$ns : $(dig @"$ns" exemple.fr SOA +short +norecurse)"
done

Un serveur qui ne répond pas, ou qui renvoie un numéro de série SOA différent des autres, signale une zone mal synchronisée ou une ancienne délégation.

A et AAAA : les adresses IP

dig +short A exemple.fr
dig +short AAAA exemple.fr
dig +short A www.exemple.fr

Vérifiez toujours le domaine nu et www : ce sont deux noms distincts. Méfiez-vous particulièrement des enregistrements AAAA oubliés après une migration : les visiteurs en IPv6 arrivent sur l'ancien serveur pendant que vous testez en IPv4. Pour le vérifier :

curl -4 -sI https://exemple.fr | head -1
curl -6 -sI https://exemple.fr | head -1

CNAME : les alias

dig www.exemple.fr +noall +answer
www.exemple.fr.   300   IN   CNAME   exemple.fr.
exemple.fr.       3600  IN   A       203.0.113.10

Deux règles à connaître :

  • Pas de CNAME sur le domaine nu (exemple.fr), qui porte obligatoirement des enregistrements SOA et NS. Certains hébergeurs DNS proposent des équivalents (ALIAS, ANAME, aplatissement de CNAME), propres à chaque fournisseur.
  • Un nom qui porte un CNAME ne peut porter aucun autre enregistrement. Ajouter un MX ou un TXT sur www alors que www est un CNAME produit des résultats incohérents selon les résolveurs.

Pensez aussi à vérifier que la cible du CNAME existe toujours : un CNAME vers un service tiers supprimé peut être exploité pour prendre le contrôle du sous-domaine.

MX : la réception des e-mails

dig +short MX exemple.fr
10 mx1.fournisseur-mail.fr.
20 mx2.fournisseur-mail.fr.

Le nombre indique la priorité : la plus petite valeur est essayée en premier. Points de contrôle :

  • la cible d'un MX doit être un nom d'hôte qui possède un enregistrement A ou AAAA, jamais une adresse IP, et ne doit pas être un CNAME ;
  • chaque cible doit résoudre : dig +short A mx1.fournisseur-mail.fr ;
  • un domaine qui ne reçoit aucun e-mail peut le déclarer explicitement avec un « MX nul » : 0 .

TXT : SPF, DKIM, DMARC et vérifications

dig +short TXT exemple.fr
dig +short TXT _dmarc.exemple.fr
dig +short TXT google._domainkey.exemple.fr
  • SPF est publié sur le domaine lui-même et commence par v=spf1. Il ne doit y en avoir qu'un seul.
  • DMARC est publié sur _dmarc.exemple.fr et commence par v=DMARC1.
  • DKIM est publié sur selecteur._domainkey.exemple.fr ; le sélecteur dépend du service d'envoi.
  • Les enregistrements TXT de plus de 255 caractères (clés DKIM notamment) sont découpés en plusieurs chaînes entre guillemets : c'est normal, elles sont concaténées à la lecture.

Pour une analyse complète de ces enregistrements, utilisez notre outil de sécurité e-mail.

CAA : les autorités de certification autorisées

dig +short CAA exemple.fr
0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:securite@exemple.fr"
  • issue autorise une autorité à émettre des certificats pour ce nom ;
  • issuewild concerne les certificats wildcard (";" les interdit tous) ;
  • iodef indique où signaler une demande refusée.

Sans enregistrement CAA, toute autorité peut émettre. Les autorités remontent l'arborescence : un CAA posé sur exemple.fr s'applique à boutique.exemple.fr, sauf si ce dernier possède ses propres enregistrements. Un CAA qui n'autorise pas votre fournisseur actuel bloquera le prochain renouvellement.

PTR : la résolution inverse

dig +short -x 203.0.113.10

Indispensable pour un serveur qui envoie des e-mails : le nom renvoyé doit lui-même résoudre vers la même adresse IP.

Diagnostiquer un problème DNSSEC

Si le domaine est signé avec DNSSEC, une signature expirée ou un enregistrement DS obsolète chez le registre rend le domaine injoignable pour les résolveurs qui valident. Test rapide :

dig @1.1.1.1 exemple.fr A          # SERVFAIL ?
dig @1.1.1.1 exemple.fr A +cd      # réponse correcte avec +cd ?
dig +short DS exemple.fr

Si la requête échoue normalement mais réussit avec +cd (qui désactive la validation), le problème vient de DNSSEC. Cas typique : un changement d'hébergeur DNS sans suppression préalable de l'ancien enregistrement DS.

La « propagation DNS » n'existe pas vraiment

Les modifications ne se « propagent » pas : elles sont publiées immédiatement sur les serveurs faisant autorité, puis les résolveurs gardent l'ancienne réponse en cache jusqu'à expiration de son TTL. Conséquences pratiques :

  • avant une migration, baissez le TTL des enregistrements concernés (par exemple à 300 secondes), puis attendez au moins la durée de l'ancien TTL avant d'effectuer le changement ;
  • pour vérifier qu'une modification est bien en ligne, interrogez les serveurs faisant autorité plutôt que votre résolveur ;
  • un changement de serveurs de noms dépend aussi du TTL fixé par le registre de l'extension, sur lequel vous n'avez pas la main.

Les erreurs DNS les plus fréquentes

  • Deux enregistrements SPF sur le même domaine.
  • Un CNAME sur le domaine nu, ou un CNAME accompagné d'autres enregistrements.
  • Un MX qui pointe vers une adresse IP ou vers un CNAME.
  • Un AAAA oublié qui pointe vers l'ancien serveur.
  • www et le domaine nu qui pointent vers des serveurs différents.
  • Des serveurs de noms chez le registrar qui ne correspondent pas à la zone réellement éditée.
  • Un point final manquant dans un fichier de zone : mx1.fournisseur.fr devient mx1.fournisseur.fr.exemple.fr.
  • Un CAA qui n'autorise pas l'autorité de certification utilisée.
  • Un enregistrement DS resté chez le registre après un changement d'hébergeur DNS.
  • Des CNAME vers des services tiers abandonnés.

Équivalents Windows

nslookup -type=MX exemple.fr
nslookup -type=TXT _dmarc.exemple.fr 1.1.1.1
Resolve-DnsName exemple.fr -Type NS
Resolve-DnsName exemple.fr -Type MX

Checklist de vérification DNS

  1. NS : cohérents entre registrar et zone, tous joignables, même numéro de série SOA.
  2. A et AAAA : domaine nu et www pointent vers le bon serveur, en IPv4 comme en IPv6.
  3. CNAME : aucun sur le domaine nu, aucun enregistrement parasite à côté, cibles existantes.
  4. MX : cibles valides qui résolvent, priorités cohérentes.
  5. TXT : un seul SPF, DMARC et DKIM présents.
  6. CAA : cohérent avec l'autorité de certification utilisée.
  7. DNSSEC : pas de SERVFAIL sur un résolveur qui valide.

Vérifier une fois ne suffit pas : une zone DNS change au fil des migrations et des interventions. Nous expliquons pourquoi dans notre article sur la surveillance des modifications DNS et dans notre guide pour protéger la configuration DNS de votre nom de domaine.

Vérifiez votre domaine maintenant

Lancez notre outil DNS Lookup gratuit sur votre domaine et passez la checklist ci-dessus en revue. Si vous voulez être prévenu dès qu'un enregistrement change, le plan gratuit de Domains Defender surveille la configuration DNS, le certificat SSL et l'expiration d'un domaine, et vous alerte immédiatement en cas de changement critique.

À lire aussi

Articles similaires