Définir le reverse DNS sur vos adresses

Où vit l'enregistrement

Chaque adresse routée vers votre instance a un PTR modifiable. Le panneau les liste sous l'instance, une ligne par adresse. L'API expose la même chose :

curl -s https://paragonvps.com/api/v1/instances/<instance-id>/addresses -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[].ptr'

En définir un :

curl -s -X PUT https://paragonvps.com/api/v1/addresses/<address-id>/ptr -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"ptr":"mail.example.com"}'

L'enregistrement direct doit exister d'abord

Un PTR pointant vers un nom sans A ou AAAA correspondant est pire que pas de PTR du tout. Les serveurs de messagerie destinataires lisent l'incohérence comme un signal, et certains refusent la connexion sur la base de cela. Publiez l'enregistrement direct, confirmez qu'il résout, puis définissez le PTR.

dig +short mail.example.com A
dig +short mail.example.com AAAA

Ensuite, vérifiez que la paire concorde dans les deux sens :

dig +short -x <ipv4>
dig +short -x <ipv6>

dig -x assemble le nom in-addr.arpa ou ip6.arpa pour vous, ce qui évite d'inverser trente-deux nibbles à la main et de se tromper sur l'un d'eux.

Propagation

Nos zones faisant autorité prennent en compte un changement en environ une minute. Ce qui prend plus de temps, c'est le cache négatif : tout résolveur qui a demandé le PTR avant que vous ne le définissiez peut conserver la réponse vide aussi longtemps que le minimum SOA, qui sur les zones inverses est d'une heure. Ni l'un ni l'autre ne peut raccourcir cela, et réessayer la requête ne fait que le prouver.

IPv6

Le /64 routé contient plus d'adresses que vous n'en nommerez jamais, et le panneau ne va pas vous offrir un champ de texte pour chacune. Deux approches viables :

• Définissez un PTR sur les adresses individuelles que vous utilisez réellement. La plupart des gens n'en ont besoin que d'un seul, pour l'expéditeur de courrier.
• Demandez que la zone ip6.arpa couvrant votre /64 soit déléguée à vos propres serveurs de noms, après quoi vous générez ce que vous voulez. La délégation est un ticket, prend environ une journée, et nécessite deux serveurs de noms répondant déjà pour la zone.

Spécificités du courrier

Le port 25 sortant est fermé sur les nouveaux comptes. Demandez, dites ce que l'instance envoie et à peu près combien, et nous l'ouvrons. La vérification existe parce que les relais ouverts sont l'une des trois choses que la politique d'utilisation acceptable interdit explicitement.

Une fois ouvert, quatre chaînes doivent concorder : le nom d'hôte d'envoi, le PTR, le nom HELO et ce que votre enregistrement SPF autorise. Rendre le HELO identique au PTR supprime la cause la plus courante de rejet doux.

swaks --to [email protected] --server localhost --helo mail.example.com

Quand cela ne prend pas

Trois causes, dans l'ordre où elles se produisent :

1. L'enregistrement direct est manquant, erroné, ou ne s'est pas encore propagé.
2. L'adresse que vous avez modifiée appartient à une instance différente de celle qui envoie le trafic.
3. Votre démon se lie à une adresse différente dans le /64 que celle sur laquelle vous avez défini le PTR.

La troisième est facile à manquer et facile à vérifier :

ip -brief addr
ss -tlnp

Si l'adresse source dans une connexion sortante n'est pas celle qui porte votre PTR, liez le démon explicitement plutôt que d'espérer que le noyau choisisse l'adresse que vous aviez en tête.