У моего клиента уже настроена электронная почта от провайдера, но он хотел бы, чтобы их веб-сайт размещался у другого провайдера. В настоящее время у них просто есть запись NS, указывающая на компанию, которая размещает их электронную почту. Я использовал dig, чтобы захватить их две записи MX, иначе у них нет других записей. Они используют Network Solutions в качестве регистратора своих доменов, поэтому мне придется использовать расширенный инструмент DNS Network Solutions, чтобы внести изменения.
Я планировал сделать следующее: 1. Измените NS так, чтобы он указывал на сетевые решения (это требование их расширенного DNS) 2. Убедитесь, что записи MX указывают на старый почтовый хост 3. Добавьте записи A для нового веб-сайта хозяин
Когда я нажимаю кнопку редактирования расширенного DNS на панели управления Network Solutions, появляется следующее сообщение:
"Обратите внимание: когда вы перемещаете серверы имен в сетевые решения, существующие серверы имен больше не будут использоваться. В результате веб-сайты и электронная почта от других поставщиков будут недоступны. потерянный."
Это последнее слово меня немного обеспокоило. Будут ли все предыдущие электронные письма «потеряны» или они говорят, что электронное письмо, отправленное во время перехода, может быть потеряно?
Вопреки тому, что говорит Вубл, формулировка вполне разумная. Случай, который он рассматривает, конечно, довольно очевиден, если немного подумать: кто-то настраивает записи сервера имен, чтобы переключиться с службы хостинга DNS контента другой компании на службу хостинга DNS контента Network Solutions без копирования каких-либо других существующих записей через, и внезапно HTTP и SMTP идут наперекосяк, так как мир в целом больше не знает, куда обращаться за этими услугами.
Да люди иногда не знайте, что необходимо передать базу данных от одного издателя к другому при смене издателя.
И вопреки тому, что говорит космическая охота, все будет не мягкий сбой, если переключить серверы перед копированием базы данных. В отсутствие MX записи ресурсов, клиенты ретрансляции SMTP вернутся к A и AAAA записи ресурсов, согласно RFC 2821 § 5. Их, конечно же, не будет, поскольку вы их тоже не копировали. Клиенты SMTP Relay будут возвращать всю почту в очереди как недоставленную. Мягкие сбои возникают в том случае, если при разрешении DNS-запросов вообще не удается получить ответ, а не в том случае, если разрешение запроса выполнено успешно и дает нулевой ответ.
В том же духе сделайте ты знайте, что нет необходимости менять хостинговые компании DNS, если все что вы хотите сделать (это то, что вы нам сказали.) - это точечный HTTP-сервис в другом месте? Как вы объяснили, то, что вы делаете, кажется совершенно ненужным. У вас есть компания A, предоставляющая почтовый сервис SMTP и сервис DNS контента для клиента, и компания B, предоставляющая сервис HTTP контента. Чтобы сделать услуги компании B известными во всем мире, совсем не обязательно заменять компанию A компанией C - Network Solutions. Просто зайдите в ток поставщика услуг DNS контента и введите необходимые A и AAAA записи ресурсов в базу данных.
Нет, пока записи MX не будут изменены, ваши электронные письма не будут потеряны.
В худшем случае SMTP-сервер, который пытается отправить вам электронное письмо, не сможет какое-то время разрешить записи MX вашего доменного имени, но все, что происходит, - это то, что электронные письма помещаются в очередь на их стороне для повторной попытки позже.
Ваш DNS-провайдер (если вы не пользуетесь пакетными услугами) не имеет никакого контроля над вашими фактическими веб-службами и электронной почтой; формулировка там невероятно тупая. Вы не потеряете данные, хранящиеся на других серверах, изменив свой DNS.
Если новый хост DNS имеет те же записи A, CNAME и MX, что и старый провайдер, крайне маловероятно, что у вас вообще возникнут проблемы с подключением; ваши имена хостов будут преобразовываться в одни и те же IP-адреса до и после распространения вашего изменения. Если вы используете разные записи DNS на 2 хостах DNS, возможно, часть вашего трафика может переходить на неожиданные IP-адреса на время, примерно равное вашему значению TTL; вы должны быть готовы иметь дело с трафиком, продолжающим идти на старые IP-адреса в течение короткого времени.