dns Recherche DNS (A, MX, TXT, NS) star

Comment ça fonctionne

Saisissez un domaine, choisissez un type d'enregistrement, et la requête part en DNS-over-HTTPS (DoH) vers le résolveur public de Google à 8.8.8.8 — une API JSON sur HTTPS plutôt que le protocole binaire UDP traditionnel du port 53. Ce choix est délibéré : DoH fonctionne sur HTTPS standard, donc s'exécute depuis un navigateur sans accès aux sockets bruts, et surtout il contourne le résolveur DNS que votre système, votre routeur ou votre FAI utiliseraient normalement. Votre machine, votre réseau de bureau et votre FAI tiennent chacun leur propre cache DNS, rafraîchi selon son propre calendrier basé sur le TTL (Time To Live) de l'enregistrement — à un instant donné, chacun peut donc afficher une réponse légèrement différente et légèrement obsolète. Interroger directement le résolveur de Google contourne ces trois caches et montre ce qu'un grand résolveur public, fréquemment rafraîchi, croit actuellement — le meilleur proxy disponible de « ce que voit internet en ce moment », mais toujours le point de vue d'un seul résolveur, pas une garantie mondiale.

Chaque type d'enregistrement répond à une question opérationnelle différente. Les enregistrements A et AAAA associent un nom d'hôte à une adresse IPv4 ou IPv6 — c'est ce que votre navigateur résout avant même de pouvoir ouvrir une connexion. Les enregistrements MX listent les serveurs de messagerie acceptant le courrier du domaine, chacun avec une priorité numérique (nombre plus bas = essayé en premier) — utile lors d'une migration de messagerie, car un MX obsolète signifie que le courrier continue d'être routé vers l'ancien fournisseur. Les TXT sont du texte libre non structuré où résident les chaînes SPF, DKIM et de vérification de domaine ; un domaine peut en avoir plusieurs, et un enregistrement SPF mal formé ou absent est l'une des causes les plus courantes de courrier légitime finissant en spam. Les CNAME font pointer un nom d'hôte vers un autre comme alias (www vers le domaine nu, ou un sous-domaine vers un point de terminaison CDN) — un nom avec un CNAME ne peut pas porter d'autre type d'enregistrement sous le même nom, source fréquente de la confusion « pourquoi ce sous-domaine ne peut-il pas aussi avoir un MX ». Les NS listent les serveurs de noms faisant autorité pour répondre aux requêtes du domaine — s'ils sont erronés ou désynchronisés du registrar, aucun autre enregistrement du domaine ne se résout correctement nulle part.

Cas typique : après avoir déplacé un site vers un nouvel hébergeur, vous pointez l'enregistrement A vers l'IP du nouveau serveur. La propagation n'est pas instantanée — elle est bornée par le TTL de l'ancien enregistrement, donc un enregistrement à TTL 3600 (une heure) peut mettre jusqu'à une heure à disparaître des caches dans le monde, et certains résolveurs ignorent le TTL et le mettent en cache plus longtemps qu'ils ne devraient. Interroger directement le résolveur DoH de Google permet de vérifier si « la nouvelle valeur a au moins atteint ce résolveur majeur », sans attendre l'expiration du cache de votre propre FAI.

Ce qu'il faut savoir

• Comme DNS-over-HTTPS contourne les caches locaux, les résultats ici peuvent être plus à jour que ce que rapportent nslookup ou votre système — c'est attendu, pas un bug.
• A, MX, TXT, CNAME et NS couvrent quasiment tous les contrôles de propagation, de messagerie et de vérification ; les types plus rares comme SRV ou CAA ne sont pas inclus actuellement.
• Les changements DNS sont mis en cache, pas instantanés — attendez-vous à un délai borné par le TTL précédent, pas un effet mondial immédiat.