Reverse DNS check : contrôler le PTR d’une adresse IP

Sommaire

Ce qu’interroge réellement un reverse DNS check

Le DNS traduit un nom en adresse. Le reverse DNS fait le trajet opposé : il part de l'IP et cherche le nom d'hôte déclaré pour elle. La mécanique n'a rien de particulier, c'est une résolution DNS ordinaire sur un nom construit à partir de l'adresse. Pour 203.0.113.42, le résolveur demande 42.113.0.203.in-addr.arpa et attend un enregistrement de type PTR. Les octets sont inversés parce que le DNS lit sa hiérarchie de droite à gauche, du plus général au plus précis, alors qu'une IPv4 s'écrit dans l'autre sens. Le PTR et la zone in-addr.arpa datent de la RFC 1035 (1987).

En IPv6, le principe tient mais la zone s'appelle ip6.arpa (RFC 3596) et l'adresse est découpée en 32 quartets hexadécimaux, un par label, inversés eux aussi. Une adresse comme 2001:db8::1 produit un nom de 32 labels qui se termine par 8.b.d.0.1.0.0.2.ip6.arpa. Personne ne l'écrit à la main, dig s'en charge.

Historiquement, beaucoup de démons résolvaient l'IP entrante pour écrire un nom lisible dans les logs. Cette habitude a reculé pour une raison de latence : Apache livre HostnameLookups sur Off par défaut, et OpenSSH a basculé UseDNS sur no à partir de la version 6.8, une résolution inverse lente pouvant retarder l'ouverture de session de plusieurs secondes. Aujourd'hui, le consommateur principal du PTR reste le courrier électronique.

Adresse IP	Nom interrogé dans le DNS	Réponse attendue
203.0.113.42	42.113.0.203.in-addr.arpa	PTR mail.example.com.
8.8.8.8	8.8.8.8.in-addr.arpa	PTR dns.google.
2001:db8::1	…8.b.d.0.1.0.0.2.ip6.arpa (32 labels)	PTR selon l'opérateur

Les commandes qui font le test

Aucun outil en ligne n'est nécessaire, le client DNS de votre machine suffit. La seule difficulté est de lire la réponse correctement.

Retirez le +short quand rien ne sort. Un status: NXDOMAIN signifie qu'aucun nom n'existe à cet endroit de l'arbre, soit parce que le PTR n'a jamais été créé, soit parce que la zone inverse n'est pas déléguée. Un status: NOERROR accompagné de ANSWER: 0 veut dire autre chose : le nom existe, mais sans enregistrement PTR. Les deux cas se corrigent chez des interlocuteurs différents. Pour trancher, demandez la délégation elle-même avec dig NS 113.0.203.in-addr.arpa : si personne ne répond avec des serveurs de noms, le problème est en amont de vous.

dig -x 203.0.113.42 +short : la forme la plus courte, dig construit lui-même le nom in-addr.arpa
dig PTR 42.113.0.203.in-addr.arpa : la même requête écrite à la main, utile pour voir ce qui part vraiment sur le réseau
host 203.0.113.42 : une ligne de réponse lisible, présent sur la plupart des distributions
nslookup 203.0.113.42 : l'équivalent sous Windows sans rien installer
Resolve-DnsName 203.0.113.42 -Type PTR : la version PowerShell, verbeuse mais scriptable
dig -x 203.0.113.42 @1.1.1.1 : force un résolveur public pour écarter un cache local qui mentirait

FCrDNS : le contrôle que font vraiment les serveurs mail

Un serveur SMTP qui reçoit une connexion ne se contente pas de lire le PTR. Il fait le chemin retour : il résout le nom obtenu et vérifie que ce nom repointe vers l'IP de départ. C'est le forward-confirmed reverse DNS, ou FCrDNS. Si le PTR annonce mail.example.com mais que mail.example.com résout vers une autre adresse, le contrôle échoue et l'expéditeur est traité comme non identifié. Cette vérification porte un nom dans les en-têtes Authentication-Results : iprev, défini par la RFC 8601.

Le symptôme est reconnaissable. Postfix, avec reject_unknown_client_hostname, renvoie 450 4.7.25 Client host rejected: cannot find your hostname. Sa variante plus permissive, reject_unknown_reverse_client_hostname, se contente d'un PTR existant sans exiger la confirmation en sens inverse et produit un message légèrement différent (cannot find your reverse hostname). Reconnaître lequel des deux vous frappe évite de chercher du côté SPF ou DKIM pendant une heure.

Les guides d'expéditeurs de Gmail et d'Outlook.com demandent tous deux un PTR valide sur l'IP émettrice. Attention au PTR générique du type 203-0-113-42.pool.exemple-fai.net : il passe le test technique, il existe, il se résout, mais il annonce une IP de pool grand public. Beaucoup de filtres le notent défavorablement. Un nom de machine cohérent avec le domaine expéditeur vaut mieux qu'un nom hérité de l'hébergeur.

PTR absent ou faux : qui a la main pour le corriger

Voici ce qui bloque le plus souvent. Vous ne pouvez pas créer un PTR dans la zone DNS de votre domaine. La zone in-addr.arpa correspondant à un bloc d'adresses est déléguée par le registre régional au titulaire du bloc, donc à votre opérateur ou à votre hébergeur. Chez un hébergeur, la modification se fait dans le panneau de gestion de l'IP (champ reverse ou rDNS), jamais chez le registrar du domaine. Un ticket au support est parfois la seule voie sur des offres mutualisées.

Si vous détenez vous-même un /24 ou un bloc plus large, vous créez un objet domain: dans la base du RIR pour 113.0.203.in-addr.arpa et vous y déclarez vos serveurs de noms. En dessous du /24, la découpe ne tombe pas sur une frontière d'octet et la délégation classique ne fonctionne plus : la RFC 2317 décrit le contournement, où l'opérateur publie des CNAME vers une sous-zone que vous gérez. Le résultat est peu élégant, c'est la méthode standard.

Après correction, la visibilité dépend des caches. Le point que l'on oublie : une absence de réponse se met en cache elle aussi. La RFC 2308 fait durer la mémorisation d'un NXDOMAIN selon le champ minimum du SOA de la zone, souvent une à trois heures. Si vous avez testé avant de configurer, votre résolveur continuera de vous répondre « rien » bien après que le PTR soit en place. Vérifiez depuis un résolveur qui n'a pas la réponse en mémoire, en enchaînant dig -x IP @1.1.1.1 puis @8.8.8.8.

Reverse DNS check, reverse IP lookup et WHOIS d’IP

Trois requêtes portent des noms voisins et ne répondent pas du tout à la même question. Les confondre fait perdre du temps en diagnostic.

Un reverse DNS check ne vous dira jamais quels sites tournent sur une IP mutualisée. Le PTR est unique en pratique et pointe vers le nom de la machine chez l'hébergeur, pas vers les centaines de domaines qu'elle sert. À l'inverse, un reverse IP lookup ne prouve rien sur la configuration DNS de l'adresse : il restitue ce qu'un crawler tiers a observé, avec du retard et des trous, alors que le PTR se lit en direct dans le DNS. Le WHOIS d'IP, lui, ne descend pas au niveau de la machine : il vous donne l'organisation attributaire du bloc et ses contacts d'abus.

Requête	Ce qu'on obtient	Source de la réponse
Reverse DNS check (PTR)	Le nom d'hôte déclaré pour l'IP	La zone in-addr.arpa du propriétaire du bloc
Reverse IP lookup	La liste supposée des domaines hébergés sur l'IP	Une base tierce issue de crawl, pas le DNS
WHOIS d'IP (RDAP)	L'organisation à qui le bloc est attribué	Le registre régional (RIPE, ARIN, APNIC…)

Un reverse DNS check interroge l'enregistrement PTR associé à une adresse IP pour savoir quel nom d'hôte cette adresse annonce, ce que fait en une ligne la commande dig -x 203.0.113.42 +short. Ce PTR est publié par le propriétaire du bloc d'adresses, pas par le titulaire du domaine, et c'est ce détail qui explique la majorité des vérifications qui reviennent vides.

Questions fréquentes

dig -x me répond NXDOMAIN alors que mon hébergeur affiche bien un nom, pourquoi ?

Deux causes possibles. Soit votre résolveur a mis en cache l'absence de réponse d'un test antérieur, le cache négatif durant ce que fixe le champ minimum du SOA (RFC 2308) : retestez via @1.1.1.1. Soit la zone inverse n'est pas déléguée du tout, et le panneau de l'hébergeur enregistre une valeur qui n'est publiée nulle part. Le test qui départage : dig NS 113.0.203.in-addr.arpa.

Combien de temps un changement de PTR met-il à être visible ?

Le temps du TTL de l'enregistrement, souvent 3600 secondes chez les hébergeurs, plus le délai de propagation interne de l'opérateur qui peut aller de quelques minutes à plusieurs heures selon son automatisation. Si vous aviez testé avant le changement, ajoutez la durée du cache négatif.

Peut-on déclarer plusieurs PTR sur une même adresse IP ?

Le DNS l'autorise techniquement, la RFC 1912 le déconseille. L'ordre des réponses n'est pas garanti et la plupart des vérificateurs ne lisent que la première, ce qui rend le résultat imprévisible d'une requête à l'autre. Un PTR par IP, et le nom choisi doit résoudre vers cette IP.

Un site web a-t-il besoin d’un reverse DNS ?

Pour servir des pages, non : un navigateur ne consulte jamais le PTR. Cela devient nécessaire dès que la machine envoie du courrier, et utile pour la lisibilité des logs et des traceroutes. Sur un serveur mutualisé, le PTR appartient de toute façon à l'hébergeur.

Le reverse DNS a-t-il un effet sur le référencement ?

Aucun élément public ne le décrit comme un facteur de classement, et affirmer le contraire serait inventer. Son usage documenté côté Google est ailleurs : la procédure officielle pour authentifier Googlebot consiste précisément à faire une résolution inverse sur l'IP du robot, puis une résolution directe du nom obtenu pour confirmer qu'il revient à la même adresse.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Qui contrôle l'enregistrement PTR d'une adresse IP publique ?