Guide du vérificateur DNS : enregistrements, TTL et erreurs

Comment effectuer une recherche DNS

Ouvrez le vérificateur DNS et attendez le chargement de sa configuration de connexion. Saisissez un nom comme www.example.com, sélectionnez un type, choisissez un ou deux fournisseurs et les emplacements de requête disponibles. Cliquez sur Vérifier le DNS pour envoyer la demande. Charger la page ou modifier le nom ne lance pas automatiquement une recherche de ses enregistrements.

Avant d’interpréter les valeurs, lisez le fournisseur, l’emplacement, le statut et l’horodatage. Si vous connaissez la valeur nécessaire, saisissez-la dans le champ facultatif et choisissez Correspondance exacte ou Contient. Télécharger le rapport DNS enregistre l’observation actuelle dans dns-results.json ; conservez ce fichier pour comparer un avant et un après.

• Chaque vérification porte sur un nom DNS et un type. Lancez des recherches A et AAAA séparées pour examiner les deux familles d’adresses.
• Par défaut, A, les deux fournisseurs et l’emplacement principal de ToolMellow sont sélectionnés. Les emplacements disponibles proviennent de la configuration actuelle du service.
• Changer le nom, le type, le fournisseur ou l’emplacement efface le résultat précédent. Modifier la valeur attendue ou le mode relance seulement la comparaison locale du résultat actuel.

Choisir le type d’enregistrement DNS selon votre tâche

Les enregistrements DNS répondent à des questions différentes. Une recherche A ne demande pas tous les enregistrements du domaine, et une recherche MX n’envoie pas de courriel de test. Le sélecteur propose neuf types. La comparaison de valeur attendue prend en charge les huit types de recherche directe ci-dessous ; les résultats PTR peuvent être consultés et téléchargés, mais leur comparaison de valeur attendue est indisponible.

RFC 1035 : implémentation DNS et formats des enregistrementsRFC 3596 : extensions DNS pour IPv6RFC 8659 : autorisation des autorités de certification

Saisir le bon nom DNS, y compris les noms TXT et IDN

Utilisez le nom auquel appartient l’enregistrement DNS, sans protocole URL, chemin, adresse électronique ni port. Le domaine racine et son nom www sont des entrées distinctes. Une vérification peut demander un sous-domaine ou un nom commençant par un tiret bas ; une recherche TXT à la racine ne trouve pas automatiquement les TXT de ces autres noms.

Le vérificateur retire les espaces aux extrémités, reconnaît les variantes Unicode de point admises, supprime le point racine final, convertit les noms internationalisés admis en ASCII avec domainToASCII de Node et passe le nom en minuscules. Il exige au moins deux étiquettes, chacune d’au plus 63 caractères ASCII après conversion, avec un total d’au plus 253. Les étiquettes ordinaires acceptent lettres, chiffres et traits d’union intérieurs. Les étiquettes de service admises avec préfixe de tiret bas sont acceptées, mais pas des tirets bas intérieurs arbitraires.

RFC 5891 : noms de domaine internationalisésNode.js : conversion URL domainToASCIIRFC 1035 : implémentation DNS et formats des enregistrementsRFC 6376 : signatures DKIM et recherche de clé par sélecteurRFC 9989 : découverte de politique et alignement DMARC

Distinguer fournisseurs récursifs et serveurs faisant autorité

Un serveur faisant autorité publie les données d’une zone DNS. Un résolveur récursif obtient des réponses pour ses clients et peut réutiliser des informations en cache. Sélectionner Google Public DNS ou Cloudflare choisit le service récursif de cette observation ; cela ne signifie pas qu’il héberge votre zone ou qu’il est le serveur faisant autorité pour votre domaine.

ToolMellow envoie les requêtes depuis son serveur ou une sonde configurée vers les points d’accès HTTPS fixes du fournisseur et lit les réponses JSON. Ce format JSON défini par le fournisseur diffère des messages binaires DNS standardisés pour DNS sur HTTPS. La recherche ne modifie pas les réglages DNS de votre appareil, n’interroge pas un serveur arbitraire saisi par vous et ne retrace pas chaque délégation depuis la racine.

RFC 1034 : noms de domaine, résolution et cacheRFC 8484 : requêtes DNS sur HTTPSGoogle Public DNS : API JSON pour DNS sur HTTPSCloudflare 1.1.1.1 : requêtes DNS sur HTTPS en JSON

Lire ensemble les noms d’enregistrement, TTL et détails de l’observation

Chaque ligne de réponse contient le nom de l’enregistrement, son type, le TTL renvoyé en secondes et des données textuelles. Lisez aussi le nom : une réponse récursive peut contenir une chaîne d’alias et une adresse de la cible. Un CNAME auxiliaire ou un autre type ne remplace pas le type demandé. Déployez Enregistrements d’autorité pour contextualiser une réponse négative ou une indication d’autres serveurs à interroger.

Chaque résultat de fournisseur et d’emplacement indique un horodatage d’observation et une durée. L’horodatage décrit cette requête, pas la dernière modification du DNS par l’administrateur. La durée inclut le parcours de la demande ainsi que HTTP et le traitement ; elle n’est pas une mesure du seul DNS sur votre connexion. Si un échec laisse les enregistrements ou indicateurs absents, considérez ces informations manquantes au lieu d’en inventer les valeurs.

RFC 1035 : implémentation DNS et formats des enregistrementsRFC 2308 : mise en cache négative des requêtes DNS

Interpréter les statuts sans confondre absence et échec

Une réponse négative valide et une demande impossible à terminer nécessitent des suites différentes. Dans ToolMellow, la classification positive NOERROR contient une réponse du type demandé. Les autres réponses DNS réussies sont classées selon leur contexte SOA, CNAME ou NS. Le tableau explique le statut affiché sans assimiler toute réponse vide à un domaine inexistant.

Une réponse tronquée est incomplète même si un fragment contient le texte attendu. L’outil déclare la comparaison non concluante en cas de troncature ou d’échec opérationnel. Un fournisseur peut réussir pendant qu’un autre échoue ; conservez les deux résultats plutôt que de prendre l’échec pour une preuve d’absence de l’enregistrement.

RFC 2308 : mise en cache négative des requêtes DNSGoogle Public DNS : API JSON pour DNS sur HTTPSCloudflare 1.1.1.1 : requêtes DNS sur HTTPS en JSON

Comprendre le TTL après une modification DNS

Le TTL exprime une durée de cache en secondes. Un résolveur récursif peut renvoyer la durée restante d’informations en cache ; deux réponses présentant les mêmes données peuvent donc avoir des TTL différents. Le nombre renvoyé ne compte pas les secondes avant que tous les résolveurs du monde utilisent votre nouvelle valeur.

Les réponses positives, négatives et informations de délégation peuvent avoir des historiques de cache différents. Réduire maintenant le TTL ne raccourcit pas rétroactivement la durée attribuée à une copie déjà en cache. Certains résolveurs peuvent aussi fournir des données périmées selon des politiques de résilience définies. Une nouvelle recherche apporte donc une autre observation, pas la preuve que chaque cache est à jour.

Pour une modification prévue, confirmez le nom et les valeurs avec l’hébergeur DNS, conservez les anciennes et nouvelles observations et répétez les vérifications utiles à des intervalles pertinents. Planifiez la vérification d’après les instructions de changement de l’hébergeur et le contexte du cache antérieur. Une règle générale de 24 ou 48 heures ne décrit pas toutes les modifications DNS.

RFC 2181, section 8 : durée de vieRFC 2308 : mise en cache négative des requêtes DNSRFC 8767 : fournir des données DNS périmées

Pourquoi l’accord entre fournisseurs ne prouve pas une propagation mondiale

Google et Cloudflare peuvent renvoyer des réponses différentes à cause de leurs données en cache ou de leur comportement de résolution. Des réponses faisant autorité et dépendant de l’emplacement peuvent aussi intervenir. Comparez d’abord le même nom normalisé et le même type aux heures enregistrées, puis les statuts, noms, valeurs et TTL. Une différence n’identifie pas automatiquement la bonne réponse.

Une vérification permet de choisir au plus quatre emplacements configurés, mais seuls ceux affichés dans l’interface sont disponibles. Si un seul apparaît, les deux fournisseurs sont interrogés depuis cet emplacement. Une région déclarée n’est pas une géographie confirmée indépendamment si son indicateur de vérification est false. Ne déduisez pas un réseau mondial de sondes du nombre de fournisseurs ou de la limite de sélection.

L’accord établit seulement l’accord entre ces observations. Votre appareil, un autre réseau ou un résolveur d’entreprise privé peuvent voir autre chose, notamment avec des caches locaux ou des vues DNS différentes selon le réseau. Utilisez un service multi-emplacements de portée adaptée ou les diagnostics de votre réseau si ces perspectives supplémentaires sont nécessaires.

RFC 1034 : noms de domaine, résolution et cacheRFC 8767 : fournir des données DNS périmées

Comparer littéralement avec Correspondance exacte ou Contient

La comparaison examine les valeurs d’Answer du type demandé et pris en charge par cette fonction. Correspondance exacte exige que tout le texte renvoyé égale le texte attendu ; Contient exige la présence de la sous-chaîne attendue. Les deux distinguent majuscules et minuscules. Une seule valeur correspondante suffit à marquer ce résultat de fournisseur et d’emplacement comme correspondant, même si d’autres valeurs diffèrent. Cela ne prouve pas que tout l’ensemble des enregistrements égale la configuration prévue.

La comparaison ne retire ni espaces, ni guillemets, ni points finaux, ne normalise pas la représentation IPv6 et n’analyse pas la syntaxe des politiques DNS. Les expressions régulières ne sont pas prises en charge. Le protocole DNS peut comparer des noms sans tenir compte de la casse, tandis que cette comparaison de chaînes la distingue. Pour une égalité littérale, utilisez la présentation renvoyée et examinez les données complètes avant de vous appuyer sur une courte sous-chaîne.

• NXDOMAIN et NODATA sont normalement comparés comme différents en l’absence de valeur demandée ; ce sont des observations négatives valides, pas des échecs de requête.
• Les résultats échoués ou tronqués sont non concluants. La comparaison est aussi indisponible pour un texte attendu vide, dépassant 4096 unités de chaîne JavaScript, ou pour PTR.
• Le texte attendu reste dans cet onglet et le rapport téléchargé. Il n’est pas envoyé avec la requête DNS. Une correspondance textuelle ne prouve ni la validation DNSSEC ni la propriété du domaine.

RFC 4343 : insensibilité des noms DNS à la casse

Lire l’indicateur DNSSEC de données authentifiées avec sa source

L’indication Authentifié reflète le drapeau AD du résolveur récursif sélectionné. Ce résolveur affirme que les données sont authentifiées ; ToolMellow ne vérifie pas indépendamment les signatures DNSSEC ni la chaîne de confiance. Se fier à cette affirmation dépend aussi de la confiance accordée au résolveur et au canal transportant sa réponse.

Non authentifié signifie que le fournisseur n’a pas affirmé AD. Des données non signées peuvent produire ce résultat ; l’indicateur seul ne démontre donc pas un domaine défectueux ou malveillant. SERVFAIL demande également une investigation plutôt qu’un diagnostic DNSSEC automatique. Le vérificateur demande des données de réponse liées à DNSSEC en laissant la vérification activée chez le fournisseur, mais ne réalise ni audit DNSSEC complet ni test de fuite DNS du navigateur.

RFC 4035 : DNSSEC et affirmations de données authentifiéesGoogle Public DNS : API JSON pour DNS sur HTTPSCloudflare 1.1.1.1 : requêtes DNS sur HTTPS en JSON

Vérifier le DNS du site avant l’hébergement et HTTPS

Si un site pointe vers une ancienne destination, vérifiez le nom d’hôte exact utilisé par les visiteurs. Comparez A et AAAA séparément et examinez CNAME pour un alias tel que www. Ne supposez pas que le domaine racine et www ont la même configuration. Comparez le résultat aux enregistrements prévus par votre hébergeur, y compris la cible d’alias nécessaire.

Une valeur DNS apparemment correcte constitue une partie du diagnostic. Les redirections HTTP, le routage d’hôte virtuel, la validité du certificat et les réponses de l’application exigent leurs propres contrôles. CNAME est un alias DNS ; envoyer un visiteur vers une autre URL relève de HTTP. CAA concerne l’autorisation des autorités de certification ; sa présence ne confirme pas que le site actuel fournit un certificat valide.

RFC 1035 : implémentation DNS et formats des enregistrementsRFC 8659 : autorisation des autorités de certification

Rechercher TXT de vérification, SPF, DKIM et DMARC au bon nom

Pour vérifier un domaine, copiez le nom de l’enregistrement depuis les instructions du service et choisissez TXT. Comparez l’enregistrement complet au jeton nécessaire en tenant compte des guillemets et fragments affichés. Trouver le jeton est une observation utile, mais le service demandeur applique sa propre procédure de vérification de propriété.

La politique SPF utilise TXT au domaine de messagerie pertinent. La recherche de clé DKIM emploie un nom propre au sélecteur, comme selector._domainkey.example.com ; obtenez le sélecteur du service de messagerie au lieu de le deviner. Une vérification liée à DMARC commence souvent par TXT à _dmarc.example.com. La découverte moderne de politique DMARC et l’alignement des identifiants comportent d’autres règles qu’une seule observation TXT n’évalue pas.

Les enregistrements MX décrivent le routage des courriels, tandis que ces mécanismes TXT ont des rôles distincts. Le vérificateur ne suit pas tous les include SPF, ne valide pas un message signé, n’évalue pas toute la découverte de politique DMARC, n’analyse pas de rapports DMARC et ne teste pas la livraison. La présence de l’enregistrement ou une correspondance de sous-chaîne ne remplace pas ces contrôles.

RFC 7208, section 3.1 : politiques SPF dans TXTRFC 6376 : signatures DKIM et recherche de clé par sélecteurRFC 9989 : découverte de politique et alignement DMARC

Comprendre la confidentialité et partager un rapport DNS utile

Le nom et le type demandés passent par l’intermédiaire ToolMellow ou la sonde sélectionnée jusqu’au résolveur public choisi. Celui-ci voit l’adresse réseau de la sonde ; ToolMellow ne lui transmet pas les en-têtes d’IP client du visiteur. L’hébergement reçoit toujours les métadonnées habituelles des demandes. HTTPS ne rend pas toute l’activité anonyme et n’établit pas une politique de zéro journalisation ; le nom lui-même peut être sensible.

Le texte attendu est comparé localement et peut figurer comme expectedComparison dans dns-results.json. Avant de partager un rapport, vérifiez son nom demandé, les données renvoyées et le texte attendu, notamment les jetons de vérification. Envoyez l’observation utile au destinataire prévu plutôt que de considérer toute valeur exportée comme publiable.

Pour demander de l’aide, indiquez le nom et type exacts, la configuration prévue, le fournisseur et l’emplacement, l’heure d’observation, le statut, les données Answer et Authority utiles et tout résultat tronqué ou échoué. Le rapport téléchargé est un instantané de la requête ; l’outil ne conserve pas un historique des enregistrements sur le serveur et n’exporte pas toute votre zone DNS.

Examiner progressivement une réponse DNS absente ou inattendue

Commencez par comparer le nom normalisé de l’enregistrement et le type choisi aux instructions de l’hébergeur DNS. Distinguez ensuite une réponse négative d’une demande échouée, examinez les alias et les détails Authority et comparez les deux observations de fournisseur. Si vous utilisez une valeur attendue, vérifiez le texte complet et le mode avant de conclure à une différence de configuration.

Après un changement, conservez un rapport et effectuez volontairement les vérifications suivantes. L’outil ne relance pas automatiquement les recherches et répéter les demandes ne vide pas tous les caches. Utilisez Réessayer la connexion lorsque ce choix apparaît pour un problème de configuration, respectez les avis de limite et soumettez une nouvelle recherche au moment approprié. Annuler arrête le travail client en attente et propage l’annulation en amont, mais ne peut pas retirer une requête déjà envoyée.

Utilisez les outils distincts de recherche IP ou de DNS inverse si vous partez d’une adresse, et les diagnostics DNS locaux de votre système pour examiner le parcours du résolveur de cet appareil. Ce vérificateur ne recense pas tous les sous-domaines, ne propose pas SRV, DS, DNSKEY ou ANY, ne transfère pas une zone et ne vérifie pas la disponibilité chez un registraire. Adaptez le diagnostic à la question avant de donner une portée plus large à une réponse réussie.

Questions fréquentes

Sources et lectures complémentaires

• RFC 1034 : noms de domaine, résolution et cache
• RFC 1035 : implémentation DNS et formats des enregistrements
• RFC 3596 : extensions DNS pour IPv6
• RFC 8659 : autorisation des autorités de certification
• RFC 2181, section 8 : durée de vie
• RFC 2308 : mise en cache négative des requêtes DNS
• RFC 8767 : fournir des données DNS périmées
• RFC 4035 : DNSSEC et affirmations de données authentifiées
• RFC 8484 : requêtes DNS sur HTTPS
• Google Public DNS : API JSON pour DNS sur HTTPS
• Cloudflare 1.1.1.1 : requêtes DNS sur HTTPS en JSON
• RFC 4343 : insensibilité des noms DNS à la casse
• RFC 5891 : noms de domaine internationalisés
• Node.js : conversion URL domainToASCII
• RFC 7208, section 3.1 : politiques SPF dans TXT
• RFC 6376 : signatures DKIM et recherche de clé par sélecteur
• RFC 9989 : découverte de politique et alignement DMARC