DNS inverse : qu'est-ce qu'un enregistrement PTR ?

Le DNS ordinaire répond à la question « quelle adresse correspond à ce nom ? ». Le DNS inverse répond à la question opposée : « quel nom correspond à cette adresse ? ». L'enregistrement qui contient la réponse est l'enregistrement PTR. C'est une petite chose qui compte à quelques endroits (la livraison du courrier avant tout), et elle déroute les gens parce qu'elle ne vit pas dans la zone de votre domaine et qu'on ne peut généralement pas la définir depuis son panneau DNS.

Comment fonctionne le DNS inverse

Le DNS ne sait rechercher que des noms : une adresse IP doit donc d'abord être transformée en nom. Pour IPv4, les quatre octets sont inversés et .in-addr.arpa est ajouté :

192.0.2.25   →   25.2.0.192.in-addr.arpa.

L'inversion place la partie la plus significative à droite, comme dans tout nom de domaine, ce qui rend la délégation possible : le responsable de 192.0.2.0/24 gère la zone 2.0.192.in-addr.arpa et peut y publier un enregistrement pour chaque adresse :

25.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

Pour IPv6, l'adresse est écrite en entier, inversée un chiffre hexadécimal (quartet) à la fois, sous ip6.arpa :

2001:db8::25   →
5.2.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.

Vous ne tapez jamais cela à la main ; dig -x construit le nom pour vous :

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short -x 2001:db8::25
mail.example.com.

host 192.0.2.25 et nslookup 192.0.2.25 font la même chose.

Qui contrôle l'enregistrement PTR

L'arbre inverse suit l'allocation des adresses, pas la propriété des domaines. Les registres Internet régionaux (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) délèguent les zones inverses aux organisations qui détiennent des blocs d'adresses (FAI, hébergeurs, fournisseurs cloud), et ce sont elles qui décident comment leurs clients peuvent définir des enregistrements PTR.

Conséquences :

Ajouter un enregistrement PTR dans la zone de example.com ne sert à rien. Personne ne l'y interrogera jamais.
VPS ou serveur dédié : la plupart des fournisseurs proposent un champ « DNS inverse » pour chaque IP dans leur panneau de gestion. Beaucoup exigent que l'enregistrement direct existe d'abord.
Plateformes cloud : en général pris en charge pour les adresses statiques ou réservées, parfois seulement par un appel d'API ou une demande au support, et parfois pas du tout pour le courrier sortant.
Connexion domestique ou de bureau : c'est le FAI qui le définit. Les lignes professionnelles à IP fixe peuvent souvent obtenir un PTR personnalisé sur demande ; les lignes résidentielles, en général, non.
Hébergement mutualisé : l'adresse est partagée par de nombreux sites et le PTR nomme le serveur de l'hébergeur. C'est normal et il n'y a rien à corriger.
Votre propre bloc d'adresses : vous gérez la zone inverse vous-même, ou vous la faites déléguer. Pour les blocs plus petits qu'un /24, où une zone in-addr.arpa entière ne peut pas être déléguée sur une frontière d'octet, les fournisseurs utilisent la technique à base de CNAME de la RFC 2317.

Pour savoir à qui demander, cherchez qui détient l'adresse ; voir comment savoir où un site web est hébergé.

DNS inverse confirmé par le direct

Un enregistrement PTR seul prouve peu de chose, car le responsable de la zone inverse peut y écrire n'importe quel nom, y compris mail.yourbank.example. Ce que les destinataires vérifient réellement, c'est si les deux directions concordent :

IP → PTR → un nom
ce nom → A/AAAA → la même IP

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com A
192.0.2.25

Si la boucle se referme, on parle de DNS inverse confirmé par le direct (forward-confirmed reverse DNS, FCrDNS). Cela montre que la personne qui contrôle l'adresse et celle qui contrôle le nom coopèrent, ce qui est un signal modeste mais réel.

Pourquoi c'est important pour l'e-mail

Les serveurs de réception utilisent le DNS inverse comme critère de filtrage du spam depuis des décennies, parce qu'une machine sans PTR, ou avec un PTR générique comme host-192-0-2-25.dynamic.isp.example, a bien plus de chances d'être un ordinateur domestique infecté qu'un serveur de messagerie. Les grands fournisseurs de boîtes aux lettres indiquent dans leurs consignes aux expéditeurs que les IP d'envoi doivent avoir un DNS direct et inverse valides ; sans cela, attendez-vous à des rejets ou à des reports avec des messages mentionnant « PTR record » ou « reverse DNS ».

Pour un serveur de messagerie, alignez trois noms :

Élément	Devrait être
PTR de l'IP d'envoi	`mail.example.com`
`A`/`AAAA` de `mail.example.com`	l'IP d'envoi
Nom dans la salutation SMTP (`HELO`/`EHLO`)	`mail.example.com`

Le PTR n'a pas à correspondre au domaine de l'adresse From. Un serveur mail.hosting.example peut envoyer pour des centaines de domaines clients ; aligner ceux-là est le rôle de SPF, DKIM et DMARC, expliqués dans MX, SPF, DKIM et DMARC.

Si vous envoyez par un prestataire d'e-mailing ou un service de messagerie hébergé, les IP d'envoi sont les leurs, et le PTR aussi. Vous n'avez rien à configurer.

IPv6 mérite un avertissement particulier : si votre serveur a une adresse IPv6, il la préférera souvent pour le courrier sortant, et les destinataires ont tendance à être plus stricts sur le PTR en IPv6. Définissez le PTR et l'AAAA pour cette adresse aussi, ou faites en sorte que le serveur de messagerie n'envoie qu'en IPv4.

Les autres endroits où vous rencontrez des PTR

traceroute et mtr affichent les noms des routeurs à partir des enregistrements PTR, qui révèlent souvent le réseau et la ville de chaque saut.
Les journaux et les outils de sécurité résolvent les adresses des clients en noms. Traitez ces noms comme des indices ; ils sont contrôlés par l'autre partie.
Les règles d'accès fondées sur le DNS inverse (par exemple « autoriser *.crawler.example ») ne sont sûres que si le logiciel confirme le nom par le direct. C'est ainsi que les moteurs de recherche recommandent de vérifier leurs robots.
Certains serveurs SSH et FTP font une recherche inverse à chaque connexion ; une zone inverse cassée se manifeste par un délai de plusieurs secondes à la connexion (UseDNS dans OpenSSH).

Ce qu'un enregistrement PTR ne vous dit pas

Pas quels sites web tournent là. Une IP peut héberger des milliers de sites ; le PTR est un nom unique choisi par le détenteur de l'adresse. Les services de « reverse IP » qui listent les domaines d'une adresse utilisent leurs propres données collectées, pas les enregistrements PTR.
Pas qui possède le serveur. server42.hosting.example vous indique l'hébergeur. Les données d'enregistrement du bloc d'adresses vous disent la même chose, de façon plus fiable.
Pas où il se trouve. Les codes d'aéroport dans les noms de routeurs sont au mieux des indices.
Rien du tout, très souvent. Beaucoup d'adresses n'ont aucun PTR. Pour un serveur web, c'est sans conséquence.

Le configurer : liste de contrôle

Choisissez un nom d'hôte dans un domaine que vous contrôlez : mail.example.com. Évitez le domaine nu et les noms qui servent déjà à autre chose.
Créez d'abord l'enregistrement direct : mail.example.com A 192.0.2.25 (et AAAA le cas échéant).
Définissez le PTR dans le panneau du fournisseur, ou demandez au fournisseur ou au FAI de le faire, vers exactement ce nom d'hôte.
Configurez le serveur de messagerie pour qu'il se présente sous le même nom (myhostname dans Postfix, par exemple).
Vérifiez les deux directions avec dig, en IPv4 et en IPv6.
Tenez compte du TTL de l'ancien PTR avant de juger le résultat. Le fonctionnement du cache est décrit dans qu'est-ce que le TTL dans le DNS.

Erreurs fréquentes

Créer un enregistrement PTR dans la zone directe et se demander pourquoi rien ne change.
Un PTR pointant vers un nom qui ne se résout pas, ou se résout vers une autre IP.
Plusieurs enregistrements PTR sur une même adresse. C'est permis, mais beaucoup de vérifications n'en prennent qu'un, de façon imprévisible. Utilisez-en exactement un.
Laisser le PTR générique par défaut du fournisseur sur une adresse qui envoie du courrier.
Configurer IPv4 avec soin et oublier que le serveur envoie aussi en IPv6.
Changer l'IP du serveur et ne mettre à jour que l'enregistrement direct.
Lire un PTR comme une preuve d'identité. Sans confirmation par le direct, il ne prouve rien.

Vérifiez avec OrbitProbe

La recherche IP d'OrbitProbe résout un nom d'hôte en adresses IPv4 et IPv6 et montre, pour chaque adresse, le nom DNS inverse avec le système autonome et le propriétaire du réseau. Saisissez le nom d'hôte de votre serveur de messagerie : si le nom inverse affiché pour chaque adresse est le nom d'hôte que vous avez saisi, la boucle est refermée. Si le nom inverse est absent ou générique, le propriétaire du réseau affiché à côté est l'organisation qui peut le changer.