Tester le DNS d’un domaine étape par étape

Tester un DNS, c'est vérifier trois choses distinctes : que votre poste résout le nom, que les serveurs faisant autorité renvoient la bonne valeur, et que la délégation déclarée chez le registre pointe bien vers eux. Une commande dig et la lecture du status suffisent dans la majorité des cas.

Trois tests différents derrière la même question

Un client vous signale que le site ne répond plus. Vous tapez l'adresse, elle s'ouvre chez vous. Le DNS est souvent en cause, mais rarement au même endroit d'une panne à l'autre.

Le premier niveau est votre résolveur : celui de la box, du réseau d'entreprise ou un service public comme 1.1.1.1. Il peut servir une réponse mise en cache plusieurs heures plus tôt. Le deuxième niveau, ce sont les serveurs faisant autorité de la zone, ceux qui détiennent la valeur de référence. Le troisième, presque toujours oublié, c'est la délégation : les serveurs de noms enregistrés chez le registre du TLD sont-ils ceux que vous administrez aujourd'hui ?

Ces trois niveaux tombent en panne indépendamment. Une zone parfaitement configurée chez votre hébergeur ne sert à rien si le registre pointe encore vers les serveurs de l'ancien prestataire.

Les commandes qui répondent en dix secondes

dig reste l'outil de référence. Il arrive avec le paquet bind9-dnsutils sous Debian et Ubuntu, bind-utils sous RHEL et dérivés. Sur macOS, si la commande manque, `brew install bind` la fournit. Sur Windows, nslookup et Resolve-DnsName font le travail de base.

Le drapeau `+short` supprime tout le contexte et ne renvoie que la donnée. Pratique dans un script, gênant en diagnostic : sans le status ni les flags, vous perdez la moitié de l'information.

Objectif	Commande	Ce que vous regardez
Résolution simple	dig exemple.fr A +short	l'adresse renvoyée, rien d'autre
Comparer deux résolveurs	dig @1.1.1.1 exemple.fr A	un écart avec votre résolveur habituel
Réponse faisant autorité	dig @ns1.exemple.fr exemple.fr A	le flag aa dans l'en-tête
Chaîne depuis la racine	dig +trace exemple.fr	l'étape où la délégation casse
Messagerie	dig exemple.fr MX	priorités et noms des serveurs
SPF et vérifications texte	dig exemple.fr TXT	la ligne v=spf1, et une seule
Inverse	dig -x 203.0.113.10	le PTR déclaré par le titulaire de l'IP
Windows sans dig	nslookup -type=MX exemple.fr 1.1.1.1	la réponse d'un résolveur choisi

Lire le status avant de lire la réponse

L'en-tête de la sortie dig porte le verdict : `;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41521`. Le reste ne s'interprète qu'à la lumière de cette ligne.

Les flags qui suivent complètent le tableau. `aa` signale que le serveur interrogé fait autorité sur la zone. `ra` que le résolveur accepte la récursion. `ad` que la réponse a passé la validation DNSSEC. `tc` que le message a été tronqué en UDP : le client doit rejouer la requête en TCP, toujours sur le port 53. Sans EDNS0 (RFC 6891), une réponse UDP est plafonnée à 512 octets, d'où des troncatures fréquentes sur les zones signées.

Le TTL affiché devant chaque enregistrement décroît tant que la réponse reste en cache. Lancez deux dig d'affilée sur le même résolveur : si le TTL passe de 3542 à 3538, vous lisez un cache, pas la zone.

status	Signification	Où chercher
NOERROR	requête traitée, la section ANSWER peut être vide	ANSWER vide = le nom existe mais pas pour ce type
NXDOMAIN	le nom n'existe pas dans la zone	faute de frappe, enregistrement supprimé, zone absente
SERVFAIL	le résolveur n'a pas pu produire de réponse	validation DNSSEC, serveurs injoignables
REFUSED	le serveur refuse de répondre à cette requête	vue restreinte, transfert de zone bloqué, mauvais serveur
FORMERR	requête mal formée pour le serveur	EDNS mal supporté, retester avec +noedns

Vérifier un changement de zone sans attendre 48 heures

Le mot propagation décrit mal ce qui se passe. Rien ne se propage : chaque résolveur conserve l'ancienne valeur jusqu'à expiration du TTL, puis va chercher la nouvelle de son côté. Un TTL de 3600 signifie au pire une heure d'écart entre deux visiteurs.

Avant une migration, abaissez le TTL à 300 secondes au moins 24 heures à l'avance, le temps que l'ancienne valeur expire partout. Vous le remonterez après la bascule.

Pour un nom qui n'existait pas encore, c'est le cache négatif qui s'applique. Sa durée vient du champ MINIMUM du SOA, borné par le TTL de l'enregistrement SOA lui-même (RFC 2308). Un MINIMUM à 86400 vous fera attendre une journée entière parce qu'un collègue a testé le sous-domaine trois minutes trop tôt.

• Interroger tous les serveurs de la zone : `for ns in $(dig +short NS exemple.fr); do echo -n "$ns "; dig @$ns exemple.fr A +short; done`
• Comparer les numéros de série : `dig +nssearch exemple.fr` affiche le SOA vu par chaque serveur, un serial en retard trahit un transfert bloqué entre maître et esclave
• Contrôler ce que dit le parent : `dig +trace exemple.fr` remonte depuis la racine et montre la délégation publiée par le registre du TLD
• Tester un résolveur qui n'a jamais vu l'ancienne valeur : `dig @9.9.9.9 exemple.fr A`

Les contrôles de zone qu’on oublie

Une zone qui résout n'est pas une zone saine. Ces cinq vérifications prennent deux minutes et évitent des pannes qui se déclarent des semaines plus tard, souvent au pire moment : renouvellement de certificat, campagne d'emailing, changement d'hébergeur.

• Transfert de zone : `dig AXFR exemple.fr @ns1.exemple.fr` doit se terminer par un REFUSED ou un « Transfer failed ». Si la zone entière s'affiche, vous publiez votre inventaire interne à qui le demande
• CAA (RFC 8659) : `dig exemple.fr CAA`. Une valeur oubliée qui n'autorise que l'ancienne autorité bloquera l'émission du prochain certificat, ce contrôle étant obligatoire pour les autorités de certification depuis septembre 2017
• MX et NS ne doivent jamais pointer vers un alias CNAME (RFC 2181, section 10.3). Certains serveurs de messagerie refusent la remise dans ce cas
• SPF : un seul enregistrement TXT commençant par v=spf1, et au maximum 10 résolutions DNS déclenchées par les mécanismes include, a, mx et ptr (RFC 7208). Au-delà, le résultat est permerror et vos messages perdent le bénéfice de l'authentification
• DNSSEC : `dig exemple.fr +dnssec` puis `delv exemple.fr`. Un SERVFAIL qui disparaît avec `dig +cd` désigne une chaîne de confiance cassée, typiquement un enregistrement DS resté chez le registre après un changement de serveurs DNS

Ce que le test DNS ne dit pas

Un `ping exemple.fr` qui échoue mais affiche l'adresse IP n'est pas un incident DNS : la résolution a fonctionné, la panne est ailleurs. À l'inverse, un « hôte inconnu » sans aucune IP renvoie bien au DNS.

WHOIS et DNS ne racontent pas la même histoire. Le WHOIS liste les serveurs de noms déclarés au registre par le bureau d'enregistrement. Le DNS montre ce que ces serveurs répondent réellement. Un domaine peut afficher les bons NS au WHOIS et renvoyer NXDOMAIN parce que la zone n'a jamais été créée côté hébergeur, cas classique après un transfert de domaine.

Comparer la vitesse de 1.1.1.1, 8.8.8.8 et 9.9.9.9 est encore un autre exercice : cela mesure la latence de votre réseau vers un nœud anycast, pas la santé de votre zone. Pour tester un résolveur chiffré, `kdig +tls @1.1.1.1 exemple.fr` passe par le port 853 (DoT, RFC 7858), tandis qu'une requête DoH emprunte HTTPS sur le port 443 (RFC 8484) et se teste avec un simple curl.

Questions fréquentes

Comment tester le DNS sans installer dig ?

Sous Windows, `nslookup -type=MX exemple.fr 1.1.1.1` ou, en PowerShell, `Resolve-DnsName exemple.fr -Type MX -Server 1.1.1.1`. Sous Linux avec systemd-resolved, `resolvectl query exemple.fr` indique en prime quel résolveur a répondu. Limite à connaître : nslookup n'affiche ni les flags ni le TTL restant, ce qui suffit pour vérifier une valeur mais pas pour diagnostiquer un cache ou une réponse non autoritative.

Pourquoi le site répond chez moi et pas chez mon client ?

Trois causes reviennent : votre résolveur a déjà la nouvelle valeur alors que le sien garde l'ancienne jusqu'à expiration du TTL, un seul des serveurs faisant autorité a reçu la mise à jour, ou le cache local du poste n'a pas été vidé. Videz-le avec `ipconfig /flushdns` sous Windows, `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` sous macOS, `resolvectl flush-caches` sous Linux, puis comparez avec un résolveur public.

Faut-il vraiment attendre 48 heures après un changement DNS ?

Non, ce chiffre est un héritage des années où les zones des TLD étaient régénérées une ou deux fois par jour. Le délai réel est le TTL de l'enregistrement modifié, auquel s'ajoute le temps de publication du registre pour un changement de serveurs de noms, aujourd'hui de quelques minutes à quelques heures selon le TLD. La marge de sécurité vient surtout de résolveurs domestiques qui ignorent les TTL courts.

Quelle différence entre dig +trace et dig @serveur ?

`dig @ns1.exemple.fr` pose la question à un serveur précis et vous montre sa réponse à lui. `dig +trace` refait tout le parcours depuis les serveurs racine, en interrogeant la racine, puis les serveurs du TLD, puis ceux de la zone. La trace localise l'étape où la délégation casse, mais elle contourne votre résolveur : elle ne reproduit pas ce que voit un visiteur.

Comment savoir si un SERVFAIL vient de DNSSEC ?

Rejouez la requête avec `dig +cd exemple.fr` (checking disabled, la validation est désactivée). Si la réponse revient en NOERROR, DNSSEC est en cause : enregistrement DS obsolète chez le registre, signatures expirées, rotation de clé mal terminée. Si le SERVFAIL persiste, regardez plutôt du côté des serveurs faisant autorité injoignables ou d'un pare-feu qui bloque le port 53 en TCP.

Testez vos connaissances

À lire aussi

commande dig · cache · cloudflare dns 1 1 1 1 · anycast