none
DNS - MX, A, TLL и почтовый сервер

    Общие обсуждения

  • Коллеги, добрый день!

    Возник небольшой спор с одним из моих коллег, помогите рассудить. :)

    Речь пойдет о почтовых серверах и DNS.

    Задача - построить отказоустойчивый почтовый сервис из двух Exchange 2016.

    Как я вижу:

    разделю по ролям, дабы не усложнять

    EDGE {

    MX = first.domen.com 10 TLL=180

    MX = second.domen.com 20 TLL=180

    A = first.domen.com = 1.1.1.1 TLL=180

    A = second.domen.com = 1.1.1.2 TLL=180

    }

    Как все это будет работать в DNS (упустим PTR записи и тд.):

    Допустим, сервер google хочет отправить мне письмо: Он запрашивает MX запись домена domen.com => получает first.domen.com => запрашивает A запись домена first.domen.com => получает IP и начинает сеанс связи и так далее, результат - мы отправили письмо.

    В момент получения любой из A записей сервер google занес в свой DNS кэш нашу A запись и она будет храниться 180 секунд.

    В случае, если в кэше DNS сервера google завалялись наши записи, то он сразу, без запросов во внешние DNS отправлять письмо по имеющимся у него IP

    Предположим, first.domen.com ушел в офлайн:

    google получает MX, A => видит, что сервер ему не отвечает => запрашивает другую A запись по второй MX second.domen.com => отправляет письмо.

    Как видит мой коллега:

    EDGE {

    MX = first.domen.com 10 TLL=180

    A = first.domen.com = 1.1.1.1 TLL=180

    A = first.domen.com = 1.1.1.2 TLL=180

    }

    Как на мой взгляд все это будет работать:

    Все по той же схеме - google запрашивает MX => получает first.domen.com => запрашивает A запись /* и тут самое интересное */ внешний DNS сервер видит, что у него 2 одинаковые записи с разными IP и отправляет одну А запись (не забываем про DNS RR) => отправляем письмо.

    По этой схеме, в случае отказа одного из серверов - почтовый сервер google доставит нам письмо с вероятностью 50%. Во вторых, я не просто так указал TLL (тем более у MX записей он на порядок выше, но не суть) - если у google в кэше DNS имеется А запись о нашей единственной MX c TLL=180 , то повторно он запросит A запись спустя 180 секунд и с вероятностью 50% получит запись рабочего сервера.

    Как это должно работать по мнению моего коллеги:

    Та же схема - google делает запрос на внешний DNS => получает MX => делает запрос на А запись => получает два IP /*дальше я не понял*/:

    а) отправляет сразу по двум IP (двум серверам) письмо

    б) в случае отказа одного из серверов => google отправляет только живому серверу письмо

    -----------------

    Как грамотно построить отказоустойчивый почтовый сервис (best practices) имея два почтовых сервера?

    Будет ли работать вторая схема при двух живых серверах и только при одном из двух и как?

    Спасибо, что прочли, а то уж очень много букв :D

    13 февраля 2018 г. 13:24

Все ответы

  • Первый вариант однозначно. Здесь хорошо всё описано
    13 февраля 2018 г. 13:59
  • Первый вариант однозначно. Здесь хорошо всё описано

    Первый вариант мой и в его работоспособности я не сомневаюсь. :)

    Меня больше интересует второй вариант. Как все в такой конфигурации будет работать, лично я не представляю.

    13 февраля 2018 г. 14:03
  • Коллега, ответ на Ваш вопрос описан множеством ФАКов и мануалов, которые Вы, вероятно, уже просмотрели. Если Вам необходимо показать некомпетентность коллеги в этом споре, то да, я один из тех, кто подтвердит правильность Вашей точки зрения. Посоветуйте коллеге прочитать умные книжки по данному вопросу, т.к. неправильная настройка ДНС может пагубно сказаться на доставляемости писем вашей организации. Удачи!
    13 февраля 2018 г. 14:05
  • Коллега, ответ на Ваш вопрос описан множеством ФАКов и мануалов, которые Вы, вероятно, уже просмотрели. Если Вам необходимо показать некомпетентность коллеги в этом споре, то да, я один из тех, кто подтвердит правильность Вашей точки зрения. Посоветуйте коллеге прочитать умные книжки по данному вопросу, т.к. неправильная настройка ДНС может пагубно сказаться на доставляемости писем вашей организации. Удачи!

    Тут дело не в компетентности а в работоспособности конфигурации.

    Правильно ли я понял, что при второй схеме, в случае отказа одного из серверов мы будем получать только 50% писем?

    PS я специально не беру в расчет, что у сервера отправителя есть "попытки отправки" (если можно так назвать), речь идет только о DNS

    13 февраля 2018 г. 14:08
  • Я так подозреваю, что во втором случае письма таки придут все, поскольку отправляющий сервер сразу их не отбросит, а будет периодически долбиться к вашим серверам пока либо не пробъётся, либо не истечёт время ожидания в очереди. 
    13 февраля 2018 г. 14:28
  • Алгоритм Round Robin DNS - это самый простой способ распределения нагрузки, имеющий ряд минусов, среди которых и те, которые Вы описали. Для маршрутизации почты используются MX-записи, поэтому они так и называются - Mail eXchanger
    13 февраля 2018 г. 14:29
  • Зависит от деталей реализации MTA: будет ли он пытаться отправлять по альтернативным IP адресам для записи A.

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


    Слава России!

    13 февраля 2018 г. 14:40
  • Столько предположений и никто не взялся протестировать на реальной среде.

    Итак, первый вариант с двумя МХ всем понятен, его разбирать нет смысла.

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

    Что происходит на стороне отправляющего сервера? Для тестов возьмем обычный МТА Postfix, на которых в интернете работает подавляющее большинство почтовых серверов. Если не изображать из себя умного админа и не допиливать этот МТА под себя, то большинство задач он разрулит вполне себе корректно, это же касается и нашего кейса.

    Отправляем письмо на сервер, у которого МХ настроены как во втором примере топикстартера. Когда доступны оба адреса, то видим запись в логах:

    ________________________________________________________________

    Feb 14 13:57:37 mail postfix/smtp[62657]: ACF0D140073: to=<vasilev@domain.tld>, relay=mail.domain.tld[1.1.1.2]:25, delay=1.7, delays=0.17/0/0.09/1.5, dsn=2.6.0, status=sent (250 2.6.0 <bd5bbc4f-95d7-4261-a991-cc4756bfa9a7@getmailbird.com> [InternalId=133384504345527, Hostname=EXCH01.sc.local] Queued mail for delivery)

    ________________________________________________________________

    Собственно видно, что письмо доставлено и все хорошо (моменты, на которые стоит обратить внимание, я выделил жирным шрифтом).

    Дальше смоделируем ситуацию, когда один из принимающих серверов - в моем примере 1.1.1.2 - внезапно перестает принимать почту. Кому интересно: сервер я не отключал, а просто заблочил адрес в iptables (сервер с Postfix, разумеется, линуксовый), но думаю роли это не играет.

    Смотрим что происходит:

    ________________________________________________________________

    Feb 14 14:02:16 mail postfix/smtp[62676]: connect to mail.domain.tld[1.1.1.2]:25: Connection timed out
    Feb 14 14:02:17 mail postfix/smtp[62676]: 35E8F140073: to=<vasilev@domain.tld>, relay=mail.domain.tld[1.1.1.1]:25, delay=31, delays=0.15/0/30/0.7, dsn=2.6.0, status=sent (250 2.6.0 <dc5f628f-eac0-44d0-954f-395004205ed5@getmailbird.com> [InternalId=139818365354012, Hostname=EXCH02.sc.local] Queued mail for delivery)

    ________________________________________________________________

    Отправить на прежний адрес у МТА не получилось и он сразу предпринял попытку отослать данные на второй адрес в выдаче DNS RR. Задержка минимальная и ни чуть не больше, чем если бы были настроены две МХ.

    Вывод: оба варианта настройки МХ, на мой взгляд, равнозначно имеют право на жизнь. Только первый вариант однозначно сложнее в плане конфигурации - это и две МХ, это и два разных HELO в настройках эксчей, это и разные имена в сертификатах и т.п. Мое мнение - чем больше единообразия, тем лучше и тем меньше влияние человеческого фактора. Так что если вам не нужно распределение потока входящей почты в виде АКТИВНЫЙ-ПАССИВНЫЙ, которое вы можете реализовать только гибкой настройкой приоритетов МХ, вполне можно использовать вариант №2, который, как оказалось, тоже работает неплохо.

    Поправьте меня, если я упустил какие-то важные моменты.



    • Изменено Egor Vasilev 14 февраля 2018 г. 15:57
    14 февраля 2018 г. 11:21
  • Egor Vasilev , спасибо за развернутый ответ!


    Пару месяцев назад моделировал ситуацию в DNS на Windows Server 2012:

    Создал две записи: A = test.domen.com = 192.168.100.100 TLL=60; A = test.domen.com = 192.168.100.101. По факту второго хоста не было.

    Далее начал пинговать по доменному имени и ситуация была такая: Пингую- есть ответ; жду минуту-две; пингую-ответа нет и так далее, в рандомном порядке.

    Я понимаю, что сравнивать клиентскую машину и сервер мягко говоря - не правильно, но по-моему DNS что там и и там работает одинаково. 

    Простите, что докапываюсь, но все равно не пойму откуда взялся второй IP. Допустим, не было этого IP в кэше, но в таком случае на что тогда TLL?

    14 февраля 2018 г. 15:08
  • Коллега, как вы знаете, DNS RR выдает набор адресов в последовательно порядке - сначала первым будет один адрес, потом следующий, потом следующий и так далее. То есть, такое поведение зашито на уровне сервера DNS. За счет этого и осуществляется примитивная балансировка нагрузки (если в DNS RR выдача в три адреса и обращаются по очереди три клиента, то первыми в выдаче у каждого из них будут разные адреса и нагрузка распределится равномерно между тремя серверами)

    Задача пинга другая - он просто проверяет доступность хоста. Если в выдаче несколько адресов, то у него нет задачи последовательно проверить каждый из них.

    Задача почтового сервера (или МТА - в узком смысле) - доставить письмо получателю. И этот МТА всеми известными ему способами пытается выполнить задачу.

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

    14 февраля 2018 г. 15:53
  • думал топик соберет много неравнодушных, но по факту как-то все быстро затухло. Может кто-то ещё поделится вескими ЗА или ПРОТИВ двух описанных вариантов настройки МХ?
    15 февраля 2018 г. 7:26
  • Не могу сказать про остальных, но я все же намереваюсь протестировать все это добро, просто пока времени нет собрать тестовый стенд. Либо пробовать на боевом сервере. Задача - сравнить вывод ipconfig /displaydns до отправки письма и после, предварительно очистив кэш ipconfig /flushdns


    15 февраля 2018 г. 9:01