Lookup reverse DNS : du PTR à l’erreur SMTP

Un lookup reverse DNS traduit une adresse IP en nom d'hôte en interrogeant l'enregistrement PTR de la zone in-addr.arpa (IPv4) ou ip6.arpa (IPv6). La commande dig -x 8.8.8.8 donne la réponse en une ligne, mais seul le titulaire du bloc d'adresses, votre hébergeur dans la plupart des cas, peut créer ou modifier ce PTR.

Ce que fait réellement la requête

Prenez 192.0.2.10. Le résolveur ne parcourt aucune table d'adresses : il retourne les quatre octets, colle in-addr.arpa au bout, et pose une question DNS parfaitement ordinaire, de type PTR, sur le nom 10.2.0.192.in-addr.arpa. La réponse, quand elle existe, est un nom d'hôte. Sur 8.8.8.8 vous obtenez dns.google, sur 1.1.1.1 vous obtenez one.one.one.one.

C'est tout le mécanisme.

Cette zone spéciale vient de la RFC 1035, section 3.5, celle-là même qui décrit le format des messages DNS. Le sens de lecture inversé n'est pas une coquetterie : dans un nom de domaine la partie la plus générique se trouve à droite, dans une adresse IPv4 elle se trouve à gauche. Retourner les octets permet à la délégation de suivre la découpe des blocs, et un /24 correspond alors exactement à une zone.

En IPv6 la découpe se fait par quartet, pas par octet. L'adresse 2001:4860:4860::8888 devient 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa (RFC 3596), soit 32 labels d'un seul caractère. Personne ne tape ça à la main sans se tromper, et c'est justement ce que dig -x fabrique pour vous.

Famille	Suffixe de la zone	Labels avant le suffixe
IPv4	in-addr.arpa	4 octets décimaux, ordre inversé
IPv6	ip6.arpa	32 quartets hexadécimaux, ordre inversé

Les commandes, et la nuance qui compte dans la sortie

dig -x 1.1.1.1 +short renvoie one.one.one.one et rien d'autre. Retirez +short quand vous attendez la prise en compte d'un changement : la sortie complète affiche le TTL restant, donc le temps qu'il reste à patienter avant que le cache lâche l'ancienne valeur.

La sortie qui trompe le plus de monde, c'est l'absence de réponse, parce qu'il y en a deux formes. Un status NXDOMAIN signifie que le nom inversé n'existe pas : très souvent la délégation de la zone reverse n'a jamais été faite par l'opérateur du bloc. Un status NOERROR avec ANSWER: 0 veut dire autre chose : la zone existe bien, elle est servie, mais ce PTR précis n'y a pas été renseigné. Le premier cas se règle chez l'opérateur du réseau, le second dans le panneau d'administration de votre hébergeur.

• dig -x 8.8.8.8 +short : la forme courte, une ligne de réponse
• dig PTR 8.8.8.8.in-addr.arpa : la requête que dig -x construit pour vous, à écrire à la main quand vous doutez du nom généré
• host 1.1.1.1 : une ligne de sortie, disponible par défaut sur la plupart des distributions
• nslookup 8.8.8.8 : l'équivalent sous Windows, sans rien installer
• dig -x 192.0.2.10 @9.9.9.9 : la même question posée à un autre résolveur, pour séparer un cache local d'une zone réellement vide

Vous ne pouvez pas créer votre PTR, et c’est normal

C'est la confusion numéro un.

Vous êtes titulaire de example.com, vous gérez sa zone chez votre registrar, vous y ajoutez des A, des MX, des TXT à volonté. Le PTR de 203.0.113.7, lui, habite dans 7.113.0.203.in-addr.arpa : une zone déléguée par le RIR (RIPE NCC pour l'Europe) au titulaire du bloc d'adresses, c'est-à-dire votre hébergeur ou votre opérateur. Le champ à remplir se trouve donc dans leur interface, pas dans votre zone DNS. Chez OVHcloud, Scaleway ou Hetzner c'est un champ sur la fiche de l'IP ; sur AWS, une demande à passer pour le compte.

Reste le cas des petits blocs. Si on vous alloue un /29, la découpe par octet ne tombe plus juste, et la RFC 2317 décrit le contournement : le titulaire du /24 place un CNAME par adresse vers une zone que vous gérez, et vous reprenez la main sur vos PTR sans qu'il ait à déléguer un octet entier. Les opérateurs professionnels le proposent, les offres grand public rarement.

Un enregistrement A ajouté chez votre registrar ne crée jamais un PTR.

FCrDNS : le test que font vraiment les serveurs de messagerie

N'importe qui peut mettre n'importe quel nom dans le PTR de ses propres adresses. Un PTR annonçant mail.google.com sur une IP quelconque ne coûte rien à fabriquer, donc personne de sérieux ne s'y fie seul. Le contrôle réel s'appelle forward-confirmed reverse DNS : on lit le PTR de l'IP, on résout le nom obtenu en A ou AAAA, et on vérifie que l'adresse de départ figure dans le résultat. Les deux sens doivent concorder.

Concrètement, vous rencontrez ces refus. Gmail répond 550-5.7.25 The IP address sending this message does not have a PTR record setup. Postfix, côté réception, sort un 450 4.7.25 Client host rejected: cannot find your hostname quand reject_unknown_client_hostname est actif dans smtpd_client_restrictions ; sa variante reject_unknown_reverse_client_hostname se contente de l'existence du PTR, sans exiger la concordance.

Le refus tombe à l'ouverture de la connexion SMTP, avant que SPF ou DKIM soient évalués. Vos en-têtes d'authentification peuvent être irréprochables, le message ne sera pas jugé sur eux.

Les règles publiées par Google pour les expéditeurs demandent explicitement un PTR valide sur l'IP d'envoi, avec un nom qui pointe en retour vers cette même IP. Le nom choisi n'a pas besoin de correspondre au domaine de l'expéditeur, contrairement à une idée répandue : c'est la cohérence aller-retour qui est testée, pas la ressemblance avec le From.

Reverse DNS, WHOIS d’IP et WHOIS de domaine : trois réponses distinctes

Le reverse DNS livre une étiquette. Rien de plus, rien de moins : un nom écrit par l'exploitant du bloc, qui peut être descriptif, générique ou faux.

Pour savoir à qui l'espace d'adressage est attribué, il faut interroger la base du RIR en WHOIS ou en RDAP : vous y trouvez l'organisation titulaire, la plage allouée, le contact abuse. Là encore, l'information s'arrête au bloc. Une IP dans un /22 d'hébergeur mutualisé ne dira jamais quel client se cache derrière, et un PTR de la forme 203-0-113-7.rev.exemple-hebergeur.net vous renseigne sur l'exploitant, pas sur l'utilisateur de la machine.

Les noms d'infrastructure contiennent souvent un code de site, gra ou rbx chez OVHcloud par exemple. C'est une convention interne pratique pour un diagnostic rapide, pas une source de géolocalisation à laquelle vous pouvez opposer un chiffre.

Outil	Ce qu'il interroge	Ce qu'il renvoie
dig -x	la zone in-addr.arpa ou ip6.arpa	un nom d'hôte choisi par l'exploitant du bloc
whois ou RDAP sur une IP	la base du RIR (RIPE NCC, ARIN, APNIC...)	l'organisation titulaire du bloc et le contact abuse
whois sur un domaine	le registre du TLD et le registrar	le titulaire du nom, souvent masqué par une protection

Questions fréquentes

dig -x sur mon IP ne renvoie rien, est-ce grave ?

Pour un serveur web ou une API, cela n'a aucune conséquence visible. Pour une machine qui envoie du courrier, c'est bloquant chez la majorité des opérateurs. Regardez le status : NXDOMAIN indique que la zone inversée n'est pas déléguée, il faut passer par l'opérateur du bloc ; NOERROR avec zéro réponse indique que le PTR n'est simplement pas rempli, ce qui se règle dans le panneau de votre hébergeur.

Puis-je créer le PTR dans la zone DNS de mon domaine ?

Non. Le PTR appartient à la zone in-addr.arpa correspondant au bloc d'adresses, déléguée par le RIR au titulaire de ce bloc. Ajouter un enregistrement PTR chez votre registrar produira une entrée qui existe techniquement mais que personne n'ira jamais consulter, puisqu'un résolveur qui inverse une IP interroge in-addr.arpa, pas votre domaine.

Combien de temps avant qu’un nouveau PTR soit visible partout ?

Deux durées se cumulent. Le TTL du nouvel enregistrement, fixé par l'opérateur du bloc, se situe souvent entre 3600 et 86400 secondes. S'y ajoute le cache négatif des résolveurs que vous avez déjà interrogés avant la création : sa durée est bornée par le champ MINIMUM du SOA de la zone reverse, selon la RFC 2308. Tester en boucle depuis la même machine ne fait qu'entretenir la réponse mise en cache ; interrogez un autre résolveur pour vérifier.

Une adresse IP peut-elle avoir plusieurs PTR ?

Le protocole ne l'interdit pas, et certains opérateurs le pratiquent. En revanche l'ordre des réponses n'est pas garanti et beaucoup de vérificateurs ne testent que la première reçue, ce qui rend le résultat imprévisible. Un seul PTR par adresse reste la configuration qui se diagnostique le plus facilement.

Le lookup reverse DNS permet-il d’identifier quelqu’un ?

Il donne le nom que l'exploitant du réseau a attribué à l'adresse, souvent un identifiant machine ou une chaîne générée à partir de l'IP. L'identité de l'organisation titulaire du bloc se lit en WHOIS ou en RDAP, et l'utilisateur final derrière l'adresse n'apparaît dans aucune de ces deux sources publiques.

Testez vos connaissances

À lire aussi

commande dig · cloudflare dns 1 1 1 1 · asn · cache