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

Сколько времени займет изменение записи MX и записи A, если DNS-сервер не изменяется?

Я пытаюсь оценить, реально ли для меня изменить IP-адрес почтового сервера в одночасье или это будет беспорядок, когда люди будут получать свою электронную почту на следующий день. По сути, объект, на котором находится почтовый сервер, будет изменять свой пул IP-адресов, и это вынуждает меня изменить записи A и MX для почтового сервера. Поскольку я не меняю сам DNS-сервер (не перемещаю записи на другой авторитетный сервер), будет ли изменение почти мгновенным или это все равно займет до 48 часов из-за кэширования на разных не авторитетных DNS-серверах, которые, возможно, недавно запрашивали ?

Спасибо за понимание,

M

Каждая запись ресурса DNS кэшируется; перемещается ли сам DNS-сервер или нет, не имеет значения. Как сказал Яхья, продолжительность кэширования записи определяется ее TTL. Перед выполнением смены DNS обычно снижают TTL с его обычного значения (обычно день или больше) до чего-то действительно небольшого, например, 5 минут.

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

Вы уже знаете новый IP-адрес? Если да, то вам повезло! Настроить новый A запись, поддомен для вашего домена, указывающий на новый IP-адрес, а затем добавьте его в качестве дополнительного MX запись; установить приоритет выше на новом, чем на старом MX запись. Сделайте это за пару дней до предполагаемой активации нового IP. После того, как новый IP-адрес станет активным, удалите старый MX запись, оставив новую MX запись. Не забудьте обновить свой SOA серийный номер каждый раз, когда вы вносите правки.

Вот статья об отказе / резервном копировании MX записи: http://www.zytrax.com/books/dns/ch9/mail.html

Самая важная настройка в вашем сенарио - это TTL соответствующих записей DNS.

Чем ниже TTL установлен лучше - вы обычно не доберетесь до "мгновенного" из-за всех DNS-серверов, которые имеют разные способы кэширования, но более низкие TTL установлено, тем лучше будут ваши результаты ...

Изменения в DNS должны происходить относительно мгновенно на ваших официальных серверах. Однако из-за кеширования DNS потребуется некоторое время, чтобы изменения дошли до клиентов. Это будет больше проблемой для постоянных клиентов, чем для случайных. Вы можете обойти это, предварительно указав свои данные.

Различные уже опубликованные ответы охватывают все, о чем вам нужно беспокоиться.

  • Установите TTL на низкое значение. Скажите 1H за несколько дней до изменения. Постарайтесь сделать это хотя бы с текущим TTL перед изменением, лучше было бы 2 раза TTL.
  • Добавьте две новые записи A для почтового сервера, используя старый и новый адреса. Создайте запись MX для каждого из них, дав наивысший приоритет старому адресу сервера. Удалите MX для старого адреса, как только вы перейдете. Установите приоритет обеих этих записей ниже, чем у существующей записи. (Серверы отправки не должны проверять имя, которое использует ваш баннер.
  • Добавьте новую запись A для почтового сервера с его текущим именем. И получите настройку записи PTR для нового адреса. Запись A вернет оба адреса. Это позволит проверке rDNS работать для любого адреса. (Многие принимающие серверы заботятся об этом и могут отклонять сообщения или классифицировать их как спам, если rDNS не работает.)

Теперь вы готовы к переходу на новый адрес. После переключения вы можете выполнить очистку.

  • Удалите записи MX для новых имен и запись A для старого адреса.
  • Подождите несколько часов и удалите записи A для новых имен.

Это должно быть полностью прозрачно для ваших пользователей. Любые проблемы, с которыми вы сталкиваетесь, должны ограничиваться серверами, которые не соответствуют стандартам.

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