1 votes

Lorsque l'on pointe vers de nouveaux serveurs DNS, y a-t-il un risque de perdre des courriels même si l'ancien service d'hébergement de courriels est toujours en service ?

Je change d'hébergeur et j'utiliserai les serveurs de messagerie du nouvel hébergeur au lieu de ceux de l'ancien.

J'ai créé toutes les boîtes aux lettres correctement nommées sur le nouveau service, mais je n'ai pas encore coupé les liens avec l'ancien hébergeur. Je m'attends à ce que même si les nouvelles valeurs DNS qui pointent vers les serveurs DNS des nouveaux hôtes et les SOA respectifs \zone avec les nouvelles valeurs MX n'ont pas encore été propagées et un courrier électronique est dirigé vers les serveurs de messagerie des anciens hôtes, conformément aux enregistrements MX de la SOA. \zone que l'ancien hébergeur détient, le courrier électronique sera toujours envoyé à la boîte aux lettres qui se trouve sur les serveurs de messagerie de l'ancien hébergeur. J'essaie donc de confirmer que j'ai bien compris et qu'il est pratiquement impossible pour moi de perdre un courriel puisqu'il atteindra les serveurs de messagerie de l'ancien ou du nouvel hébergeur ?

Est-il également possible de configurer le même compte de messagerie pour vérifier et collecter le courrier de différents serveurs de messagerie en saisissant plusieurs adresses pop3 ? Et si je choisis de conserver les services d'hébergement de messagerie de l'ancien hébergeur comme sauvegarde en spécifiant les enregistrements mx pour lui avec une priorité inférieure dans les enregistrements SOA hébergés par le nouvel hébergeur, est-il possible de faire en sorte que tous les e-mails entrants soient envoyés aux deux serveurs par le démon de messagerie afin d'avoir deux copies ? Ou est-ce que ma seule option est de faire en sorte que le serveur de messagerie primaire fasse suivre les e-mails vers l'ancien serveur de messagerie ?

0 votes

Si vous envisagez de conserver l'ancien fournisseur de messagerie comme sauvegarde, pourquoi ne pas continuer à l'utiliser pour l'hébergement de votre messagerie plutôt que de la déplacer ? Il n'y a aucune raison technique pour laquelle vous devez déplacer votre hébergement de messagerie avec votre hébergement web.

0 votes

@joeqwerty Le(s) nouveau(x) serveur(s) de messagerie sont un peu plus rapides, offrent plus d'espace et quelques options de synchronisation avancées dont je pourrais profiter. Sinon, je pourrais simplement coller les enregistrements MX des anciens serveurs de messagerie avec la plus haute priorité dans le fichier de zone sur les nouveaux serveurs DNS hôtes.

5voto

stew Points 9143

Une fois que le nouveau serveur de messagerie est prêt à accepter le courrier de votre domaine via smtp et à servir le courrier via imap ou pop ou autre, vous devez modifier l'ancien serveur pour qu'il fasse suivre le courrier au nouveau serveur. Faites en sorte que tout cela fonctionne AVANT de modifier les enregistrements MX. Ensuite, peu importe que le courrier arrive sur l'ancien ou le nouveau serveur, puisqu'il finit toujours par arriver sur le nouveau serveur.

Je n'aime pas que les gens utilisent le terme "propagation" pour désigner la plupart des changements de DNS, car je trouve que la plupart des gens sont induits en erreur sur ce qui se passe. En général, les changements DNS sont instantanés, il n'y a pas besoin de propagation. La propagation n'intervient que lorsque vous modifiez les serveurs de noms au niveau du bureau d'enregistrement, et que ces modifications doivent être envoyées à tous les serveurs DNS racine. Il s'agit d'une opération qui prenait plusieurs heures dans un passé (lointain selon les normes Internet), mais qui ne prend plus beaucoup de temps. De nos jours, lorsque les gens parlent de propagation, ils font généralement référence, à tort, aux TTL du DNS.

Lorsqu'un serveur de noms faisant autorité répond à une question DNS (par exemple, quels sont les enregistrements mx pour ce domaine), cette réponse est accompagnée d'un TTL, ce qui signifie "voici votre réponse". Vous pouvez supposer que cette réponse est la bonne pendant X secondes". Donc si vous avez un TTL très long sur vos enregistrements MX, et que vous les changez ensuite. Les personnes qui ont consulté vos enregistrements MX risquent de mettre les résultats en mémoire cache pendant longtemps et donc, après le changement, d'envoyer du courrier au mauvais serveur pendant longtemps. Si vous prévoyez un changement dans les enregistrements DNS. Vous pouvez diminuer le TTL à quelque chose de petit jusqu'à ce que le changement soit effectué.

1 votes

Très bonne réponse. Merci d'avoir expliqué la partie DNS. Je ne peux pas vous dire combien de fois j'ai craqué devant l'expression "propagation DNS". La seule chose que je corrigerais, c'est que les serveurs de noms racine et les serveurs gTLD sont des serveurs différents, qui desservent des portions différentes de l'espace de noms DNS. Les serveurs racine (a.root-servers.net, etc.) ne savent rien des domaines de troisième niveau (google, microsoft, etc.). Les serveurs gTLD (a.gtld-servers.net, etc.) responsables du gTLD spécifique (les domaines de deuxième niveau tels que .com, .net, etc.) sont les serveurs qui obtiendront les enregistrements NS mis à jour pour le domaine du PO.

0 votes

Si j'ai bien compris, il suffit de configurer un simple transfert de courrier, qui ne modifie pas le champ (expéditeur de l'enveloppe), pour transférer le courrier d'un compte de messagerie de l'ancien hôte à celui du nouvel hôte ? Étant donné que les mêmes noms de boîtes aux lettres existent aux deux extrémités, cela ne signifierait-il pas que je fais suivre le même courrier électronique, c'est-à-dire de sameuser@samedomain.com sur l'ancien hôte à sameuser@samedomain.com sur le nouvel hôte (même si le courrier arrive sur le nouvel hôte, sinon il reviendra au point d'origine si les anciens enregistrements n'ont pas expiré ?

0 votes

Je dis qu'il faut faire en sorte que l'ancien serveur agisse comme s'il était un MX secondaire. "Acceptez n'importe quel courrier pour ce domaine, puis marquez votre en-tête Received et déplacez-le vers le MX primaire".

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X