DNS Inversé

Le DNS classique associe un nom à une adresse : example.com pointe vers 93.184.216.34. Le DNS inversé fait l'inverse : il retrouve un nom à partir d'une adresse, via un enregistrement PTR (pointer). Contrairement aux enregistrements A/AAAA, un PTR ne réside pas dans la zone du domaine concerné : il vit dans une zone inversée spéciale, contrôlée par celui qui détient le bloc d'adresses IP - en pratique l'hébergeur ou le fournisseur d'accès, rarement le propriétaire du site.

Cette séparation a une conséquence directe : on peut configurer tous les enregistrements A que l'on souhaite sur son propre domaine, mais impossible de créer un PTR pour une IP dont on ne contrôle pas la zone inversée. Faire modifier son reverse DNS passe presque toujours par un ticket auprès du fournisseur qui a attribué l'adresse, jamais par une simple édition de zone.

• Un PTR résout IP → nom d'hôte, l'inverse d'un A/AAAA
• Il vit dans la zone in-addr.arpa (IPv4) ou ip6.arpa (IPv6), pas dans la zone du domaine
• La zone est contrôlée par le détenteur du bloc IP - hébergeur ou FAI
• Une IP ne devrait pointer que vers un seul nom canonique en pratique, même si le protocole autorise plusieurs enregistrements

La RFC 1035 définit ce mécanisme de résolution inversée via un domaine spécial, in-addr.arpa, construit en inversant les octets d'une adresse IPv4 et en ajoutant ce suffixe. L'adresse 8.8.8.8 devient ainsi le nom interrogé 8.8.8.8.in-addr.arpa. Cette inversion suit la logique de délégation du DNS, qui place le label le plus significatif en fin de nom : en inversant les octets, la partie la plus générale de l'adresse (le premier octet) se retrouve à la fin, cohérente avec la délégation de droite à gauche des noms de domaine.

L'IPv6 reprend le même principe sous ip6.arpa (RFC 3596), mais au niveau du quartet hexadécimal plutôt que de l'octet. Chaque chiffre hexadécimal de l'adresse 128 bits est inversé et séparé par des points. L'adresse 2001:4860:4860::8888, une fois développée sous sa forme complète à 32 quartets puis inversée, donne un nom nettement plus long que son équivalent IPv4 - une des raisons pour lesquelles les zones PTR IPv6 sont presque toujours gérées par automatisation plutôt qu'à la main.

Cet outil interroge l'enregistrement PTR de l'IP saisie et affiche le nom d'hôte résolu, avec le temps de requête et l'horodatage. Un résultat positif renvoie une ou plusieurs valeurs PTR - les noms d'hôte enregistrés pour cette adresse dans la zone inversée. Un résultat vide signifie simplement qu'aucun PTR n'est configuré pour cette IP, ce qui reste courant et n'est pas un problème en soi : de nombreux serveurs légitimes n'ont aucun reverse DNS configuré.

Les plages IP privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 et leurs équivalents IPv6) sont bloquées à la recherche, car elles n'ont pas de zone inversée publique pertinente et leur interrogation ne révélerait rien d'utile. Si la saisie n'est ni une IPv4 ni une IPv6 valide, l'outil rejette la requête avant même d'interroger le DNS, plutôt que de renvoyer un résultat vide trompeur.

Le reverse DNS pèse surtout dans la remise des emails. La plupart des serveurs de messagerie, y compris les grands fournisseurs comme Orange, Gmail ou Outlook, effectuent une recherche PTR sur l'IP qui se connecte pendant l'échange SMTP, et considèrent un reverse DNS absent ou incohérent comme un signal fort de spam. Un serveur qui envoie depuis une IP sans PTR, ou dont le PTR pointe vers un nom générique attribué automatiquement par l'hébergeur, a beaucoup plus de chances d'être mis en greylisting, limité en débit, ou rejeté purement et simplement - indépendamment de ce que disent les enregistrements SPF ou DKIM du domaine expéditeur.

La règle pratique pour qui gère une infrastructure d'envoi de mails : configurer un PTR sur l'IP d'envoi avant tout envoi en volume, et s'assurer qu'il pointe vers un nom d'hôte cohérent avec le domaine ou l'organisation expéditrice, pas vers un nom générique attribué par défaut par l'hébergeur.

La vérification FCrDNS, parfois appelée "full-circle" ou méthode "iprev", va plus loin qu'une simple recherche PTR. Le serveur destinataire part de l'IP, résout son PTR pour obtenir un nom d'hôte, puis résout ce nom d'hôte en sens direct (A ou AAAA) pour vérifier que le résultat contient bien l'IP d'origine. Si c'est le cas, les enregistrements direct et inversé concordent, et l'IP est considérée comme ayant une identité vérifiée et cohérente - un signal nettement plus solide qu'un simple PTR, puisque ce dernier peut être configuré à n'importe quelle valeur par celui qui contrôle la zone inversée.

Le FCrDNS ne remplace ni SPF, ni DKIM, ni DMARC, mais de nombreux systèmes de messagerie l'intègrent dans leur scoring de réputation global. La RFC 8601 formalise cette vérification sous le nom de méthode "iprev", rapportée dans les en-têtes Authentication-Results aux côtés des résultats SPF et DKIM. Une discordance ne garantit pas qu'il s'agit de spam, mais une concordance cohérente est un indice de plus que l'infrastructure d'envoi est bien ce qu'elle prétend être.