Vérifier les DNS de votre domaine : outils pour le Web et les courriels

Vous venez de déplacer votre site Web. Il fonctionne chez vous, mais un client voit encore l’ancienne version. Ou le site s’affiche correctement, alors que les courriels de l’entreprise ont cessé d’arriver. Ces situations ont parfois un point commun : les informations DNS qui dirigent les visiteurs et les messages vers les bons services.

Quelques outils accessibles dans un navigateur permettent de voir ce que votre domaine annonce sur Internet. Bien utilisés, ils aident à répondre à une question concrète avant de toucher aux réglages : le problème vient-il de la destination publiée, d’une ancienne réponse en cache ou du service lui-même ?

Voici comment choisir un outil, lire les résultats utiles et préparer la suite avec votre hébergeur ou votre fournisseur de messagerie.

Quel outil choisir pour commencer ?

Commencez par celui qui correspond au symptôme. Vous n’avez pas besoin de lancer tous les tests disponibles ni de connaître tous les types d’enregistrements pour faire une première vérification utile.

Avant de chercher : le bon nom et la bonne référence

Dans un outil DNS, saisissez un nom, par exemple www.example.com, sans https:// ni chemin de page. Le domaine principal example.com et sa version www.example.com sont deux noms distincts. Tester l’un ne valide pas automatiquement l’autre.

Préparez aussi la valeur attendue : l’adresse ou le nom fourni par votre hébergeur pour le site, ou les destinations prescrites par votre fournisseur de courriel. Sans cette référence, vous pouvez constater qu’une réponse existe, mais pas qu’elle est correcte pour votre service.

Le DNS peut être géré ailleurs que chez le registraire qui vous facture le domaine. La zone active se trouve chez le fournisseur désigné par les serveurs de noms du domaine. Une modification dans un ancien panneau DNS peut donc n’avoir aucun effet sur les visiteurs. Notre guide sur les domaines, alias et sous-domaines explique cette répartition.

Votre site : vérifier sa destination avec dns.google

dns.google permet de consulter les réponses du service DNS public de Google. C’est un point de comparaison pratique quand votre navigateur affiche une erreur ou rejoint une destination inattendue. La documentation de Google décrit cette utilisation pour le dépannage.

1. Saisissez le nom exact du site et lancez la recherche.
2. Dans le résultat détaillé, consultez le type A pour l’adresse IPv4 et AAAA pour l’adresse IPv6, si votre service en utilise une.
3. Comparez les valeurs avec les instructions de l’hébergeur. Si un CNAME apparaît, il désigne un alias vers un autre nom : comparez aussi cette destination.
4. Recommencez avec et sans www si les deux adresses doivent fonctionner.

Exemple fictif : votre hébergeur prévoit l’adresse 192.0.2.20, mais la recherche retourne encore 192.0.2.10. Vous avez alors une différence précise à examiner. Elle peut venir d’un ancien cache ou d’un enregistrement resté inchangé dans la zone active. Ces adresses sont réservées aux exemples ; elles ne doivent pas être copiées dans votre configuration.

Une adresse IPv6 oubliée peut également expliquer pourquoi certains visiteurs atteignent un autre serveur. À l’inverse, l’absence d’un AAAA n’est pas une panne si votre hébergement n’utilise pas IPv6.

Si votre site passe par un CDN ou un service mandataire, l’adresse publique peut être celle de ce service plutôt que celle de l’hébergement d’origine. Comparez toujours avec la configuration prévue, pas avec une adresse trouvée dans un ancien courriel.

Lorsque les réponses correspondent à cette configuration, poursuivez vers le service Web : certificat, redirection, contenu ou cache du site. Une recherche DNS ne vérifie pas ces éléments. Pour préparer un déplacement, notre guide pour modifier les DNS du site en préservant la messagerie aide à éviter qu’une intervention sur le site perturbe aussi les courriels.

Vos courriels : distinguer réception et authentification avec MXToolbox

MXToolbox regroupe plusieurs vérifications de messagerie. Son répertoire officiel des outils distingue notamment les recherches MX, SPF, DKIM et DMARC. Le bon point de départ dépend du problème rencontré.

Vous ne recevez plus de messages

Choisissez la recherche MX et saisissez le domaine situé après le @ de votre adresse courriel. Les résultats indiquent les serveurs désignés pour recevoir les messages. Comparez leurs noms avec les instructions du fournisseur qui héberge réellement vos boîtes.

C’est particulièrement utile après un changement de serveurs DNS : le site peut fonctionner alors que les MX n’ont pas été repris dans la nouvelle zone. Le serveur Web et la messagerie peuvent être chez deux fournisseurs différents. Déplacer le site n’impose donc pas de déplacer les boîtes.

Si les destinations sont correctes, conservez le message de refus et vérifiez la boîte concernée : existe-t-elle, est-elle pleine, le problème touche-t-il tous les expéditeurs ? Notre guide sur les courriels non reçus ou impossibles à envoyer poursuit ces vérifications.

Vos messages sont refusés ou classés comme indésirables

Les recherches d’authentification deviennent alors utiles :

• SPF : quels services sont autorisés à envoyer pour le domaine utilisé par SPF ?
• DKIM : la clé publique du service d’envoi est-elle publiée ? Le test demande son sélecteur, à récupérer auprès du fournisseur ou dans la signature d’un message.
• DMARC : quelle politique est publiée pour le domaine de l’expéditeur visible ?

Le DNS publie les éléments nécessaires, mais c’est le message réellement envoyé qui doit réussir l’authentification. DMARC exige notamment une authentification SPF ou DKIM réussie et alignée avec le domaine visible. Ces principes sont décrits dans la spécification DMARC.

Pensez à chaque source d’envoi : une boîte de travail, le formulaire du site et un logiciel de facturation peuvent utiliser des services différents. Une boîte bien configurée ne valide pas automatiquement les messages du formulaire.

Pour aller plus loin, récupérez les en-têtes complets d’un message reçu et consultez notre article sur l’authentification des courriels pour Gmail et Yahoo. Même une authentification réussie ne garantit pas la boîte de réception : réputation, consentement et qualité des envois comptent aussi.

Après un changement : comparer les réponses avec DNSChecker

DNSChecker permet de rechercher un nom et un type d’enregistrement auprès d’une sélection de serveurs DNS dans plusieurs régions. WhatsMyDNS propose une comparaison similaire. Ces outils sont utiles lorsque le changement semble visible pour certaines personnes seulement.

Choisissez le même nom et le même type que lors de votre première vérification. Pour un changement d’adresse du site, regardez par exemple le A ; pour un changement de messagerie, les MX. Comparez les valeurs retournées à celles attendues, pas seulement les coches de couleur.

Ce qu’on appelle la « propagation DNS » dépend notamment des caches. Les serveurs peuvent conserver une réponse pendant une durée encadrée par son TTL, exprimé en secondes. Un TTL de 3600 correspond à une heure ; le nombre affiché par un outil peut être le temps restant dans un cache. Les utilisateurs ne basculent donc pas tous au même instant.

Réduire le TTL au moment du changement n’efface pas les anciennes réponses déjà conservées. Une réponse indiquant qu’un nom n’existe pas peut aussi rester en cache, comme le décrit le standard des réponses négatives.

Faut-il simplement attendre 24 ou 48 heures ? Vérifiez d’abord la zone active. Si elle publie la mauvaise valeur, attendre ne la corrigera pas. Si elle est correcte et que certains caches conservent l’ancienne réponse, les TTL et l’heure du changement deviennent des informations utiles pour suivre l’évolution.

Une carte reste un échantillon, pas un certificat de disponibilité mondiale. Des réponses différentes peuvent aussi être prévues par un CDN. Si seul votre ordinateur semble conserver une ancienne valeur, notre guide pour vider le cache DNS peut aider, une fois les premiers résultats relevés.

Comprendre un résultat vide ou une erreur

Une recherche sans réponse n’a pas toujours la même signification. Voici les principaux cas à reconnaître :

Les codes de réponse DNS décrivent le résultat de la requête, pas l’état complet du site ou de la messagerie.

Un outil public peut aussi obtenir une réponse différente de votre ordinateur, notamment avec un VPN, un réseau d’entreprise ou un DNS propre au navigateur. Cette différence est une piste à transmettre à l’équipe technique. Elle ne justifie pas à elle seule de remplacer les paramètres DNS de tous les postes.

Vous préférez le terminal ? Quelques commandes suffisent

Les outils Web couvrent déjà les vérifications précédentes. Le terminal est surtout pratique pour répéter une recherche et transmettre sa sortie exacte. Remplacez example.com par votre domaine public ; les exemples consultent des données sans modifier vos réglages.

Windows : nslookup ou PowerShell

Dans l’invite de commandes ou PowerShell, nslookup permet de consulter l’adresse du site et les serveurs de réception :

nslookup -type=A example.com
nslookup -type=MX example.com

La première recherche concerne le Web, la seconde la réception des courriels. Une « réponse ne faisant pas autorité » est normale lorsqu’elle vient d’un résolveur intermédiaire ; ce libellé ne signifie pas que la réponse est fausse.

Sous Windows, le module DnsClient propose aussi Resolve-DnsName. Pour comparer une réponse A avec celle du DNS public de Google :

Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8 -DnsOnly -NoHostsFile

Cette commande choisit le serveur pour cette recherche seulement. -DnsOnly limite la recherche au DNS et -NoHostsFile écarte le fichier hosts.

Linux et macOS : dig, ou host pour une réponse concise

Dans Terminal sur macOS, ou avec les utilitaires DNS installés sur votre distribution Linux, dig fournit une réponse détaillée. host propose une sortie plus courte lorsqu’il est disponible. Les options figurent dans les manuels BIND.

dig example.com A
dig @8.8.8.8 example.com A
host -t MX example.com

Les deux premières commandes comparent le même enregistrement avec le serveur choisi par l’outil, puis avec Google. La troisième recherche les serveurs de réception. Conservez les sorties complètes, le serveur interrogé et l’heure du test : ces renseignements sont plus utiles à l’assistance qu’une capture limitée à « ça ne fonctionne pas ».

Vous cherchez plutôt qui gère le domaine ?

Pour retrouver le registraire ou les statuts d’un domaine, utilisez ICANN Lookup pour les domaines génériques comme .com, ou le WHOIS de CIRA pour un .ca. Cela peut aider à retrouver le bon interlocuteur avant un renouvellement ou un transfert.

L’ICANN utilise désormais RDAP comme référence pour les données d’enregistrement des domaines génériques, à la suite de sa transition depuis WHOIS. Ces recherches complètent le diagnostic DNS, mais ne donnent pas les réglages complets de votre site ou de vos boîtes. Le registraire n’est pas nécessairement leur hébergeur, et certaines coordonnées sont masquées pour protéger la vie privée.

Quand demander un coup de main à Nuagerie

Si les résultats restent contradictoires, si tout le domaine cesse de répondre après un changement de serveurs de noms ou si vous ne savez pas quelle zone est active, mieux vaut faire examiner la configuration avant de multiplier les modifications.

Des outils spécialisés comme DNSViz et Zonemaster permettent alors à une équipe technique d’examiner la délégation et DNSSEC, le mécanisme de validation des réponses DNS. Ils servent à approfondir une anomalie précise ; vous n’avez pas besoin de maîtriser leurs rapports pour demander de l’aide.

Pour un service existant, retrouvez nos coordonnées sur la page d’assistance. Préparez simplement :

• le domaine ou le sous-domaine touché ;
• ce qui ne fonctionne pas et depuis quand ;
• le changement récent, s’il y en a un ;
• l’outil utilisé, le résultat et l’heure du test ;
• la portée du problème : tout le monde, certains destinataires ou un seul réseau.

N’envoyez pas de mot de passe ou de clé privée. Masquez les renseignements personnels dans les en-têtes de courriel et réservez les outils publics aux noms que vous pouvez leur communiquer.

Vous préparez plutôt un nouveau site ou une migration ? Présentez-nous votre configuration actuelle. Identifier où se trouvent le domaine, les DNS, le site et la messagerie permet de prévoir les bonnes vérifications avant le changement.