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

13

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

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

M

domain-name-system

— Недели манки
источник

31

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

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

— ombble
источник

15

+1 «Люди, управляющие этими системами, должны погибнуть в огне, и если я когда-нибудь меня изберут Великим Повелителем Интернета, они будут», - вы получили мой голос.

— Крис С

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

— Manca Weeks

@womble: К сожалению, спамеры используют fast flux DNS для перемещения своих серверов и предотвращения обнаружения. До тех пор, пока администраторы DNS не устанавливают необоснованно длительное время для своего минимального TTL, я поддерживаю их действия, чтобы победить эти незаконные операции. Тем не менее, это делает переходы более сложными.

— BillThor

Идиоты переопределяют TTL намного дольше, чем спаммеры используют fast-flux, и переопределение TTL, очевидно, не работает, потому что спаммеры все еще делают это. TTL не место для борьбы со спамом. Они все еще идут в огонь.

— womble

Точно, побочный эффект состоит в том, что изменения DNS могут занять буквально до 24 часов для полного распространения. Это больно, когда у вас есть проблема с локализованным сетевым подключением и вы хотите применить быстрое решение для перенаправления трафика на резервную линию / средство.

— Хьюберт Карио

7

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

Вот статья, описывающая отказоустойчивые / резервные MXзаписи: http://www.zytrax.com/books/dns/ch9/mail.html

— laebshade
источник

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

— Manca Weeks

1

@manca Нет, это дополнительные записи. Смысл наличия нескольких записей MX состоит в том, чтобы иметь более одного допустимого пути на случай, если что-то пойдет не так. По сути, вы просто переключаетесь на существующий сервер, пока он не будет перенастроен.

— Высокий Джефф

5

Самым важным параметром в вашем сенарио являются TTLсоответствующие записи DNS.

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

— Яхья
источник

Ну, я не имел в виду мгновенное. Цель будет около 12-14 часов ... Если я смогу это сделать, я буду в порядке. Я предполагаю, что один из способов сделать DNS вообще не имеет значения, это ввести фактический WAN IP во всех настройках почтового клиента - таким образом, это не будет иметь значения. Их всего около 40 ...

— Manca Weeks

0

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

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

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

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

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

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

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

— BillThor
источник