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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mihamina Rakotomandimby
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) 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)
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)
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)
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
Mihamina Rakotomandimby a écrit sur son écran le 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 ).
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" -+-
Mihamina Rakotomandimby <r12y@infogerance.us> a écrit sur son écran le
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 contact@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" -+-
Mihamina Rakotomandimby a écrit sur son écran le 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 ).
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
Olivier Masson 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.
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 <sisemen@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.
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 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.
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
Monsieur 99 a écrit :
Olivier Masson 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 :)
Monsieur 99 a écrit :
Olivier Masson <sisemen@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 :)
Olivier Masson 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
Monsieur 99 wrote:
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.
Monsieur 99 wrote:
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.
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
Olivier Masson wrote:
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 wrote:
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 »
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
Stephane Bortzmeyer a écrit :
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.
Stephane Bortzmeyer a écrit :
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 »
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
Le Wed, 02 Jul 2008 18:32:50 +0200, Stephane Bortzmeyer écrivit:
> 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.
Le Wed, 02 Jul 2008 18:32:50 +0200, Stephane Bortzmeyer écrivit:
> 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.
Le Wed, 02 Jul 2008 18:32:50 +0200, Stephane Bortzmeyer écrivit:
> 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.
