DNS et PTR

Support Debian
#1

Hello,

Tout va bien dans mes zones normales, un dig me renvoi les bonnes infos. Pour une zone, j’ai plusieurs enregistrements DNS.
Dans une zone, j’ai également plusieurs A records, qui ont la même IP. Je fais ça plutôt que de mettre des CNAME partout, car je veux anticiper la migration de services plus tard vers un autre serveur.

Bref, dans mes zones reverse, j’ai déclaré à chaque fois 2 enregistrements NS et autant de PTR qu’il y a de A records dans la zone normale.

Par contre, ce que je ne comprends pas, c’est pourquoi lorsque je fais un dig -x 1.2.3.4 @8.8.8.8, pour la zone dont l’ip correspond à 1.2.3.4, je n’ai toujours que la première IP et non la liste complète de tous les PTR que j’y ai inscrit.

dans la zone normale, en gros j’ai :

mazone.com A 1.2.3.4
service1.mazone.com CNAME mazone.com
service2.mazone.com CNAME mazone.com
atlas.mazone.com A 1.2.3.4
service3.mazone.com CNAME atlas.mazone.com
service4.mazone.com CNAME atlas.mazone.com
ns1.mazone.com CNAME mazone.com
ns2.mazone.com A 1.2.4.5
mazone.com NS ns1.mazone.com
mazone.com NS ns2.mazone.com

et dans le reverse correspondant 1.2.3.4, je déclare mes 2 NS, ainsi que le PTR mazone.com, atlas.mazone.com.

Ce que je ne comprends pas, c’est que lorsque je fais un dig -x 1.2.3.4, seul une réponse est trouvée (c’est d’ailleurs celle qui correspond au reverse IP inscrit côté OVH). Moi je m’attends à ce qu’il me redescende tous les PTR de la zone liés à cette IP.

Ou alors j’ai mal compris un truc ?

#2

Comme il est dit ici: https://serverfault.com/questions/618700/why-multiple-ptr-records-in-dns-is-not-recommended

"
L’enregistrement PTR d’un reverse (par exemple 7.2.0.0.192.in-addr.arpa) doit identifier le nom canonique qui est associé à cette adresse IP.

Les pointeurs de passerelle aux nœuds du réseau et les pointeurs d’hôte normaux aux nœuds d’adresse complète utilisent le PTR RR pour pointer vers les noms de domaine primaires des hôtes correspondants.

Dans: http://tools.ietf.org/html/rfc1035#section-3.5

Cette attente est reflétée dans les logiciels qui font des recherches inverses ; souvent, ces logiciels s’attendent spécifiquement à ce qu’un seul nom leur soit rendu et ils s’attendent à pouvoir utiliser ce nom comme un nom canonique pour cet hôte. S’il y a plusieurs noms, il est courant d’en prendre un au hasard parce qu’ils n’y a absolument aucun moyen de savoir lequel vous auriez préféré pour cette occasion particulière.

Comme on s’attend à ce qu’il y ai un nom canonique associé à une adresse IP et que ce nom soit ce que le PTR devrait indiquer, l’ajout de plusieurs noms n’a généralement pas d’intérêt (rien ne prévoit qu’un enregistrement A/AAAA aléatoire ait un PTR correspondant) mais il a un inconvénient potentiel car il peut provoquer des résultats étranges puisque vous ne pouvez déterminer lequel de vos enregistrements PTR sera utilisé si vous en avez ajouté plusieurs.

Essentiellement, si vous avez plusieurs enregistrements PTR, vous ne faites pas paraître votre hôte plus légitime, mais au contraire, vous courez le risque d’échouer une validation ou de casser quelque chose.

Comme métaphore peut-être un peu extrême, remettre cinq passeports avec votre photo mais avec des noms différents à l’aéroport ne sera probablement pas aussi bien reçu que si vous en remettiez un seul.
"

(Traduit avec l’aide de www.DeepL.com/Translator )

Donc, faut pas…

#3

D’accord, je comprends mieux !

Donc un A record par IP avec tous les CNAME derrière et de l’autre un PTR (par IP évidemment), pas plus, pas moins.

Merci pour l’info !

#4

Forcément. Une zone contient au minimum deux enregistrements : un SOA et un NS. Et si on s’en tient là, elle ne sert pas à grand-chose.

Comme l’a fort justement écrit @mattotop, définir plusieurs reverses pour une même adresse IP est une mauvaise idée. Pour compléter,

Si je comprends bien, il s’agit de l’adresse IP publique d’un serveur dédié hébergé chez OVH ? Or la gestion des reverses DNS d’une plage d’adresses IP est accordée à l’entité à qui cette plage est allouée, ici OVH. A moins qu’OVH t’ait accordé la délégation pour le reverse de cette adresse, ta zone inverse n’est pas prise en compte par le reste du monde. Tu peux éventuellement définir le reverse via l’interface d’administration fournie par OVH, mais c’est OVH qui a la main sur la zone inverse qui est consultée par le reste du monde.

Si tu ajoute l’option +trace à ta commande dig, tu devrais voir que le serveur qui renvoie le PTR est un serveur DNS d’OVH, pas le tien.

#5

Effectivement, c’est bien chez OVH, un VPS publique.

Je comprends mieux maintenant ce qu’il se passe… les zones reverses que j’hébergeais directement sur mes serveurs DNS ne semblaient pas prises en compte. J’avais bien renseigné celles d’OVH, mais il y avait une incompréhension de ma part de ce côté là, car je ne comprenais pas pourquoi je devais renseigner les zones côté OVH et créer aussi les zones reverses de mon côté.

Bon, eh bien là ça devient beaucoup plus clair. Sur mes serveurs DNS, je n’ai donc pas à gérer les reverses, c’est dans l’interface de gestion des IP d’OVH que ça se passe. Well done !

Une dernière question, pour être sûre de faire proprement :

Il faut donc, si on veut être propre avoir une IP séparée pour :

  • Chaque serveur de nom (un NS doit avoir un A record propre, différent du fqdn du serveur)
  • Chaque domaine doit avoir sa propre interface (IP) pour son MX
  • Et si je veux rajouter un A record pour donner un fqdn propre chaque serveur, je dois là aussi lui attribuer une IP.

Donc, pour 5 MX, plus 2 NS, le tout sur 2 serveurs, je devrais avoir 9 IPs en tout.

Et si vraiment je veux pousser plus loin, pour chaque hôte présentée par Nginx, je devrais là aussi avoir une IP (mais je pense qu’ici ce n’est pas non plus indispensable).

Je pense que c’est ça, mais merci de confirmer et une fois encore, merci pour vos explications !

#6

Bah non.
Tu mélanges tout.
Quel que soit le nombre de domaines que tu as à gérer, tu peux très bien définir partout la même paire de NS et de MX sur les 2 mêmes serveurs sur lesquels tu auras installés des services dns couplés en maitre/esclave, et smtp pareil, couplés en primaire/secondaire.

Et ce ne sont pas forcément 4 ips dont tu as besoin, mais 2 ips pour 2 serveurs qui font dns+smtp, pour l’ensemble de tes domaines/zone.

Aprés, tu peux associer des IPs à des noms de machine dans ta zone avec les A/CNAME, mais ça n’a rien à voir avec les MX et NS.

Le minimum pour gèrer autant de zone que tu veux, c’est juste juste 2 serveurs, 2 ips.
[edit:
les 2 IPs doivent être sur des emplacement physiques distincts, si on veut respecter les recommandations officielles]

[reedit:
Alors ça c’est pour la pure configuration de zone, mais je vois que tu parles de NGINX, ce qui n’a rien à voir avec la choucroute non plus.
Pour compléter à propos des besoins d’IP pour nginx:
il n’y a pas forcément besoin d’autres IP pour gèrer tes sites.
Si tu installes ton serveur web sur une des deux machines ou tu as mis dns+smtp, alors, pas besoin de nouvelle IP, tu peux réutiliser la même que celle que tu as donnée pour le NS/MX que tu as mis dessus.
Pas besoin de nouvelle ip, tes sites auraont tous l’IP de ton serveur, la même, et c’est ton service http qui décidera quel site il doit servir, non pas en fonction de l’ip, mais en fonction du nom qu’on a utilisé pour l’atteindre (ce qu’on appelle un “name virtual host”).
]

#7

Pour conclure:
pour tout faire, tu n’as besoin que de 2 IPs, si tu veux respecter les recommandations de redondance dns/smtp, et même une seule, si tu te fous des interruptions de service en cas de panne, et que tu te passe de serveur secondaire.

#8

Je suis d’accord avec toi, on peut effectivement tout faire avec 2 IPs, mais dans mon cas, dans la gestion de mes domaines, j’ai dans certains cas des choses envoyées par des pros et dans l’autre des particuliers.

Donc, si je présente mes 5 domaines avec une IP pour un MX, si plusieurs utilisateurs d’un même domaine se mettent à crasher du spam (malgré le filtre en sortie) à travers la planète, c’est l’IP de mon MX qui va se retrouver bannie un peu partout, résultat des courses, mon seul et unique moyen de communication pour l’ensemble de mes domaines sera muet.

Alors que si je mets un MX (avec son IP) différent pour chaque domaine, si un de mes MX se retrouve ban, les autres peuvent continuer à travailler.
C’est en ce sens que je pense (peut-être encore à tord), qu’il est utile d’avoir un MX propre avec son IP par domaine.
Sorti de ce contexte, oui, rien empêche effectivement de délivrer tout avec un seul MX (c’est d’ailleurs ce qu’il se passe sur l’infra actuelle).

Me concernant, ce que j’essaye de faire, c’est d’être au plus juste avec cette logique (et corrigez moi si je me trompe, je n’essaye pas d’être contrariant mais de bien faire par rapport à mes besoins) et de corriger tout ce qui ne va pas sur https://mxtoolbox.com/domain/ pour chacun de mes domaines.

#9

OK. Je comprends mieux la problématique.
Donc pour le nombre d’IP nécessaires pour ton systéme, quelle que soit la répartition de tes services sur différents serveurs, ça sera le max des besoins entre celui pour le dns et le smtp, en fait, soit avec ton choix de séparer les smtp: autant d’IP que de clients pour l’envoi, mais les dns seront les 2 mêmes ip pour tous.

Alors non, parce que ça ne va pas se passer comme ça:
si tu as une inondation de spam, c’est ton hébergeur qui va couper, et qui va déconnecter ta machine du net (avec toutes ses ips au passage) avant que >son< ip (celle qui spamme lui appartient, même si elle pointe vers ta machine) ne soit cramée.
Pour t’assurer que tout ne se coupe pas en cas de spam, il te faut >un serveur< par smtp, pas juste une ip.

#10

Hello,

Je remonte ce topic parceque je suis en train de me demander si je ne vais pas changer de stratégie par rapport au rdns.

Initialement, sur un seul serveur de mail, je voulais présenter 5 ips. Chaque IP publique de mon serveur correspondant à un enregistrement MX par domaine, typiquement comme ceci :

serveur toto : IP 1 ==> mx.domaine1.org
serveur toto : IP2 ==> mx.domaine2.org
serveur toto : IP3 ==> mx.domaine3.org
etc…

Histoire d’avoir des beaux enregistrements DNS tout propre et qu’à chaque fois qu’un utilisateur configure à la main ses accès au service, il ne se pose pas la question de savoir si il y a un mx global à connaître ou si à chaque fois c’est celui de son domaine.

Ça, ça marche. Le problème, c’est que lors de la résolution reverse, je tombe à chaque fois sur celle de mon FQDN qui correspond au mx de mon premier domaine ! (je précise que côté OVH, les reverses IP pointent bien vers chaque MX).

Donc lorsque je fais des interrogations dans tous les sens sur domaine1.org, ça va bien. Mais dès lors que je fais un reverse de mx.domaine2.org et bien ça tombe assez logiquement sur mx.domaine1.org, puisque c’est ce nom là que j’utilise en FQDN de ma machine !

Du coup, même si avec la conf en l’état j’ai un beau 10/10 à mail-tester, quel que soit le domaine, ça reste que c’est pas très propre et que si je tombe sur un serveur un peu frileux qui qui vérifie le rdns du MX par lequel est envoyé mes mails de domaine2.org et domaine3.org, ça risque de poser problème.

3 solutions s’offrent à moi :

  1. Affecter plusieurs FQDN à une machine ? ça résoudrait mon problème. Mais par définition, il n’y a, sauf erreur, qu’un FQDN par serveur, non ? Sinon, je ne vois pas comment c’est possible.

  2. N’avoir finalement qu’un seul et même mx pour tous les domaines, qui correspondrait au FQDN de mon serveur.

  3. Avoir un vrai serveur de mail (vps ou ce que vous voulez) par domaine, et pour le coup les FQDN de chaque serveurs seront raccords avec les rdns… mais c’est lourd comme solution.

Pour le coup, je pencherais pour la solution N°2, qui me semble la plus simple. En voyez-vous une autre ?

#11

Lors de la résolution inverse de quoi ?

Par définition on ne fait pas une résolution inverse d’un nom de domaine mais d’une adresse IP.
Un exemple concret serait bienvenu pour comprendre de quoi tu parles car ce n’est certainement pas du reverse. Est-ce le nom de domaine annoncé par le MTA dans le dialogue SMTP lorsqu’il communique avec un autre MTA ?

#12

Par exemple, gmail et outlook.
Heureusement que personne ne les utilise.

Ca, tu le fais tous les jours, puisque la même machine (je ne parle pas d’IP) est appelable par mx.domain[1…N].org qui sont des FQDN.
Le truc, c’est que ton postfix, lui, ne peut utiliser qu’un seule de toutes ces adresses pour s’identifier.

Ben oui.
C’est comme ça que tout le monde fait, oui.
Ta problématique d’isoler les domaines de spam pouvait justifier de monter une usine à gaz, comme je le disais plus haut, mais vu que ça pose d’autres problèmes, il me semble que tu as plus intérêt à repasser à cette config plus standard, quitte à limiter le rythme d’envoi par domaine pour avoir le temps de détecter et bloquer les domaines de spam avant que de te faire bouler globalement par ton hébergeur, et que ton ip commence à tomber dans les spamlist.

Pas forcément, vu que ça va être le même déploiement pour tous, au nom de domaine prés.
Mais ce qui risque d’être lourd, c’est le monitoring, et le cout des vps.

#13

Quand je parle de rDNS, c’est la résolution inverse de de l’IP donnée par le MX d’un des 2 domaines n’apparaissant pas dans le FQDN du serveur :

  • IP: 51.83..
  • HELO: mail.domaine1.org
  • rDNS: mail.domaine2.org

Avec ma conf, quand j’envoie un mail depuis domaine2.org, c’est le HELO du premier MX (dont le nom correspond au FQDN du serveur) qui répond, par le fait, le rDNS n’est pas bon. Idem pour domaine3.org & cie.

Du coup, comme le dit @mattotop , j’ai voulu monter une usine à gaz pour pas grand chose finalement.

Je croyais que c’était une bonne pratique d’avoir un mx spécifique à chaque domaine, avec une IP différente.
Je le pense toujours en fait, mais au final, je me rends compte que mettre ça en place, c’est surtout une histoire de moyen, puisque si on veut être vraiment propre, il faut pouvoir être capable, pour chaque domaine, d’offrir :

  • un FQDN (donc un serveur complet…)
  • un A record
  • un MX record
  • un enregistrement reverse, dont l’ip pointe vers le FQDN

Moi aujourd’hui, chacun de mes domaines a un MX dont le résolution inverse sur l’IP pointe non pas sur le FQDN du serveur, mais sur le MX record. Il est là mon problème.

Alors forcément, pour le premier domaine, ça marche bien, puisque le FQDN du serveur est mx.domaine1.org, que le MX est le même et que la reverse IP pointe là dessus.

Mais pour les 2 autres, vu que ça pointe aussi sur les MX propres à chaque domaine, mais que le FQDN est systématiquement mx.domaine1.org, ça ne va plus.

En conclusion, pour le reverse, j’ai commis une erreur : j’ai raisonné résolution reverse IP vers le MX alors que j’aurais dû raisonner résolution revers IP vers le FQDN (en plus vous m’en aviez parlé…).

Ce que je trouve un poil bizarre quand même, c’est d’avoir 10/10 à mail-tester.com avec ma configuration actuelle (avant correction). En plus, il remonte bien l’anomalie, mais on ne “perd pas de points” malgré celle-ci.

#14

Le reverse correspond à l’adresse IP, il est forcément bon. C’est le nom annoncé dans le HELO qui n’est pas bon car ne correspondant pas à l’adresse IP. Soit tu te débrouilles pour que le MTA envoie dans HELO le reverse de l’adresse IP, soit tu fais tourner une instance de MTA par adresse IP et domaine.

#15

Les serveurs ne vérifient pas le PTR du MX mais celui du nom avec le quel le serveur d’envoi s’annonce (EHLO ou HELO). Le serveur peut s’annoncer avec nom complètement différent du MX.

#16

Aaaahh mais du coup, le HELO envoyé, c’est ce qui correspond à la directive $myhostname dans le main.cf de postfix en fait. Je viens de piger, je ne savais pas d’où était extraite cette valeur.

Pour le coup, oui, soit persévérer dans mon usine à gaz et avoir plusieurs instance postfix qui tournent, soit ma solution n°2.

Je dois être cruche, mais du coup, à quoi sert le FQDN là-dedans finalement (à part pleinement qualifier un serveur) ? Si je comprends bien : l’IP qu’on déclare pour notre mx, doit avoir son reverse qui correspond non pas, ni au mx, ni fqdn, mais à la valeur de Myhostname ?

Donc :

J’aurais HELO = rDNS.

Si oui, quid du FQDN ? J’avais lu (peut-être de travers du coup), qu’il fallait impérativement que $myhostname corresponde au FQDN de mon serveur…

#17

Un enregistrement MX sert pour recevoir du courrier, pas en envoyer. Il dit en substance : le courrier adressé à tel domaine doit être délivré à tel hôte.

Lorsqu’on se connecte à un serveur SMTP pour lui délivrer du courrier, celui-ci est susceptible de faire des vérifications avant d’accepter le courrier. Les critères peuvent être plus arbitraires et délirants les uns que les autres, mais parmi ceux qui sont légitimes on peut citer ceux-ci :

  • le reverse DNS de l’adresse IP source pointe vers un nom de domaine qui pointe vers l’adresse IP source
  • le nom de domaine passé dans le HELO/EHLO pointe vers l’adresse IP source
  • existence d’un enregistrement A/AAAA/MX pour le domaine d’expéditeur du mail from

Parfois, mais c’est moins légitime AMA, le nom passé dans le HELO doit correspondre au reverse DNS (nom canonique).

1 J'aime