Назад | Перейти на главную страницу

Как мне переместить мой веб-сайт на новый сервер, не прерывая электронную почту?

У меня есть корпоративный веб-сайт на сервере, на котором также размещается вся наша электронная почта. Я понятия не имею, насколько старательно все сотрудники выполняли резервное копирование своей электронной почты / оставляли старые сообщения на сервере и т. Д. На самом деле, я бы хотел избежать всех этих хлопот и сохранить старую электронную почту на старом сервере.

Я просто хочу переместить веб-сайт на новый, более надежный сервер, оставив электронную почту работающей на старом сервере.

Как я могу это сделать? Когда я указываю DNS на IP-адрес нового виртуального хоста, после его распространения будет ли отключено электронное письмо на старый сервер? Похоже, так считает администратор старого сервера.

Какое здесь решение, действующее по принципу, что мы хотим НАИМЕНЬШЕ количество изменений / реконфигурации / потери данных для наших сотрудников?

При работе с электронной почтой вам необходимо позаботиться о четырех функциях:

  1. Люди, отправляющие вашим пользователям электронную почту.
  2. Ваши пользователи собирают свою электронную почту.
  3. Ваши пользователи отправляют электронную почту.
  4. Ваш почтовый сервер передает эти письма на серверы других людей.

Каждый из них требует обработки потенциально другой записи DNS.

  1. Ваша запись MX. В настоящее время он должен иметь такое имя, как mail.example.com который, в свою очередь, должен содержать запись A, содержащую IP-адрес, по которому другие люди могут отправлять электронные письма вашим пользователям. Если ваша запись MX example.com вместо того mail.example.com вы, вероятно, захотите изменить его до миграции.

  2. Что ваши пользователи помещают в свой почтовый клиент в качестве сервера POP или IMAP. Это может быть необработанный IP-адрес или ваш основной домен (example.com) или субдомен. Обычно используется что-то вроде pop.example.com, imap.example.com или mail.example.com.

  3. Что ваши пользователи помещают в свой почтовый клиент в качестве SMTP-сервера. Как и в случае с настройками POP и IMAP, это часто субдомен, например smtp.example.com.

  4. Две записи DNS, которые имеют значение для этого, - это ваша запись (и) SPF и ваша запись PTR. Вы не захотите изменять свою запись SPF, кроме, возможно, добавления нового веб-сервера, если он отправляет почту. Некоторые почтовые серверы ожидают, что ваш прямой и обратный DNS совпадут, следовательно, если IP-адрес почтового сервера имеет PTR, указывающий на example.com и example.com теперь преобразуется в новый IP-адрес веб-сервера, некоторые почтовые серверы будут отклонять электронную почту, отправляемую им пользователями.

Что бы я сделал в вашей ситуации:

  1. Создайте mail.example.com, pop.example.com, imap.example.com и smtp.example.com и дайте им все записи A, указывающие на почтовый сервер.
  2. Убедитесь, что каждый пользователь в вашей организации использует некоторую комбинацию этих и только этих поддоменов в своих почтовых клиентах. (Не забывайте смартфоны.)
  3. Убедитесь, что ваши записи MX используют один из этих субдоменов.
  4. Убедитесь, что PTR для IP-адреса вашего почтового сервера является одним из этих поддоменов.
  5. Убедитесь, что у всех этих изменений DNS есть время, чтобы очистить кеши других людей. Это означает ожидание до самого длинного из существующих TTL.
  6. Измените DNS для своего домена, чтобы он указывал на новый веб-сервер.

Ноты:

  • Вы можете изменить www поддомен довольно легко и безопасно, не затрагивая электронную почту. (Если вы не сделали что-то странное, например, www.example.com в почтовых клиентах вашего пользователя.) Вы можете даже остановиться на этом и не беспокоиться ни о каком из вышеперечисленных шагов. Оставьте веб-сервер на почтовом сервере, который ничего не делает, кроме перенаправления 301 на www.example.com.
  • Внесение всех описанных выше изменений, хотя сейчас они потенциально медленные и трудные, позволит вам избежать больших проблем в будущем, потому что все ваши независимые службы теперь указывают на отдельные поддомены, и все ваши пользователи используют согласованную схему именования для поиска этих служб. Будущие изменения будут легкими.
  • Вы можете проверить изменения DNS самостоятельно, отредактировав свой собственный файл hosts. Это позволит вам проверить, могут ли ваши пользователи отправлять и получать электронную почту, и что другие люди могут отправлять вам электронную почту.

Сценарий: электронная почта будет продолжать поступать туда, куда она идет. Веб-сайт переедет на новый сервер.

Измените запись A для веб-сайта (если вы используете запись A для www) или для хост-сервера веб-сайта (если вы используете CNAME для www), чтобы она указывала на IP-адрес нового сервера.

Никаких изменений или обсуждения записи MX не требуется.

Запись MX DNS вашего домена должна указывать на ваш старый сервер после перемещения веб-сайта. Тогда у вас не должно быть перебоев в обслуживании.

Вы должны установить mx-запись для своей электронной почты на старый сервер и настроить запись A на новый сервер вашего веб-сайта. Вот и все. MX сопоставляет доменное имя со списком агентов передачи сообщений для этого домена, а запись A возвращает 32-битный IPv4-адрес, который чаще всего используется для сопоставления имен хостов с IP-адресами хоста.

Все модификации безопасны и не должны влиять на простои какой-либо службы. Вы должны сначала настроить веб-сайт на новом сервере, протестировать его, а затем вносить изменения в DNS. Рекламная запись MX и изменение записи A.

Проверьте свой DNS на наличие записей MX и посмотрите, как они настроены. Если ваш MX настроен на mail.yourdomain.com, посмотрите запись для mail.yourdomain.com. Если это запись A (которая должна быть установлена ​​как IP-адрес вашего текущего сервера), все в порядке, просто не меняйте эту запись при перемещении yourdomain.com и www.yourdomain.com

Если mail.yourcomain.com - это CNAME, указывающее на www.yourdomain.com или yourdomain.com, вам необходимо создать новую запись A, как указано выше.

Если в вашей записи MX указано yourdomain.com или www.yourdomain.com, вам придется создать новую запись A, как указано выше. и измените запись MX на новую.

Если вам нужно внести какие-либо из описанных изменений, вы должны подождать день или два (если ваши TTL не превышают это значение), чтобы убедиться, что любые другие почтовые серверы, на которых ваша текущая информация кэширована, получат новую информацию, прежде чем вы что-то измените.