Qu'est-ce que le DNS inverse ? Les enregistrements PTR

Le DNS ordinaire répond à « quelle adresse a ce nom ? ». Le DNS inverse répond à l'inverse : « quel nom correspond à cette adresse ? ». Le type d'enregistrement qui le fournit est PTR, abréviation de pointer (pointeur).

Pourquoi ce n'est pas simplement une recherche à l'envers

Les deux directions sont réellement indépendantes. Les enregistrements directs résident dans la zone de votre domaine, que vous contrôlez. Les enregistrements inverses résident dans une zone spéciale dérivée de l'adresse IP elle-même, et cette zone appartient à celui qui possède le bloc d'adresses.

Address:  93.184.216.34
IPv4 zone: 34.216.184.93.in-addr.arpa

Les octets sont inversés, car le DNS lit la
hiérarchie de droite à gauche : le réseau vient en premier.

IPv6 applique la même idée sous ip6.arpa, chaque chiffre hexadécimal étant inversé individuellement, ce qui produit un nom long mais mécaniquement simple.

Pourquoi les serveurs de messagerie s'y intéressent

Le DNS inverse ne compte sérieusement qu'à un seul endroit : la délivrabilité des e-mails. Lorsque votre serveur se connecte pour livrer un message, le serveur destinataire effectue fréquemment une recherche inverse sur l'adresse qui se connecte, comme premier contrôle de légitimité.

• Aucun enregistrement PTR : un fort signal de spam. Les serveurs de messagerie légitimes en ont presque toujours un ; les machines domestiques compromises n'en ont généralement pas.
• Un PTR générique du fournisseur : quelque chose comme 93-184-216-34.dynamic.isp.net signale l'adresse comme résidentielle ou dynamique, et de nombreux serveurs rejettent d'emblée le courrier venant de telles adresses.
• Un PTR qui ne correspond pas à l'enregistrement direct : cela paraît mal configuré ou usurpé.

dig +short -x 93.184.216.34
# -> mail.example.com.

dig +short mail.example.com
# -> 93.184.216.34   (these must match)

La mise en place

1. 1

   Confirmez que vous avez une adresse dédiée

   Une adresse d'hébergement mutualisé ne peut pas avoir d'enregistrement PTR qui ait un sens pour vous : elle est partagée avec tous les autres qui l'utilisent. Voyez mutualisée ou dédiée.

2. 2

   Créez d'abord l'enregistrement direct

   Ajoutez un enregistrement A pour le nom d'hôte de votre messagerie, par ex. mail.example.com, pointant vers l'adresse. Faites-le avant de demander le PTR pour que la paire corresponde immédiatement.

3. 3

   Demandez le PTR à celui qui possède l'adresse

   Les fournisseurs cloud l'exposent dans leur console : AWS exige une demande d'assistance, DigitalOcean le déduit du nom du droplet, Hetzner et Linode proposent un champ direct. Un hébergeur traditionnel demande généralement un ticket.

4. 4

   Faites correspondre le nom d'hôte au HELO de votre serveur de messagerie

   Votre serveur de messagerie annonce un nom d'hôte lors de la connexion. Ce nom, le PTR et l'enregistrement direct doivent tous concorder. Les écarts entre HELO et PTR constituent eux-mêmes un signal de spam.

5. 5

   Vérifiez les deux directions

   Exécutez les deux commandes ci-dessus et confirmez qu'elles concordent. Envoyez ensuite un message de test à un service qui rapporte les résultats d'authentification.

Là où le DNS inverse n'a pas d'importance

Il est facile de trop investir ici. Le DNS inverse est essentiellement sans objet pour :

• Les sites web. Les navigateurs n'effectuent jamais de recherche inverse. Un PTR manquant n'a aucun effet sur votre site, ni sur le SEO.
• Le courrier envoyé via un fournisseur. Si Google, Microsoft ou SendGrid envoie votre courrier, ce sont leurs serveurs qui se connectent, et leur PTR qui s'applique. Le vôtre est sans objet.
• Les adresses derrière un CDN. Les visiteurs atteignent la périphérie, et le fournisseur contrôle cet enregistrement inverse.

Les recherches inverses comme outil d'investigation

Le DNS inverse est aussi un moyen rapide d'identifier ce qu'est une adresse donnée. Les adresses appartenant à un fournisseur s'inversent presque toujours en un nom d'hôte descriptif :

C'est le moyen le plus rapide de savoir si une adresse que vous avez résolue appartient à un CDN plutôt qu'à un serveur d'origine : voyez pourquoi un CDN masque l'IP d'origine.