Propagation & diagnostics

Comparez plusieurs résolveurs et analysez les réponses servies.

Recherche enregistrement TXT

En mode trace itérative, le résolveur est ignoré.
Interroge plusieurs résolveurs publics pour comparer les réponses.

Comment bien utiliser les différentes options du moteur de recherche DNS ?

Qu'est-ce que la trace itérative ?

La trace exécute la résolution pas à pas. Le résolveur interroge d'abord les serveurs de la racine, puis ceux du TLD (.com, .fr, .eu), puis les serveurs autoritaires de la zone cible. À chaque étape, la page affiche le serveur interrogé, la réponse, le RCODE et la latence.

  1. 1. Racine

    Découverte des serveurs du TLD pour le nom demandé.

  2. 2. TLD

    Référence vers les NS de la zone (délégation).

  3. 3. Autoritaires

    Réponse finale (ou erreur) avec TTL et latence.

À quoi ça sert ?

  • Comparer les réponses selon les résolveurs et les régions
  • Détecter un cache chaud, un TTL trop long ou une délégation incomplète
  • Expliquer une différence de latence ou un RCODE inattendu

Astuce : gardez la trace désactivée pour les vérifications rapides ; activez-la quand vous enquêtez ou préparez un ticket/post-mortem.

Qu'est-ce que la trace classique ?

La trace classique interroge uniquement le résolveur sélectionné (UDP ou DoH) et restitue la réponse telle qu'elle est perçue depuis ce point du réseau. Vous obtenez le RCODE, les sections de réponse et la latence du trajet client → résolveur.

  1. 1. Résolveur choisi

    Utilise le preset ou la configuration personnalisée pour lancer la requête exactement comme votre service.

  2. 2. Protocole conservé

    Respecte le transport sélectionné (UDP, TCP ou DoH) afin de reproduire le comportement réel.

  3. 3. Réponse détaillée

    Affiche les sections question, answer, authority/additional quand elles existent, avec TTL et métadonnées utiles.

Pourquoi l'utiliser ?

  • Vérifier la vision d'un résolveur spécifique avant de suspecter la délégation
  • Confirmer les valeurs en cache et l'impact d'un TTL ou d'un flush
  • Documenter une résolution telle qu'un client ou un microservice la voit

Astuce : laissez l'option de trace itérative désactivée quand vous auditez un résolveur donné ; activez-la ensuite pour comparer avec le parcours root → TLD → autoritaire.

Comment fonctionne le test de propagation ?

Le test interroge en parallèle un ensemble de résolveurs publics (Google, Cloudflare, Quad9, OpenDNS, FAI…) et groupe les réponses par contenu et RCODE. Vous visualisez instantanément qui a déjà pris en compte la mise à jour.

  1. 1. Résolveurs multipoints

    Active les presets de propagation pour interroger plusieurs acteurs répartis dans le monde.

  2. 2. Comparaison automatique

    Regroupe les réponses identiques et signale les divergences ou les erreurs propres à un résolveur.

  3. 3. Synthèse exploitable

    Fournit un résumé clair, la liste des résolveurs, leurs latences et l'état de chaque groupe.

Quand l'utiliser ?

  • Suivre la diffusion d'un changement DNS à l'échelle mondiale
  • Identifier les caches encore anciens et décider d'un flush ciblé
  • Partager un état de propagation dans un ticket ou un post-mortem

Astuce : pendant le test de propagation, la sélection de résolveur est figée. Désactivez le mode pour revenir au diagnostic unitaire.

Informations complémentaires sur les enregistrements DNS de type TXT

Un TXT record publie un texte associé à un nom de domaine. Les services s'en servent pour prouver la propriété du domaine configurer la messagerie comme SPF DKIM DMARC ou exposer des informations techniques.
Un TXT record contient un nom un type une valeur et un TTL. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.

Exemple enregistrement DNS de type TXT

NomTypeValeurTTL en secondes
@TXT"v=spf1 ip4:203.0.113.0/24 ~all"3600

Dans cet exemple le nom @ vise la racine du domaine. La valeur contient une règle SPF en texte. Un TTL à 3600 correspond à une heure.

Exemples courants

NomTypeValeurTTL en secondes
selector1._domainkeyTXT"v=DKIM1; k=rsa; p=MII...AB"3600
_dmarcTXT"v=DMARC1; p=quarantine; adkim=s; aspf=s"3600
@TXT"propriete=token12345"300

Ces lignes montrent un sélecteur DKIM une politique DMARC et un jeton de vérification. Le nom visé dépend du service utilisé.

Plusieurs TXT sur le même nom

Il est possible de publier plusieurs TXT records sur une même étiquette. Chaque valeur apparaît dans la réponse. Pour SPF garder une seule entrée par nom et y regrouper les mécanismes. Pour DKIM utiliser un sélecteur différent pour chaque clé.

TTL expliqué en clair

Un TTL court rend un changement visible plus vite. Utile pendant une mise à jour de SPF ou une vérification de domaine.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Adapté à une configuration stable.
Réduire le TTL quelques heures avant la modification puis le remonter après validation.

Bon à savoir
Une valeur TXT peut dépasser 255 octets. Elle est alors découpée en plusieurs chaînes entre guillemets dans la zone. Les résolveurs recollent ces chaînes côté client.

Où utiliser un TXT record

Publier le TXT sur le nom demandé par le service. SPF se met souvent à l'apex. DKIM se publie sur selector._domainkey. DMARC se met sur _dmarc. Les services de vérification donnent un nom précis. Un TXT peut coexister avec A AAAA MX sur le même nom.

À éviter
Avoir deux entrées SPF sur le même nom. Fusionner en une seule valeur.
Oublier les guillemets ou mal échapper les caractères spéciaux.
Publier un DKIM au mauvais sélecteur.

Vérifier en ligne

Un DNS lookup en ligne permet d'entrer un nom de domaine. On obtient la liste des valeurs TXT ainsi que le TTL visible depuis Internet. C'est un premier contrôle utile. Faire ensuite un test local depuis sa machine.

Vérifier sous Windows

Windows fournit nslookup. On peut l'utiliser en mode interactif.

Résolveur local
nslookup
set q=txt
exemple.com
Résolveur précis
nslookup
set q=txt
server 1.1.1.1
exemple.com

La première partie interroge selon la configuration réseau de la machine. La seconde force l'usage d'un résolveur tiers ici celui de Cloudflare.

Vérifier sous Linux et sous Mac

Sur ces systèmes la commande dig est pratique et facile à utiliser.

Résolveur local
dig TXT www.exemple.com
Résolveur précis
dig TXT www.exemple.com @1.1.1.1

Lecture rapide des réponses

Plusieurs lignes indiquent plusieurs valeurs TXT. Lire les préfixes v=spf1 v=DKIM1 v=DMARC1 pour repérer la fonction de chaque entrée.
Un TTL restant élevé peut expliquer un décalage après un changement.
Une valeur vide ou tronquée signale souvent un guillemet manquant ou une coupure mal gérée.

Procédure de migration simple

  1. Noter les valeurs actuelles et le TTL.
  2. Réduire le TTL à 300 voire 60 secondes quelques heures avant la modification.
  3. Préparer la nouvelle valeur. Pour SPF fusionner les mécanismes en une seule ligne.
  4. Publier la nouvelle valeur puis retirer l'ancienne si nécessaire.
  5. Vérifier avec nslookup ou avec la commande dig depuis plusieurs réseaux et remonter le TTL quand tout est stable.

Astuce pratique
Pour DKIM publier une nouvelle clé sur un nouveau sélecteur. Laisser l'ancienne le temps de la transition. Retirer ensuite l'ancienne clé quand tout est validé.

Cas fréquents

SPF pour la réception correcte des courriels

Publier une règle SPF à l'apex avec les adresses et les domaines autorisés. Tester avant la mise en production.

DKIM pour signer les messages

Publier la clé publique au sélecteur fourni par le service de messagerie. Vérifier que la clé est complète.

DMARC pour la politique de domaine

Publier une politique sur _dmarc avec la directive p et les options utiles. Surveiller les rapports si activés.

Vérification de propriété

Publier un jeton TXT temporaire fourni par un service. Le retirer après validation si le service le permet.

Dépannage rapide

  1. Si SPF est signalé invalide vérifier qu'il n'existe qu'une seule entrée SPF au même nom.
  2. Si DKIM échoue vérifier le sélecteur et la clé. Chercher une coupure ou un espace en trop.
  3. Si DMARC n'est pas détecté vérifier le nom _dmarc et la valeur v=DMARC1.
  4. Si la réponse reste ancienne attendre l'expiration du TTL et purger le cache du résolveur local si possible.

En résumé, un enregistrement TXT publie des informations en texte pour un nom de domaine. Il sert aux vérifications aux politiques de messagerie et à d'autres usages techniques. Le TTL règle la durée de cache. Plusieurs TXT peuvent coexister au même nom, mais une seule entrée SPF doit exister. La vérification passe par un outil en ligne puis par nslookup et par dig.
Avec ces repères la gestion reste claire. Les changements se déroulent sans stress. Les services fonctionnent comme prévu.