Consulter la configuration DNS d'un domaine
Saisissez un nom de domaine et l'outil interroge les serveurs de noms pour afficher ses
enregistrements : A et AAAA (adresses du serveur), MX
(serveurs de messagerie), NS (serveurs de noms), TXT (vérifications et
authentification), CNAME (alias) et SOA (zone de référence).
Chaque enregistrement s'affiche avec sa durée de vie, le fameux TTL, exprimée en secondes. Cette valeur détermine combien de temps un serveur intermédiaire conserve la réponse en mémoire avant de la redemander.
Ce que chaque type d'enregistrement fait
A et AAAA associent le domaine à l'adresse d'un serveur, en IPv4 pour le premier, en IPv6 pour le second. C'est ce qui dirige les visiteurs vers votre hébergement.
MX désigne les serveurs qui reçoivent votre courrier, avec une priorité numérique : la valeur la plus basse est essayée en premier. C'est l'enregistrement à vérifier quand des e-mails n'arrivent plus.
NS indique quels serveurs font autorité sur la zone. Il détermine où sont réellement gérés vos enregistrements — souvent ailleurs que là où vous croyez.
TXT est le fourre-tout utile : il porte l'authentification des e-mails (SPF, DKIM, DMARC) et les codes de vérification demandés par Google ou d'autres services.
CNAME crée un alias vers un autre nom. Un domaine ne peut pas porter à la fois un CNAME et d'autres enregistrements sur le même nom : c'est une source d'erreur classique à la racine d'un domaine.
Le diagnostic qui sert le plus souvent : les e-mails
Quand un courrier n'arrive pas ou part systématiquement en indésirable, le DNS est le premier endroit à regarder.
Vérifiez d'abord que les enregistrements MX pointent bien vers le service que vous
utilisez réellement. Après une migration d'hébergement, il n'est pas rare que les MX pointent
encore vers l'ancien prestataire : le site fonctionne, les e-mails partent ailleurs.
Regardez ensuite les enregistrements TXT. Un SPF absent, ou pire, deux SPF
déclarés — ce que la norme interdit et qui invalide les deux —, envoie vos messages droit dans les
indésirables. Un seul enregistrement SPF par domaine, c'est une règle stricte.
Comprendre la « propagation »
Le terme est trompeur. Rien ne se propage : les serveurs intermédiaires conservent simplement l'ancienne réponse jusqu'à expiration de son TTL, puis redemandent la valeur à jour.
La conséquence pratique est utile à connaître : abaissez le TTL avant une migration, pas après. Passer un TTL de 24 heures à quelques minutes la veille du changement permet une bascule presque immédiate. Le baisser une fois la migration lancée ne sert à rien, puisque l'ancienne valeur est déjà en cache un peu partout.
Notez aussi que ce que vous voyez ici est ce que voit ce serveur au moment de la requête. Un visiteur passant par un autre fournisseur d'accès peut encore obtenir l'ancienne réponse pendant la durée du TTL précédent.
Vérifier qui gère réellement votre zone
Les enregistrements NS répondent à une question fréquente : pourquoi une modification
faite dans une interface reste sans effet ?
Presque toujours parce que la zone est éditée à un endroit alors que les NS désignent un autre prestataire. Vous modifiez une configuration que plus personne ne consulte. Comparez les NS affichés ici avec l'interface où vous travaillez : s'ils diffèrent, vous avez trouvé le problème.
Une photographie, pas une surveillance
L'outil affiche l'état des enregistrements à l'instant de la requête, depuis notre serveur. Il ne surveille pas les changements dans le temps et ne teste pas la validité d'un SPF ou d'un DMARC : il montre ce qui est déclaré, à vous de vérifier que la syntaxe est correcte.