Consultation DNS inverse (PTR) : confirmez le hostname derrière n'importe quelle IP
Le DNS inverse est l'image miroir d'une requête DNS normale. Un lookup forward normal transforme `mail.exemple.fr` en l'IP `85.118.219.232`. Un lookup inverse va dans l'autre sens : vous donnez au DNS l'IP, et il renvoie un enregistrement PTR avec le hostname.
Ça sonne académique jusqu'à ce que vous fassiez tourner un serveur mail. Gmail, Outlook et Yahoo vérifient tous le PTR de chaque IP qui essaie de leur livrer du trafic SMTP. Pas de PTR, ou un PTR qui ne matche pas l'enregistrement forward, ça équivaut à un rejet silencieux ou à un aller simple vers le dossier spam.
Cet outil interroge le PTR via `dns/promises` de Node (le même résolveur que `dig` utilise, pas de proxy DoH entre les deux) puis vérifie le FCrDNS en résolvant les enregistrements A et AAAA de la cible PTR en retour. Vous obtenez une coche verte quand les deux directions s'accordent, un drapeau rouge quand non, et un fix étape par étape quand quelque chose est cassé.
Mode d'emploi
- Entrez une IP : IPv4 simple (`8.8.8.8`) ou IPv6 (`2606:4700:4700::1111`). Pas de port, pas de préfixe CIDR.
- Cliquez sur Vérifier. Le résultat arrive généralement en moins d'une seconde, parfois 2 à 3 secondes pour les adresses IPv6 avec des résolveurs upstream lents.
- Lisez l'enregistrement PTR en haut : c'est le hostname que l'IP prétend être (par exemple `dns.google` pour `8.8.8.8`).
- En dessous, voyez les enregistrements forward A et AAAA de ce hostname. C'est le contrôle de round-trip.
- Badge FCrDNS : Pass vert signifie que le round-trip matche, Fail rouge signifie que le PTR existe mais que les enregistrements forward ne pointent pas vers votre IP.
- Si FCrDNS échoue, lisez l'Action suggérée : elle vous dit exactement quoi demander à votre hébergeur pour corriger.
- Pas de PTR du tout ? Courant pour les FAI résidentiels et les petits plans VPS. La boîte d'action explique comment en demander un.
Quand cet outil est utile
Sept situations typiques où une vérification DNS inverse sauve votre santé mentale :
- Configurer un nouveau serveur mail avant de basculer le DNS pour la prod. Vérifiez que le PTR matche avant d'envoyer le premier message, sinon Gmail routera tout en spam dès le premier jour.
- Déboguer la délivrabilité : les clients se plaignent que vos emails n'arrivent pas. Vous vérifiez l'IP que votre MTA utilise pour le SMTP sortant, vous découvrez que le PTR pointe vers le hostname générique d'hébergement (`ec2-54-203-xxx.compute.amazonaws.com`) au lieu de `mail.votre-domaine.fr`. Le fix c'est un ticket.
- Auditer un relais SMTP tiers : vous payez SendGrid / Mailgun / Postmark pour envoyer pour vous. Vous spot-checkez l'IP émettrice. PTR matche leur domaine mail public, tout va bien.
- Enquêter sur une plainte d'abuse : une ligne de log dit "abus depuis 185.220.101.7". Vous faites un PTR. Le hostname dit nœud de sortie TOR en clair, vous savez à quoi vous avez affaire.
- Vérifier l'host d'un certificat SSL : certains certs auto-signés n'encodent que l'IP serveur. PTR confirme quel hostname est le propriétaire canonique.
- Forensics réseau sur le trafic entrant : une requête frappe votre serveur depuis une IP inconnue. PTR montre `crawl-66-249-66-1.googlebot.com`. Maintenant vous savez que c'est le vrai Googlebot et pas quelqu'un qui spoofe le user agent.
- Confirmer résidentiel vs datacenter : un handshake TLS depuis un "navigateur" vient d'une IP avec PTR `example.linode.com`. Ce n'est pas un navigateur, c'est un script sur un VPS.
Liés : consultation DNS, Quelle est mon IP, consultation info IP / ASN, vérificateur DNS email.