Être (micro)hébergeur nous confronte parfois à des problèmes inhabituels que monsieur Tout-Le-Monde ne rencontrerait pas : pour chaque domaine que j’héberge, j’associe un serveur de courriel. Et depuis que j’ai changé de fournisseur d’accès à Internet (FAI), une partie des courriels envoyés depuis chez moi reviennent avec des erreurs :
host xxx.yy.zz[IP] refused to talk to me: xxx.yy.zz 421 Access temporarily denied. Reason : sender host aaa.bbb.ccc.ddd does not resolve to a valid hostname
ou encore :
host xxx.yy.zz[IP] said: 550 No RDNS entry for aaa.bbb.ccc.ddd (in reply to RCPT TO command)
Passé un moment de surprise – Comment est-il possible que des machines connectées à Internet pour causer librement refusent de se parler ? –, c’est bien la première fois que je fais face à ces erreurs. Et c’est aussi la première fois que je tombe sur un FAI qui m’oblige par la force des choses à me soucier du DNS inverse et son enregistrement associé : le PTR.
Qu’est-ce que le DNS inverse ?
Un DNS (Système de Nommage Dynamique) transforme un nom « humain » de machine en un adresse « machine ». C’est un peut comme si on transformait une adresse « Rue du départ, n° 20, ... » en ses coordonnées géographiques pour qu’un drone puisse s’y rendre en se référant à son GPS. La position géographique – latitude, longitude – est assez indigeste pour l’humain mais aisément exploitable par la machine. Il faut donc traduire le joli nom humain dans un langage compréhensible par une machine.
Il existe aussi l’opération inverse, appelée rDNS (reverse DNS) qui consiste à partir d’une adresse IP pour trouver un nom de machine. C’est notamment le cas pour les serveurs de messagerie. Cette opération a été mise en place à l’origine pour vérifier l’origine d’un message et assurer son authenticité.
Aujourd’hui, le rDNS n'est d'aucune utilité réelle mais est encore utilisé pour valider l’origine d’un message. Ce n’est pas obligatoire, mais ça peut arriver. La plupart du temps, il ne s’agit pas de vérifier si l’adresse correspond au nom de la machine, mais juste vérifier que l’opération rDNS soit définie, quel que soit son résultat.
Ce n’est pas forcément une bonne idée car ça peut poser des problèmes aux petits serveurs de messagerie – la preuve – et il y a d’autres moyens de vérifier plus finement et élégamment l’authenticité d’un message autrement qu’en interrogeant brutalement le rDNS du serveur qui l’envoie, mais c’est ainsi. Certains administrateurs vérifient le rDNS et il faut faire avec, donc trouver une parade pour s’adapter à eux – malheureusement.
La première conséquence directe est donc que lorsque le serveur destinataire a été configuré de façon pointilleuse, il vérifie le DNS inverse du serveur qui envoie les messages afin de déterminer son authenticité et limiter ainsi le spam. Et s’il ne trouve aucune définition, il renvoie un message d’erreur.
Dans mon cas, il ne s’agit pas de spam, mais de courriels professionnels et sérieux. Donc ces rejets sont ennuyeux, d’autant plus que c’est la première fois que je suis confronté à ce problème. D’habitude, tout fonctionne parfaitement, sans aucune configuration particulière.
Qu’est-ce que l’enregistrement PTR ?
L’enregistrement PTR est un enregistrement au niveau du DNS qui définit le DNS inverse de l’adresse IP publique d’une machine, habituellement le serveur de courriel.
Par exemple, pour l’adresse IPv4 A.B.C.D, il s’agit de l’adresse D.C.B.C.A. ou, plus précisément : D.C.B.A.in-appr.arpa.
Il faut donc définir dans le serveur DNS un enregistrement spécifique nommé PTR qui fera la correpsondance DNS inverse.
Gouvernance : Qui doit le gérer ?
Dans le cas présent, ce qui m’occupe, il n’est simplement pas défini. C’est normalement à celui qui attribue l’adresse IP (l’autorité) de définir le DNS inverse.
Pour savoir qui est l'autorité, il suffit d'interroger le DNS lookup (dig -x) de l'IP correspondant au domaine et de chercher la partie AUTHORITY. Il faudra donc demander à cette autorité de créer un PTR dans son serveur DNS pour définir l'opération inverse de la définition du domaine qu'elle a déjà ajoutée. En général, cette autorité est le FAI.
Quel nom de machine indiquer ?
Pour faire sens, ce DNS inverse fait correspondre l’adresse inverse D.C.B.A à une machine ou, plus exactement, à un nom plus lisible pour un humain que sa simple adresse IP – ce qui est le rôle d’un DNS.
Toute la question est de savoir donc à quoi doit correspondre l’adresse inversée. Quel nom de machine indiquer ?
Mon FAI me demande de lui fournir un nom de machine. C’est une solution, cependant le FAI, par essence, fournit un accès à Internet. C’est-à-dire qu’il s’occupe techniquement d’apporter Internet jusqu'à chez moi et de faire en sorte que ça marche. Il n’a pas à se soucier des machines qui tournent chez moi, sur mon réseau local, qu’elles soient connectées à Internet ou pas. Or, là, c’est justement ce qu’il demande : le nom de mon serveur de messagerie.
Habituellement, lorsque je veux gérer la correspondance entre une machine et une adresse IP, c’est de mon ressort et je le fais au niveau de mon fournisseur de domaine, qui est un autre fournisseur mettant à disposition des serveurs DNS pour que j’y définisse des relations IP → machine.
Mais mon fournisseur de domaine ne me permet pas de gérer les enregistrements PTR – sauf pour les domaines qu'il héberge lui-même moyennant contrepartie financière. Et, d’un point de vue technique, je n’ai jamais eu à le gérer non plus. Ça a toujours fonctionné sans aucun souci auparavant.
Lorsque j’analyse une ancienne adresse IP (avec un dig -x), chez un autre FAI, je trouve :
D.C.B.A.in-appr.arpa. PTR A.B.C.D.xxx.xxx.mon.fai.
Bien entendu, A.B.C.D.xxx.xxx.mon.fai n’existe pas forcément et correspond simplement à une autre entrée DNS qui retourne l’adresse IP A.B.C.D quand on l’interroge.
Cette méthode a l’avantage de fonctionner dans tous les cas, indépendamment de mon infrastructure réseau personnelle, sans se soucier du nom des machines qui tournent chez moi. Mais ça oblige le FAI à créer deux autres enregistrements dans son DNS. Un pour le sens IP → A.B.C.D.xxx.xxx.mon.fai, et un PTR pour l'opération inverse.
L'autre possibilité consiste à fournir le nom de la vraie machine qui existe sur mon réseau afin de définir simplement le PTR manquant. Il faut donc fournir le nom DNS de la machire qui gère la messagerie et dont le nom peut être résolu par DNS, c'est-à-dire qu'il doit exister un enregistrement A ou AAAA associé.
Le cas des domaines multiples
Autre problème du PTR nominatif : si je donne le nom d’un serveur de messagerie à mon FAI mais que je gère plusieurs domaines distincts – sur une même adresse IP publique –, quel serveur choisir ? Il n’y a aucune raison que je donne un serveur plutôt qu’un autre. Si je dispose du domaine A et B, et que je fournis le serveur mail.A pour le PTR, dans ce cas, tout message partant du domaine B aura pour résolution inverse mail.A. Si les deux domaines existent et sont virtuellement séparés, je perds alors cette séparation.
Et si je change le nom de la machine, je dois alors prévenir mon FAI que le nom a changé si je ne veux pas avoir des rejets à nouveau.
Fort heureusement, les serveurs de messagerie qui vérifient le rDNS et qu’en plus la réponse corresponde bien au nom de la machine qui a envoyé le message (directive EHLO) sont assez rares. La plupart du temps, le serveur de messagerie vérifie simplement que l’interrogation rDNS renvoie un résultat, indépendamment de son contenu.
Car le PTR a une taille limitée et mettre plusieurs résolutions risque de saturer l’enregistrement. Le plus simple est de n’utiliser qu’une seule résolution, sur le serveur le plus utilisé, ou, dans la plupart des cas, sur une machine dont le nom est résolu en DNS, quelle soit serveur de messagerie ou pas, réelle ou virtuelle. Il est quand même mieux que cette adresse existe réellement pour limiter les problèmes à venir.