À quoi sert une recherche DNS
Diagnostiquer l'origine d'une panne de site.
Vérifier un changement avant une mise en production.
Confirmer la propriété d'un domaine lors d'une vérification par TXT.
Mettre en place SPF DKIM DMARC BIMI et contrôler la visibilité.
Préparer une migration avec un TTL réduit et suivre l'effet réel sur le réseau.
Comparer la réponse vue depuis votre poste et celle vue depuis d'autres régions.
Bon à savoir
On parle souvent de propagation DNS. En réalité le système met en cache les réponses selon le TTL. Tant que ce délai n'a pas expiré certains résolveurs gardent l'ancienne valeur. Le mot propagation reste pratique pour décrire cet effet.
Ce que fait l'outil
Résolution récursive complète depuis la racine jusqu'aux serveurs autoritaires.
Choix d'un résolveur public comme Google Cloudflare Quad9 OpenDNS Yandex ou du serveur autoritaire quand c'est pertinent.
Affichage des réponses brutes avec le TTL et les données.
Trace itérative optionnelle qui montre chaque saut et la latence.
Lecture claire quand aucune réponse structurée n'est trouvée.
Fonctionnement d'une recherche DNS
Votre appareil demande la réponse au résolveur configuré sur le poste ou sur la box.
Le résolveur consulte d'abord son cache local.
Sans réponse, il interroge un serveur racine qui lui indique le serveur du domaine de premier niveau.
Le serveur TLD renvoie vers les serveurs autoritaires du nom recherché.
Le résolveur interroge un serveur autoritaire qui renvoie l'enregistrement demandé avec son TTL.
Le résolveur met la réponse en cache pour accélérer les prochaines requêtes et la renvoie à votre appareil.
Conseil rapide
Pour vérifier un résultat depuis votre poste, vous pouvez utiliser nslookup sous Windows et dig sous Mac et Linux. Ces commandes lisent la configuration locale ou un résolveur choisi.
Comprendre le TTL et la fameuse propagation
Le TTL est une durée exprimée en secondes. Elle indique combien de temps une réponse peut rester en cache.
Un TTL court rend un changement visible plus vite. Très utile pendant une migration.
Un TTL moyen ou long réduit la charge sur les serveurs autoritaires. Bien pour un service stable.
Un fournisseur d'accès peut garder une réponse plus longtemps selon sa propre politique de cache. Il arrive que la mise à jour prenne plus de temps que prévu.
Astuce pratique
Avant une bascule réduire le TTL un peu en avance. Faire le changement. Contrôler les réponses depuis plusieurs réseaux. Remonter ensuite le TTL choisi pour l exploitation.
Quand lancer une recherche DNS
Un site ne répond plus alors que le serveur est en ligne.
Vous venez de modifier un enregistrement et vous voulez voir la réponse réelle.
Vous déployez un nouveau service et vous devez valider A AAAA CNAME ou MX.
Vous installez SPF DKIM DMARC ou BIMI et vous souhaitez confirmer la visibilité publique.
Vous préparez une migration et vous voulez mesurer la latence et la trace de bout en bout.
Lecture d'une réponse
Présence d'une ou plusieurs adresses pour A ou AAAA
Le client choisit une adresse dans la liste ce qui répartit la charge de façon simple.
Présence d'un CNAME
La réponse montre la cible. Vérifier ensuite que la cible publie bien A ou AAAA.
Présence de NS et de SOA
La zone est servie par ces hôtes. Le serial du SOA doit avancer après chaque mise à jour.
Réponse vide ou NXDOMAIN
Aucun enregistrement pour ce nom. Vérifier l'orthographe le sous domaine et la zone.
TTL élevé
Un décalage après un changement est possible tant que le cache n'a pas expiré.
Limites et points d'attention
Un CNAME ne doit pas coexister avec A AAAA MX ou TXT au même endroit.
À l'apex d'un domaine, on évite le CNAME. Utiliser un équivalent proposé par le fournisseur si présent.
Un MX doit viser un nom qui résout en A ou AAAA. Pas de CNAME en cible de MX.
Un PTR doit renvoyer un nom qui résout vers l'adresse d'origine pour garder une bonne cohérence.
Les paramètres SVCB et HTTPS guident le client, mais ne remplacent pas A et AAAA.
Bonnes pratiques pour gagner du temps
Documenter chaque changement avec la date le TTL et la raison.
Tester depuis votre réseau puis depuis des résolveurs publics.
Comparer la réponse du serveur autoritaire avec la réponse d'un résolveur public.
Surveiller les noms critiques et poser des alertes en cas de changement inattendu.
Conserver une capture de la trace quand un incident se produit afin de la partager avec un prestataire.
Foire aux questions
En quoi cela diffère des commandes locales
L'outil interroge des résolveurs publics et peut afficher la trace complète. Les commandes locales restent utiles pour un contrôle rapide depuis votre poste.
Combien de temps pour voir un changement ?
De quelques minutes à plusieurs heures selon le TTL et les caches en place chez les fournisseurs d'accès et chez certains résolveurs publics.
Que faire si la réponse diffère selon les régions ?
Attendre l'expiration du TTL. Purger le cache local si possible. Vérifier la cohérence côté serveurs autoritaires.
Quels types d enregistrements vérifier en priorité ?
A AAAA CNAME MX TXT NS SOA restent la base. Selon le besoin ajouter CAA PTR SRV SVCB ou HTTPS. Avec DNSSEC contrôler DS et DNSKEY.