Recherche DNS : enregistrements A, AAAA, MX et autres

Comment utiliser cet outil

1. Saisissez un nom DNS public, pas une URL complète, des identifiants ou un nom interne privé.
2. Choisissez le type d’enregistrement et lancez la requête. Le nom saisi passe par le serveur Savvy Toolkit vers Google Public DNS.
3. Lisez les noms, types, données et TTL renvoyés avec le statut DNS. Distinguez une réponse vide, une erreur DNS et une requête échouée.

Interroger un nom, pas une adresse de page

Saisissez le nom dont le registre DNS vous intéresse, comme example.com, sans https://, chemin, port ou adresse électronique. www.example.com est un autre nom que example.com et peut renvoyer des enregistrements différents. Un point final est retiré lors de la normalisation ; les noms internationalisés acceptés sont convertis en forme DNS. Le formulaire rejette les noms mal formés au lieu de deviner la partie utile d’une URL collée. Il ne dresse pas une liste de sous-domaines ni de noms internes.

Choisissez un type et lancez la requête. Les types proposés sont A, AAAA, CNAME, MX, NS, TXT et SOA. Changer le nom ou le type efface l’ancien résultat. Savvy Toolkit interroge ensuite Google Public DNS par son serveur. Il n’inspecte pas le cache DNS de votre ordinateur et n’interroge pas tous les types automatiquement. L’heure affichée correspond à cette observation, pas à la date de modification des enregistrements du site. Conservez cette distinction lors des comparaisons entre deux résultats.

Choisir le registre selon la question

A demande une adresse IPv4 et AAAA une IPv6. CNAME interroge un alias, MX des enregistrements d’acheminement du courrier et NS des serveurs de noms au nom demandé. TXT peut contenir plusieurs textes sans lien entre eux ; afficher une valeur ne certifie ni politique de courrier, ni validation de domaine, ni propriété d’un compte. SOA contient des informations de zone. L’outil présente les données renvoyées sans valider toute la configuration liée à chaque type ou aux services qui l’utilisent.

L’absence de réponse A ne prouve pas l’absence de AAAA, MX ou TXT. Interrogez le type pertinent avant de conclure. Demander NS pour un hôte n’inspecte pas non plus toute la délégation des zones parentes. Il n’existe pas de sélecteur CAA ou PTR, de mode autoritatif, de choix de résolveur ou de carte mondiale de propagation. Utilisez un diagnostic spécialisé pour ces questions. Un contrôle absent n’est pas un résultat DNS vide et ne prouve pas qu’un autre registre manque.

Lire le code et les réponses ensemble

Le code résume la réponse DNS ; le tableau contient les enregistrements renvoyés. Le code 0, NOERROR, peut arriver sans réponse du type demandé. Le code 3, NXDOMAIN, indique que le nom demandé n’existe pas selon cette réponse du résolveur. Le code 2, SERVFAIL, représente un échec de résolution, pas une absence du nom. Un échec de requête Savvy Toolkit est distinct : aucune réponse valide du fournisseur n’était disponible pour interpréter l’état DNS de la question posée.

Chaque ligne donne nom, type, TTL et valeur. Le type demandé et les types renvoyés ne coïncident pas nécessairement dans toutes les lignes : des enregistrements liés à un alias peuvent apparaître. Un type numérique inconnu reste numérique au lieu de recevoir le libellé sélectionné. Un tableau vide ne masque pas une adresse obtenue correctement. Gardez nom, type, code et heure lors des comparaisons. Une question modifiée ne doit pas être confondue avec une modification de réponse ou une réparation de configuration.

Interpréter le TTL sans promettre la propagation

Le TTL est une durée en secondes associée à l’enregistrement renvoyé. Ce n’est pas une date d’expiration du domaine ni un compte à rebours jusqu’à ce que tous les visiteurs voient un changement. Un résolveur récursif peut renvoyer une réponse en cache avec un TTL restant. D’autres résolveurs, caches locaux et noms demandés produisent parfois d’autres observations. Un TTL de 300 secondes vaut cinq minutes, sans prouver qu’une modification atteindra tout le monde cinq minutes après cette requête.

Pour une modification prévue, conservez les anciens enregistrements et les valeurs attendues, puis comparez l’observation avec ce plan. Répétez le même nom et le même type ; examinez séparément la configuration autoritative. Savvy Toolkit ne garde pas d’historique et ne surveille pas l’achèvement de propagation. Une heure récente ne prouve pas que la réponse récursive vient d’être obtenue du serveur autoritatif. Le résultat appartient à un résolveur donné et à son comportement actuel, pas à une mesure de tous les visiteurs du site.

Distinguer DNS et disponibilité du service

Une réponse A ou AAAA fournit des adresses. Elle ne démontre pas HTTPS opérationnel, courrier accepté, certificat valide ni accès depuis votre réseau. Un MX ne teste pas une boîte aux lettres et TXT ne valide pas toute l’authentification des expéditeurs. Ces tâches demandent des observations séparées. Le vérificateur d’indexation inspecte des réponses HTTP publiques acceptées et leurs déclarations, sans certifier l’indexation des moteurs ni détecter tous les problèmes de service. Un DNS correct ne remplace pas ces contrôles indépendants.

Dans un exemple fictif, le code 0 avec une adresse et un échec de connexion du navigateur peuvent coexister. Cela n’invalide pas la réponse DNS et n’identifie pas la cause du problème. Le code 0 sans réponse A est également différent d’une requête échouée vers le fournisseur. Ces exemples décrivent des formes possibles de réponse, pas des tests en direct d’example.com ni l’état actuel d’un site. Gardez les données DNS et l’observation réelle de connexion séparées pour enquêter sans confondre les deux.

• Inspecter séparément les déclarations HTTP

Traiter les résultats incomplets et les échecs

Le serveur limite la taille de réponse du fournisseur et conserve au maximum 100 enregistrements. Un avertissement de troncature indique un résultat incomplet : les lignes visibles ne forment pas un inventaire exhaustif. Délai dépassé, données mal formées, service occupé ou endpoint désactivé restent des échecs ou indisponibilités. Notez l’état puis relancez manuellement la même requête. L’outil ne répare pas les registres et ne change pas de résolveur pour masquer un échec. Il n’invente pas d’adresse lorsque le fournisseur ne renvoie rien d’utilisable.

Arrêter et masquer l’onglet annulent la requête du navigateur ; l’annulation reste limitée lorsque le travail atteint le serveur. Réinitialiser efface l’entrée, sélectionne A et retire le résultat. Aucun rafraîchissement automatique ne suit une requête réussie. Modifiez DNS chez le fournisseur responsable en préservant la configuration antérieure. Une seule requête échouée ne justifie pas de supprimer des registres ou de substituer une adresse arbitraire, surtout sans code DNS obtenu pour comprendre ce que le résolveur a réellement répondu.

Comprendre le trajet de la requête

Le nom et le type envoyés atteignent le serveur Savvy Toolkit puis Google Public DNS. La requête utilise un paramètre de sous-réseau client de longueur zéro pour ne pas transmettre cet indice pendant la résolution. Ce n’est pas une garantie d’anonymat ou d’absence de journaux. Le navigateur contacte toujours l’hébergement du site, dont les journaux dépendent des réglages du serveur. Évitez les noms privés et informations confidentielles. La page ne demande pas d’identifiants de compte et ne transmet pas de fichiers locaux de configuration réseau.

Conservez les preuves nécessaires : nom, type, résolveur, heure, code, lignes et avertissement d’incomplétude. Comparez-les avec la configuration attendue ou une observation obtenue indépendamment. DNS, disponibilité HTTP et indexation répondent à des questions distinctes. Séparer ces étapes évite de transformer une requête réussie en affirmation non vérifiée sur le site, ses visiteurs ou sa visibilité dans les moteurs. Le résultat sert à examiner une question précise, avec ses limites de résolution et sans conclusions supplémentaires qui n’ont pas été contrôlées.

Comment interpréter le résultat

Les résultats proviennent d’un seul résolveur public et sont limités. Le DNS local, les vues de zone, la localisation et les caches peuvent produire d’autres réponses. Une réponse réussie vide peut indiquer l’absence du type demandé, pas nécessairement un domaine inexistant. Un délai dépassé ou une réponse invalide signifie requête indisponible. L’outil ne lit pas les réglages DNS de l’appareil.

Questions fréquentes