Configurer le reverse DNS

Le reverse DNS, ou rDNS, est la traduction inverse du DNS habituel : au lieu de donner l’IP d’un nom, il donne le nom d’une IP. Cette page explique à quoi il sert concrètement, comment le définir pour l’adresse de votre VPS CloudFive et comment contrôler qu’il est bien pris en compte. Elle s’adresse surtout à ceux qui envoient du courrier depuis leur serveur, ou qui veulent que leur machine s’annonce proprement.

Deux sens à ne pas confondre

L’enregistrement A fait aller du nom vers l’IP : vps.exemple.fr → 203.0.113.42. Il vit chez votre hébergeur DNS. L’enregistrement PTR fait aller de l’IP vers le nom : 203.0.113.42 → vps.exemple.fr. Il vit chez le propriétaire de l’adresse IP, donc chez CloudFive. C’est pour cela qu’il ne se règle pas dans votre zone DNS.

À quoi sert un reverse DNS

Quatre usages réels, le premier étant de loin le plus important :

• L’envoi de courrier. Presque tous les grands services de messagerie refusent ou classent en indésirable le courrier venant d’une IP sans rDNS, ou dont le rDNS ne correspond pas au nom annoncé par le serveur. C’est la première vérification faite à la réception.
• L’identification de votre machine. Dans les journaux d’un service tiers, vps.exemple.fr est lisible ; une suite de chiffres ne dit rien à personne.
• Les listes de serveurs et les services de voix, dont certains affichent le rDNS plutôt que l’IP.
• La confiance de certains services qui comparent le nom direct et le nom inverse (ce que l’on appelle le Forward-Confirmed reverse DNS) avant d’accepter une connexion.

Le rDNS ne suffit pas pour envoyer du courrier

Un PTR correct est nécessaire, mais loin d’être suffisant. Il vous faudra aussi des enregistrements SPF, DKIM et DMARC dans votre zone (Modifier la zone DNS), et un serveur de messagerie correctement configuré. Avant de vous lancer, demandez au support l’état du port 25 sur votre adresse : il n’est pas ouvert partout, et la réponse change tout votre plan. Pour quelques boîtes aux lettres sur un nom de domaine, l’hébergement web avec ses emails est beaucoup plus simple à faire fonctionner.

Prérequis : l’enregistrement A correspondant

Posez le DNS direct avant de demander le rDNS. Un PTR qui pointe vers un nom qui ne résout pas est, du point de vue de ceux qui vérifient, presque aussi mauvais que pas de PTR du tout.

1. Relevez l’adresse IP exacte de votre VPS sur la fiche du service dans l’espace client (Gérer un service). S’il s’agit d’une IP supplémentaire, prenez bien celle-là.

2. Choisissez le nom que vous voulez voir apparaître. Un sous-domaine d’un domaine qui vous appartient, par exemple vps.exemple.fr ou mail.exemple.fr.

3. Créez l’enregistrement A de ce nom vers l’IP, chez l’hébergeur de votre zone DNS. Si votre domaine est chez CloudFive, suivez Modifier la zone DNS.

4. Attendez que le nom résolve vraiment, puis vérifiez :

   dig +short vps.exemple.fr

   La commande doit renvoyer exactement l’IP de votre VPS. Si elle ne renvoie rien, n’allez pas plus loin : le problème est dans votre zone DNS.

Choisir un nom qui tient dans le temps

Quelques règles qui évitent de refaire le travail dans six mois :

• Utilisez un domaine qui vous appartient. Un nom chez un tiers vous rend dépendant de lui.
• Un nom par IP, et un seul : une adresse n’a qu’un PTR utile.
• Décrivez la fonction, pas le matériel : mail.exemple.fr vieillit mieux que vps-ryzen-3.exemple.fr.
• Évitez les noms génériques qui sentent le serveur jetable, du type serveur1.exemple.fr, surtout pour une IP qui envoie du courrier.

Définir le rDNS depuis l’espace client

Puisque l’adresse IP appartient à CloudFive, c’est CloudFive qui publie le PTR.

1. Connectez-vous à l’espace client sur cloudfive.fr/manager.

2. Ouvrez la fiche du VPS concerné, dans la section qui liste vos services.

3. Cherchez, parmi les informations réseau de la fiche, un champ de reverse DNS (ou rDNS, ou reverse) associé à votre adresse. S’il est présent et modifiable, saisissez-y le nom complet — vps.exemple.fr, sans http:// et sans point final — puis enregistrez.

4. Si ce champ n’existe pas pour votre offre, ouvrez un ticket de support avec ces trois lignes, et rien d’autre :

   Contenu du ticket

   Service concerné : VPS (identifiant de la fiche)
   Adresse IP       : 203.0.113.42
   rDNS souhaité    : vps.exemple.fr

5. Vérifiez vous-même le résultat avec la section suivante, sans attendre une confirmation.

Plusieurs IP, plusieurs demandes

Si vous avez plusieurs adresses, donnez la liste complète dans un seul ticket, sous forme de paires « IP → nom ». Une demande par IP fait trois allers-retours au lieu d’un.

Vérifier la configuration

La vérification se fait depuis votre machine, pas depuis le VPS.

Linux / macOS

dig -x 203.0.113.42 +short
host 203.0.113.42

Windows

nslookup 203.0.113.42
Resolve-DnsName 203.0.113.42 -Type PTR

La réponse attendue est votre nom, avec un point final : vps.exemple.fr. Le point est normal, il marque la racine du DNS.

Pour contrôler la cohérence des deux sens — ce que vérifient les serveurs de messagerie — enchaînez les deux requêtes :

dig -x 203.0.113.42 +short            # doit renvoyer vps.exemple.fr.
dig +short vps.exemple.fr             # doit renvoyer 203.0.113.42

Les deux doivent se répondre. Si l’une des deux désigne autre chose, la configuration n’est pas valide, même si chaque enregistrement existe de son côté.

Note

Pensez aussi au nom que votre serveur annonce de lui-même : hostnamectl set-hostname vps.exemple.fr aligne le nom de la machine sur son rDNS. Pour un serveur de messagerie, le nom annoncé dans sa propre configuration doit également correspondre.

Délai de prise en compte

La publication d’un PTR est rapide, mais sa propagation ne l’est pas toujours.

• Quelques minutes pour que le changement soit publié et visible avec dig.
• Jusqu’à quelques heures pour que les résolveurs qui avaient déjà interrogé votre adresse abandonnent leur réponse en cache. Ce délai dépend du TTL de la zone, pas de vous.
• Plus longtemps pour la réputation d’une IP qui envoyait du courrier sans rDNS : corriger le PTR n’efface pas l’historique, il arrête seulement de l’alimenter.

Pendant cette période, il est normal que deux outils différents ne donnent pas la même réponse. Attendez avant de modifier à nouveau.

Si ça ne marche pas

dig -x ne renvoie rien. Le PTR n’est pas encore publié, ou votre demande n’a pas abouti. Attendez une heure, refaites le test, puis relancez votre ticket en précisant que vous avez déjà vérifié.

dig -x renvoie un nom générique que je n’ai pas choisi. C’est le rDNS par défaut de l’adresse. Il n’est pas cassé, il n’est simplement pas le vôtre : demandez le remplacement.

Le PTR est bon mais mon courrier est toujours rejeté. Lisez le message de rejet, il nomme la cause. Dans l’ordre de fréquence : SPF ou DKIM absent, nom annoncé par le serveur différent du rDNS, port 25 fermé, IP déjà signalée. Le rDNS ne corrige que le deuxième point.

J’ai changé d’IP, ou de VPS. Le PTR suit l’adresse, pas le serveur. Après une migration ou l’ajout d’une IP supplémentaire, tout est à refaire : enregistrement A, puis demande de rDNS sur la nouvelle adresse.

Je veux deux noms sur la même IP. Ce n’est pas comment le rDNS fonctionne : une adresse a un nom inverse. Les noms multiples se gèrent dans le sens direct, avec plusieurs enregistrements A ou CNAME qui pointent vers la même IP. Voir Sous-domaines et redirections.

Mon serveur de jeu affiche encore l’IP. Le rDNS ne change pas ce qu’affiche un client de jeu. Pour cela, c’est un nom de domaine côté direct : Utiliser un nom de domaine personnalisé.