Propagation & diagnostics

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

Recherche enregistrement PTR

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 PTR

Un PTR record associe une adresse IP à un nom d'hôte. On parle de résolution inverse. Les systèmes l'utilisent pour les journaux les contrôles réseau et la messagerie. Pour aller vers une adresse, on s'appuie sur A ou AAAA. Pour revenir vers un nom, on s'appuie sur PTR.
Un PTR record contient un nom un type une cible 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 PTR pour IPv4

NomTypeCibleTTL en secondes
10.113.0.203.in-addr.arpa.PTRmail.exemple.net.3600

Dans cet exemple le nom correspond à l adresse 203.0.113.10 écrite à l envers dans la zone in addr arpa. La cible est le nom d hôte attendu. Un TTL à 3600 correspond à une heure.

Exemple enregistrement DNS de type PTR pour IPv6

NomTypeCibleTTL en secondes
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.PTRhost.exemple.net.3600

Ici le nom reprend chaque chiffre hexadécimal de 2001:db8::10 à l envers dans la zone ip6 arpa. La cible est le nom d hôte attendu.

Cohérence aller et retour

Un bon réglage fait correspondre PTR et A ou AAAA. Le nom renvoyé par PTR doit lui-même résoudre vers l'adresse d'origine. Cette cohérence aide la messagerie et le diagnostic.

TTL expliqué en clair

Un TTL court rend un changement visible plus vite. Pratique lors d'une bascule d'adresse.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Utile pour une configuration stable.
Réduire le TTL quelques heures avant une modification puis le remonter après validation.

Bon à savoir
Une adresse peut publier un seul PTR utile. Multiplier les PTR pour la même adresse crée de l'ambiguïté. Il vaut mieux un nom clair qui résout ensuite en A ou AAAA.

Où utiliser un PTR record

Dans la zone inverse fournie par le titulaire des adresses. Pour IPv4 cela se fait sous in addr arpa. Pour IPv6 cela se fait sous ip6 arpa. Sur des blocs fournis par un opérateur la gestion du PTR se règle souvent dans son tableau de bord.

À éviter
Pointer un PTR vers un nom qui ne possède pas d'enregistrement A ou AAAA.
Laisser une ancienne cible après un changement d'adresse.
Publier un nom générique qui ne reflète pas le service réel.

Vérifier en ligne

Un DNS lookup en ligne permet d'entrer une adresse. Le résultat affiche le nom renvoyé par PTR et 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=ptr
10.113.0.203.in-addr.arpa

Ou simplement

nslookup 203.0.113.10
Résolveur précis
nslookup
set q=ptr
server 1.1.1.1
10.113.0.203.in-addr.arpa

La première méthode suit 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 PTR 10.113.0.203.in-addr.arpa
Résolveur précis
dig PTR 10.113.0.203.in-addr.arpa @1.1.1.1

Pour IPv6 on interroge la forme ip6 arpa du même nom.

Lecture rapide des réponses

Une réponse avec NXDOMAIN indique l'absence de PTR. Ajouter l'entrée dans la zone inverse.
Un nom renvoyé qui ne résout pas en A ou AAAA signale une incohérence. Corriger la zone directe.
Un TTL élevé peut expliquer un décalage après un changement.

Procédure de mise en place simple

  1. Vérifier le contrôle de la zone inverse auprès du fournisseur d accès ou du cloud.
  2. Choisir un nom d hôte clair qui résout en A ou AAAA vers l adresse.
  3. Créer le PTR avec un TTL réduit.
  4. Tester avec nslookup ou avec la commande dig depuis plusieurs réseaux.
  5. Remonter le TTL quand tout est stable.

Astuce pratique
Pour la messagerie faire correspondre l'enregistrement PTR le nom utilisé par le serveur SMTP et l'enregistrement A ou AAAA associé. Cette cohérence améliore la délivrabilité.

Cas fréquents

Serveur de messagerie

Exiger un PTR qui renvoie un nom dédié. Le nom doit résoudre vers l'adresse du serveur.

Plage d'adresses chez un opérateur

Demander la délégation de la zone inverse ou utiliser l'interface prévue pour gérer les PTR.

Machines éphémères en cloud

Automatiser la création et la suppression du PTR à l'arrivée et au départ des instances.

Dépannage rapide

  1. Si un service refuse la connexion vérifier la présence d un PTR et la cohérence avec A ou AAAA.
  2. Si la réponse reste ancienne attendre l expiration du TTL et purger le cache du résolveur local si possible.
  3. Si le fournisseur gère la zone inverse ouvrir un ticket et fournir l adresse et le nom souhaité.

En résumé, un enregistrement PTR fournit le nom associé à une adresse. Il complète les enregistrements A et AAAA. Un TTL adapté et une cohérence aller et retour simplifient les contrôles. 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 s'identifient correctement en résolution inverse.