Aller au contenu principal

Recherche enregistrement PTR (résolution inverse)

Effectuez une résolution inverse de votre adresse IP

Problème de délivrabilité email ? Vérifiez que votre adresse IP a un enregistrement PTR valide et cohérent avec votre configuration DNS.

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

Résolution inverse

Découvrez quel nom d'hôte est associé à une adresse IP. Essentiel pour la messagerie et les logs réseau.

Multi-résolveur

Comparez les réponses de Google, Cloudflare et Quad9 pour détecter les problèmes de propagation.

Cohérence aller-retour

Vérifiez que le nom retourné par le PTR résout bien vers l'adresse IP d'origine via un enregistrement A/AAAA.

IPv4 et IPv6

Support complet des zones in-addr.arpa (IPv4) et ip6.arpa (IPv6) pour toutes vos adresses.

Gratuit et illimité

Testez autant d'adresses que nécessaire. Aucune inscription requise.

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.

Qu'est-ce qu'un enregistrement PTR ?

Un enregistrement PTR (Pointer) effectue la résolution DNS inverse : il associe une adresse IP à un nom d'hôte. C'est l'opération inverse des enregistrements A (IPv4) et AAAA (IPv6).

Structure d'un enregistrement PTR :

ChampDescriptionExemple
NomAdresse inversée + zone arpa10.113.0.203.in-addr.arpa.
TypeToujours PTRPTR
CibleNom d'hôte associémail.captaindns.com.
TTLDurée de cache en secondes3600

Exemples d'enregistrements PTR

IPv4 (in-addr.arpa)

L'adresse 203.0.113.10 s'écrit inversée :

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.captaindns.com.

IPv6 (ip6.arpa)

L'adresse 2001:db8::10 s'écrit avec chaque nibble hexadécimal inversé :

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  3600  IN  PTR  host.captaindns.com.

Cohérence aller-retour (FCrDNS)

La cohérence Forward-confirmed reverse DNS est essentielle :

  1. PTR : L'IP 203.0.113.10 retourne mail.captaindns.com
  2. A : Le nom mail.captaindns.com résout vers 203.0.113.10

Cette cohérence est exigée par :

  • Les serveurs de messagerie (anti-spam)
  • Les services de sécurité
  • Les systèmes de logs

Règles importantes

Configuration correcte

RègleExplication
Un PTR par IPÉvitez les multiples PTR pour la même adresse
Cohérence FCrDNSLe nom doit résoudre vers l'IP d'origine
Nom significatifUtilisez un nom qui identifie le service

Bonnes pratiques pour les emails

PratiquePourquoi
PTR obligatoireBeaucoup de serveurs rejettent sans PTR
Correspond au HELOLe nom doit correspondre au HELO SMTP
Pas de nom génériqueÉvitez les noms comme host-203-0-113-10.isp.com

Problèmes courants

PTR manquant (NXDOMAIN)

Aucun enregistrement PTR n'existe pour l'adresse.

  1. Contactez votre fournisseur d'adresses IP
  2. Demandez la création du PTR avec le nom souhaité
  3. Vérifiez après propagation

Incohérence FCrDNS

Le nom retourné ne résout pas vers l'IP d'origine.

  1. Vérifiez l'enregistrement A/AAAA du nom
  2. Corrigez si l'IP ne correspond pas
  3. Attendez la propagation

Emails rejetés pour PTR

Les serveurs destinataires rejettent vos emails.

  1. Vérifiez que le PTR existe
  2. Assurez-vous de la cohérence FCrDNS
  3. Faites correspondre le HELO SMTP

Vérification en ligne de commande

Linux/Mac

Résolution inverse simple :

dig -x 203.0.113.10

Ou avec la notation complète :

dig PTR 10.113.0.203.in-addr.arpa

Windows

nslookup 203.0.113.10

Gestion des PTR

Qui gère la zone inverse ?

SituationGestionnaire
Serveur dédiéL'hébergeur (via leur interface ou support)
Cloud (AWS, GCP, Azure)Le fournisseur cloud (via leur console)
Bloc IP propreVous (si vous avez la délégation)
IP résidentielleLe FAI (rarement modifiable)

Outils complémentaires

OutilUtilité
Recherche AVérifier la résolution directe IPv4
Recherche AAAAVérifier la résolution directe IPv6
Test emailVérifier la configuration email complète

Ressources utiles