mx du nom de domain
Olivier Masson
Cette fois-ci, je me pose la question de l'utilité d'avoir un champ MX
propre au domaine.
J'ai un serveur machine.domain.tld et d'autres domaines qui pointent
dessus. Y'a-t-il un intérêt (ou même est-ce fortement recommandé ?),
*hors certificat SSL*, de crée des enregistrements MX pour chaque domaine ?
Merci.
Mihamina Rakotomandimby
> Cette fois-ci, je me pose la question de l'utilité d'avoir un champ MX
> propre au domaine.
Euh... existe-t-il des champs MX qui "ne sont pas propres au domaine"?
(je demande parceque je ne sais psa, hein)
Et d'apres le peu que je sais, on n'a besoin du champs MX que si on veut
"recevoir des email" sur ce domaine. Si ce n'est pas utile, alors on
peut s'en passer.
--
Huile Essentielle de Camphre http://www.huile-camphre.fr
Infogerance http://www.infogerance.us
(Serveurs, Postes de travail, Développement logiciel)
Monsieur 99
01/07/2008 18:34:34 +0200 :
> Olivier Masson wrote:
>> Cette fois-ci, je me pose la question de l'utilité d'avoir un champ MX
>> propre au domaine.
>
> Euh... existe-t-il des champs MX qui "ne sont pas propres au domaine"?
> (je demande parceque je ne sais psa, hein)
Au sens strict de domaine (sous entendu de premier niveau), les sous
domaines peuvent aussi disposer de champ MX si besoin s'en fait sentir
(ie pour recevoir des mail sur con...@sous.domaine.tld).
> Et d'apres le peu que je sais, on n'a besoin du champs MX que si on veut
> "recevoir des email" sur ce domaine. Si ce n'est pas utile, alors on
> peut s'en passer.
On peut même se passer de MX pour recevoir des mails, si le champ A
corresponds au serveur de mail, puisqu'en l'absence de MX, c'est le
champ A qui est considéré comme serveur de mail.
--
> Faut faire comme moi, PS2 ET GameCube
C'est laquelle qui est sous linux ?
-+- Brina in GFD - "La solution ultime" -+-
Monsieur 99
18:23:32 +0200 :
Si par créer des enregistrement MX pour chaque domaine exprimez le fait
de crée les entrées MX suivantes mail.domaine1.tld, puis
mail.domaine2.tld etc qui pointent toutes vers le même serveur de mail,
c'est à double tranchant.
Dans le cadre d'une migration de l'adresse IP du serveur de mail, vous
allez devoir modifier autant de champ A qu'il y a de domaine.
Le fait d'avoir un champ A vers le serveur de mail et un MX du type
mx.server1.tld commun à tout les domaines permet d'avoir à ne modifier
qu'un champ A dans le cadre d'une migration complète, mais rends plus
complexe la migration vers des serveurs de mails différents.
Aucune solution n'est parfaite, à vous de choisir celle qui convient le
plus à vos besoins.
--
A toi de voir pour l'apellation "champion".
Mais il est vrai qu'on fait partie d'une élite que certains (bouffons)
nous envient. Nous ne pétons pas plus haut que notre cul, nous.
-+- MM in Guide du Freenaute Déchainé - "Gymnastique acrobatique" -+-
Olivier Masson
> Olivier Masson <sis...@laposte.net> a écrit sur son écran le 01/07/2008
> 18:23:32 +0200 :
>> Bonjour,
>>
>> Cette fois-ci, je me pose la question de l'utilité d'avoir un champ MX
>> propre au domaine.
>> J'ai un serveur machine.domain.tld et d'autres domaines qui pointent
>> dessus. Y'a-t-il un intérêt (ou même est-ce fortement recommandé ?),
>> *hors certificat SSL*, de crée des enregistrements MX pour chaque
>> domaine ?
>
> Si par créer des enregistrement MX pour chaque domaine exprimez le fait
> de crée les entrées MX suivantes mail.domaine1.tld, puis
> mail.domaine2.tld etc qui pointent toutes vers le même serveur de mail,
> c'est à double tranchant.
>
Ben non, je parlais de champs de type mx.
Le contexte c'est : un mx, un mx secondaire (finalement j'en ai fait un,
en prenant bien soin de mettre à jour automatiquement les relay_domains,
etc...) pour le domaine "master" (le nom du serveur).
Ensuite, j'ai 5 domaines différents. Dans le fichier de zone, j'ai pour
l'instant mx.master.tld et mx2.master.tld.
Je voulais savoir s'il y avait utilité d'avoir mx.autre_domaine.tld et
mx2.autre_domaine.tld.
Pour les sous-domaines mail. ou autre imap, pop, smtp, je m'en fous, ce
ne sont que des sous-domaines.
> Dans le cadre d'une migration de l'adresse IP du serveur de mail, vous
> allez devoir modifier autant de champ A qu'il y a de domaine.
>
Oui enfin, y'a des trucs qui ne se font pas à la main aussi :)
Stephane Bortzmeyer
> Dans le cadre d'une migration de l'adresse IP du serveur de mail, vous
> allez devoir modifier autant de champ A qu'il y a de domaine.
Si on n'a qu'un ou deux domaines, on fabrique en effet les fichiers de
zone à la main et, en cas de migration, on fait du rechercher/remplacer.
Ceci dit, si on a dix, vingt ou cinquante domaines, on fait fabriquer
les fichiers de zone par un programme (par exemple un prépocesseur comme
M4 ou cpp) et la question ne se pose donc plus.
Cet argument ne me parait donc pas solide du tout.
Stephane Bortzmeyer
> Ensuite, j'ai 5 domaines différents. Dans le fichier de zone, j'ai pour
> l'instant mx.master.tld et mx2.master.tld.
> Je voulais savoir s'il y avait utilité d'avoir mx.autre_domaine.tld et
> mx2.autre_domaine.tld.
Donc, la question, en utilisant les domaines d'exemple officiels du RFC
2606, est :
Soit un domaine example.org. L'enregistrement MX de ce domaine doit-il
pointer vers mx.example.org ? Ou bien est-ce que je peux sans problèmes
le faire pointer vers un serveur dans un autre domaine, comme
mx.example.com ?
Si c'est cela, la réponse est « C'est purement une question de goût »
Olivier Masson
> Soit un domaine example.org. L'enregistrement MX de ce domaine doit-il
> pointer vers mx.example.org ? Ou bien est-ce que je peux sans problèmes
> le faire pointer vers un serveur dans un autre domaine, comme
> mx.example.com ?
>
C'est bien ça.
> Si c'est cela, la réponse est « C'est purement une question de goût »
D'accord. Merci.
Arnaud Launay
> > Dans le cadre d'une migration de l'adresse IP du serveur de mail, vous
> > allez devoir modifier autant de champ A qu'il y a de domaine.
> Si on n'a qu'un ou deux domaines, on fabrique en effet les fichiers de
> zone à la main et, en cas de migration, on fait du rechercher/remplacer.
A condition d'avoir la main sur le domaine en question. Sur les
domaines que nous ne gérons, nous demandons à nos clients de
faire un CNAME vers les services, histoire de ne pas être ennuyés
quand/si on fait une migration.
Arnaud.
--
Perso: http://launay.org/blog/
Hébergement: http://www.nocworld.com/