Le DNS inverse des adresses IP louées : enregistrements PTR, délégation et courrier

Le DNS inverse associe une adresse IP à un nom, par un enregistrement PTR. Pour la plupart des services, c'est un détail. Pour un serveur de messagerie, non : Google exige que chaque adresse qui envoie vers Gmail ait un enregistrement PTR dont le nom renvoie à la même adresse, et beaucoup d'autres destinataires cherchent la même correspondance. Avec des adresses louées, l'enregistrement se trouve par défaut dans une zone que vous ne contrôlez pas : il vaut donc la peine de savoir qui le configure et comment.

Comment fonctionne le DNS inverse

Une résolution directe transforme un nom en adresse. Une résolution inverse transforme une adresse en nom, en inversant ses quatre nombres sous un domaine spécial : l'enregistrement PTR de 203.0.113.10 se trouve à 10.113.0.203.in-addr.arpa. L'IPv6 fonctionne de la même façon sous ip6.arpa, un chiffre hexadécimal à la fois.

La zone d'un /24, 113.0.203.in-addr.arpa dans cet exemple, est déléguée par le registre aux serveurs de noms indiqués pour elle. Dans la région de service du RIPE NCC, ce sont les lignes nserver d'un objet domain dans la base de données RIPE. Celui qui exploite ces serveurs de noms décide de ce que disent les enregistrements PTR.

dig -x 203.0.113.10 +short

Qui le contrôle pour des adresses louées

Le registre délègue la zone inverse au titulaire du bloc : pour des adresses louées, c'est donc le loueur, pas vous. En pratique, il existe deux arrangements.

• Le loueur crée les enregistrements que vous demandez. Vous envoyez le nom de chaque adresse, le loueur publie les enregistrements PTR. C'est l'arrangement le plus simple, et il suffit à presque tout le monde.
• Le loueur vous délègue la zone. Avec un objet domain pointant vers vos serveurs de noms, vous gérez vous-même les enregistrements PTR. Cela fonctionne pour un /24 entier. Pour une partie plus petite, le loueur peut vous confier uniquement vos adresses avec la délégation sans classe décrite dans la RFC 2317 : des enregistrements CNAME dans sa zone qui pointent vers une zone sur vos serveurs de noms.

Dans les deux cas, demandez avant le début de la location comment se font les modifications et en combien de temps elles apparaissent, car un serveur de messagerie auquel vous ne pouvez pas donner un nom correct est un serveur qui ne délivre pas.

Ce que vérifient les serveurs de messagerie destinataires

Les consignes de Google aux expéditeurs énoncent la règle pour tous les expéditeurs, pas seulement les envois en masse : « The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname » (traduction : « L'adresse IP publique d'un serveur SMTP d'envoi doit avoir un enregistrement PTR correspondant qui se résout en un nom d'hôte »). Ce nom d'hôte doit à son tour avoir un enregistrement A, ou AAAA pour l'IPv6, qui se résout vers la même adresse. C'est le DNS inverse confirmé dans le sens direct : de l'adresse au nom, et du nom à la même adresse. Gmail répond à un enregistrement manquant ou incohérent par une erreur temporaire ou permanente, et applique ses règles plus strictement depuis novembre 2025.

Deux habitudes vont avec. Utilisez le même nom dans le message d'accueil qu'envoie votre serveur de messagerie (HELO ou EHLO), et choisissez des noms qui ressemblent à un serveur plutôt qu'à une plage. Yahoo, qui exige un DNS inverse de chaque expéditeur, demande des enregistrements PTR « meaningful, non-generic » (traduction : « significatifs, non génériques »), et certains filtres traitent un nom comme 203-0-113-10.dynamic.example.net comme le signe d'une connexion domestique.

La mise en place, étape par étape

1. Choisissez un nom par adresse d'envoi, sous un domaine que vous contrôlez : mail1.example.com.
2. Créez l'enregistrement direct : mail1.example.com. A 203.0.113.10.
3. Créez l'enregistrement PTR : 10.113.0.203.in-addr.arpa. PTR mail1.example.com., par votre loueur ou dans votre zone déléguée.
4. Vérifiez les deux sens depuis un réseau extérieur au vôtre :

dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10

1. Faites utiliser le même nom par le serveur de messagerie. Dans Postfix, c'est myhostname = mail1.example.com.

Les erreurs qui empêchent la délivrance

• Un enregistrement PTR sans enregistrement A correspondant. La résolution inverse fonctionne et la vérification directe échoue.
• Deux enregistrements PTR pour une adresse. Les vérifications ne s'accordent pas sur celui qui compte. N'en gardez qu'un.
• Un changement de nom avec un TTL long. Les résolveurs continuent de servir l'ancien nom jusqu'à l'expiration du TTL. Abaissez-le la veille d'un changement planifié.
• L'IPv6 oubliée. Si le serveur envoie en IPv6, son adresse IPv6 a besoin du même traitement sous ip6.arpa, avec un enregistrement AAAA correspondant.
• Une zone déléguée sur des serveurs de noms qui cessent de répondre. Le registre ne vérifie les serveurs de noms qu'au moment de la délégation. S'ils tombent en panne plus tard, toutes les résolutions inverses du bloc échouent avec eux.

La place de RTM Networks

Le DNS inverse fait partie de chaque location sans frais supplémentaires : indiquez-nous le nom de chaque adresse et nous créons les enregistrements PTR (louer de l'IPv4). Si les adresses enverront du courrier, leur réputation compte autant que leurs noms : nous vérifions donc chaque bloc IPv4 que nous louons sur les listes noires avant la livraison et chaque jour tant que vous l'avez (garder un bloc propre).