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
  • Доброго всем дня.

    Как оказалось - вторая конфигурация имеет право на жизнь. Действительно, почта приходит.

    Выглядит это следующим образом:

    postfix/smtp[14320]: connect to mail.domen.com[188.188.188.188]:25: No route to host
    Mar 13 23:51:32 sen postfix/smtp[14320]: DC2D513AD8E: to=<user@domen.com>, relay=mail.domen.com[46.46.46.46]:25, delay=17, delays=0/0.01/14/3, dsn=2.6.0, status=sent (250 2.6.0 <e64b49e9f498d68f2c6148bf08b4515c@sendDomen.ru> [InternalId=12846247182341, Hostname=lacalName.domen.com] 3066 bytes in 2.808, 1,066 KB/sec Queued mail for delivery)
    Mar 13 23:51:32 sen postfix/qmgr[1024]: DC2D513AD8E: removed

    К великому сожалению у меня сейчас подобная схема в продакшене, отсюда вытекает несколько проблем:

    1. пришлось подгонять конфигурацию сети под новую "почтовую схему" (маршруты, GRE тоннели и тд.)

    2. не забыть поменять настройки на сетевых сканерах

    3. добавить альтернативную А запись на первый внешний IP поскольку есть несколько запаблишеных ресурсов локальной сети, обновить эти настройки у ВСЕХ пользователей, благо у меня их не 10К

    4. сомнительная высокая доступность роли Mailbox. В случае если один сервер офлайн, то мобильные клиенты не могут подключиться из-за настроек DNS. Так же не работает OWA в случае одного рабочего сервера из двух - пока не разобрался почему, да и в текущих условиях диагностировать крайне сложно.

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

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

    Все это можно назвать - Как делать НЕ НАДО.

    Как НАДО делать можно прочитать тут.


    • Изменено Sergey Ya 14 марта 2018 г. 9:15
    14 марта 2018 г. 9:14
  • Доброго всем дня.

    Как оказалось - вторая конфигурация имеет право на жизнь. Действительно, почта приходит.

    она не просто имеет право на жизнь, а так "живёт" Office365:

    C:\>nslookup somedomain.mail.protection.outlook.com 8.8.8.8
    Server:  google-public-dns-a.google.com
    Address:  8.8.8.8
    
    Non-authoritative answer:
    Name:    somedomain.mail.protection.outlook.com
    Addresses:  213.199.154.234
              213.199.154.170
    

    И даже OWA:

    C:\>nslookup outlook.office.com 8.8.8.8
    Server:  google-public-dns-a.google.com
    Address:  8.8.8.8
    
    Non-authoritative answer:
    Name:    outlook-emeacenter4.office365.com
    Addresses:  2603:1026:7:28::2
              2603:1026:3:cb::2
              2603:1026:300:64::2
              2603:1026:203::2
              2603:1026:300:a1::2
              2603:1026:206:1::2
              2603:1026:206:2::2
              2603:1026:3:f6::2
              2603:1026:4:8b::2
              2603:1026:300:51::2
              40.101.53.242
              40.101.65.130
              40.101.90.2
              40.101.7.178
              40.101.72.146
              40.101.18.242
              40.101.18.34
              40.101.126.210
              40.101.4.2
              40.101.49.66
    Aliases:  outlook.office.com
              outlook.ha.office365.com
              outlook.office365.com.g.office365.com
    14 марта 2018 г. 9:36
  • Доброго всем дня.

    Как оказалось - вторая конфигурация имеет право на жизнь. Действительно, почта приходит.

    Выглядит это следующим образом:

    postfix/smtp[14320]: connect to mail.domen.com[188.188.188.188]:25: No route to host
    Mar 13 23:51:32 sen postfix/smtp[14320]: DC2D513AD8E: to=<user@domen.com>, relay=mail.domen.com[46.46.46.46]:25, delay=17, delays=0/0.01/14/3, dsn=2.6.0, status=sent (250 2.6.0 <e64b49e9f498d68f2c6148bf08b4515c@sendDomen.ru> [InternalId=12846247182341, Hostname=lacalName.domen.com] 3066 bytes in 2.808, 1,066 KB/sec Queued mail for delivery)
    Mar 13 23:51:32 sen postfix/qmgr[1024]: DC2D513AD8E: removed

    К великому сожалению у меня сейчас подобная схема в продакшене, отсюда вытекает несколько проблем:

    1. пришлось подгонять конфигурацию сети под новую "почтовую схему" (маршруты, GRE тоннели и тд.)

    2. не забыть поменять настройки на сетевых сканерах

    3. добавить альтернативную А запись на первый внешний IP поскольку есть несколько запаблишеных ресурсов локальной сети, обновить эти настройки у ВСЕХ пользователей, благо у меня их не 10К

    4. сомнительная высокая доступность роли Mailbox. В случае если один сервер офлайн, то мобильные клиенты не могут подключиться из-за настроек DNS. Так же не работает OWA в случае одного рабочего сервера из двух - пока не разобрался почему, да и в текущих условиях диагностировать крайне сложно.

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

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

    Все это можно назвать - Как делать НЕ НАДО.

    Как НАДО делать можно прочитать тут.


    Спасибо за обратную связь. Однако я так и не понял чем плох отвергнутый вами вариант. Расписанные вами пункты с 1 по 3 вообще не имеют отношения к конфигурации днс, а только лишь к вашей инфраструктуре.

    Пункт 4 также вызывает много вопросов. При чем тут роль mailbox, если мы говорим только о MX-записях? Да и роль Mailbox вообще не принимает подключения от клиентов, это делает CAS - проксирует подключения клиентов на нужные серверы mbx. 

    Почему не работает ова?) А вы догадайтесь))) У вас идет проброс 443 порта куда? наверно на один из двух эксчей (сервер сдох, значит проброс ведет в никуда). Ок. Пусть даже у вас две записи ова - с двух разных адресов (с каждого адреса на определенный эксч). Запись разрешаются у клиента в два адреса и клиент (браузер в данном случае) стучится на любую из них и каждый раз на разную. Поэтому у вас ова может либо не работать вообще (если клиенту везет и он подключается постоянно к одному и тому же адресу), либо работать через раз.

    Работа ова - это совсем другая задача и к МХ она не имеет никакого отношения, так что не миксуйте. Для овы поднимайте балансировщик, который бы принимал подключения по одному адресу, а раскидывал бы на несколько серверов эксчей. Вот вам простейший вариант - http://blog.bissquit.com/unix/debian/prostejshij-otkazoustojchivyj-balansirovshhik-layer-4/ 

    Из всего вывод: пока что прав ваш коллега:)

    14 марта 2018 г. 10:06
  • Egor Vasilev

    Если поднимать IT  с нуля без какой либо готовой инфраструктуры, то можно рассмотреть и этот вариант, но у меня обратная ситуация. Получается, что внесли изменения в DNS - почта работает, но остальное нет. Зачем делать так чтобы потом придумывать как это починить.

    В 2016 роль CAS (в 2010) она же Mailbox. Видимо, вы неправильно меня поняли. CAS притом, что теперь под одним mail.domen.com/owa скрываются 2 сервера и при выходе из строя одного мы получим 50% возможность получить доступ к корп почте.

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

    Я когда-то понимал тему по настройке Haproxy и даже успешно его настроил. Проработало недолго, месяц-два, потом купили 2016.

    Не хочу в этом посте разбирать причины странного поведения OWA при одном рабочем сервере из двух. Я пока не занимался этой проблемой и если не разберусь попрошу вашей помощи в другой теме :) Если в двух словах - удалось подключиться к owa - вводим логин/пароль - HTTP ERROR 500

    14 марта 2018 г. 10:39
  • Да и роль Mailbox вообще не принимает подключения от клиентов, это делает CAS - проксирует подключения клиентов на нужные серверы mbx.
    зависит от сервера.
    In Exchange 2016, the Client Access services are part of the Mailbox server, so you can't configure a standalone Client Access server like you could in previous versions of Exchange
    14 марта 2018 г. 10:40
  • Ну тогда вывод простой - вам не подходит это решение. От этого оно не становится плохим, просто вам не подходит. Если у вас все и так прекрасно работает, то смысла что-то менять я не вижу.

    В 2016 эксче набор служб транспорта вроде бы точно такой же как и в 2013, а потому клиентские подключения принимает все та же Frontend Transport. 

    14 марта 2018 г. 10:56
  • Наверное, это спорная тема, но мне по душе вариант с несколькими MX записями. Если нужно сделать балансировку - выставляешь вес записи.

    К сожалению, с 2013 не работал. Мы сразу перешли с 2010 на 2016, так что сравнивать могу только с 2010

    PS с одной стороны сравнивать "почтовых провайдеров" с обычной корп структурой немного некорректно по соображению того, что за обычной корп структурой скрывается множество иных служб/приложений, которые живут в "одной среде" и их нужно как-то "подружить между собой". Если брать во внимание провайдера предоставляющего исключительно сервис почтовых услуг, то тут имеет место быть всевозможные настройки DNS, почтового сервере и так далее.

    Возможно, я окажусь неправ, но настройки с одной MX и множеством A записей больше подходят "почтовым провайдерам"

    14 марта 2018 г. 11:10
  • Если нужно сделать балансировку - выставляешь вес записи

    это не балансировка, а отказоустойчивость. Ибо при двух живых MX почти всегда будет срабатывать первой та, у которой вес меньше.

    PS с одной стороны сравнивать "почтовых провайдеров" с обычной корп структурой немного некорректно по соображению того

    это было не сравнение, а демонстрация того, что "создатель" Exchange сам использует эту схему.

    Возможно, я окажусь неправ, но настройки с одной MX и множеством A записей больше подходят "почтовым провайдерам"

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

    Egor Vasilev про транспорт я имел ввиду лишь то, что всё это является частью Mailbox роли, что CAS нельзя установить отдельно от Mailbox


    • Изменено Anahaym 14 марта 2018 г. 11:27
    14 марта 2018 г. 11:24
  • Anahaym,

    С одинаковым весом двух MX это уже не только отказоустойчивость но и балансировка.

    Я имел ввиду, что в корп среде (не провайдера) такой сервис как почта плотно взаимодействует с остальными сервисами, и внося какие либо изменения в один сервис (в нашем случае почтовый) могут пагубно повлиять на зависимые от него. Чего не скажешь когда ты предоставляешь лишь одну услугу - почту, тут попросту зависимостей меньше.

    Но все это уже уходит за рамки этого топика.

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

    14 марта 2018 г. 12:50
  • Anahaym,

    С одинаковым весом двух MX это уже не только отказоустойчивость но и балансировка.

    В Вашем первом сообщении вес разный ;)

    Чего не скажешь когда ты предоставляешь лишь одну услугу - почту
    А Office 365 это не только почта )
    14 марта 2018 г. 13:15
  • Anahaym,

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

    Не придирайтесь))) Мы оба понимаем, что Office365 это не только почтовый сервис.

    Готов поспорить, что у них (MS) изолированы подобные вещи, что у них не крутится какой-нибудь Citrix/RDS/корп портал/1C на одной железке/на одном сайте/в одной сети/..... и так далее. Поэтому мы и наблюдаем бесперебойную работу office 365, чего не могу сказать про свою почту, увы. 

    14 марта 2018 г. 13:24
  • Anahaym,

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

    Не придирайтесь))) Мы оба понимаем, что Office365 это не только почтовый сервис.

    Готов поспорить, что у них (MS) изолированы подобные вещи, что у них не крутится какой-нибудь Citrix/RDS/корп портал/1C на одной железке/на одном сайте/в одной сети/..... и так далее. Поэтому мы и наблюдаем бесперебойную работу office 365, чего не могу сказать про свою почту, увы. 

    теперь Вы понимаете, почему условный "почтовый провайдер" может быть сложнее и "круче" чем корпоративная среда.
    • Изменено Anahaym 14 марта 2018 г. 13:33
    14 марта 2018 г. 13:33
  • Подскажите пожалуйста, я не понял, какой будет выбран IP адрес из "А" записей.

    "Сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д."

    То есть обращение к IP адресу уже не от нас зависит, а так работает DNS, он обратиться вначале

    По: A = first.domen.com = 1.1.1.1 TLL=180

    А если не нашел,

    По: A = first.domen.com = 1.1.1.2 TLL=180

    Так ?


    17 марта 2018 г. 22:05
  • именно так
    • Изменено Anahaym 18 марта 2018 г. 9:21
    18 марта 2018 г. 9:21
  • В начале он обратиться к совершенно случайной записи и в случае если сервер будет не доступен продолжит обращаться к остальным если такие есть в наличии. 

    Это справедливо для почтового сервера, чего нельзя сказать о веб сервере.

    18 марта 2018 г. 15:06
  • Так в случайной или все же по порядку ?
    18 марта 2018 г. 15:28
  • а порядка нет. обратится к одному - он и будет первый, перейдёт на другой - и будет вторым.
    18 марта 2018 г. 15:42
  • И для почтового. и для веб и для всех остальных, ибо RR.

    А с веб сервером и 500й очень интересная картина получается.

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

    В четвертых- версия сервера. Здесь, вот к примеру есть обсуждение ситуации, и похоже Вы ссылаетесь именно на нее. Как пишет Илья, в 2016 у него нет ошибки 500.  Возможно, что у Вас CU старее, и там это не закрыто, но я склонен думать, что все дело в куки файлах, на которые опирается OWA в своей сессии.

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

    @Андрей, DNS Round Robin почитать немного. Случайной, и порядок не важен. Потому как RR, о чем много упоминаний здесь в теме и присутствует.

    18 марта 2018 г. 15:44
  • Дима, так я читал. Пишут, что: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.

    То есть у Сергея, первый в списке 1.1.1.1, второй 1.1.1.2, вот я и думал, что он получает оба, но вначале обратиться к 1.1.1.1, а если он уже не ответил, к 1.1.1.2

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

    Или это уже зависит от настроек на серверной стороне ? А именно:

    Если это включено, он будет перемешивать, если выключено, то будет по порядку обращаться, пока первый не выйдет из строя. Так ?

    18 марта 2018 г. 16:07
  • Если это включено, он будет перемешивать, если выключено, то будет по порядку обращаться, пока первый не выйдет из строя. Так ?

    Если включено, будет перемешивать. Если выключено, то по порядку.

    пока первый не выйдет из строя.

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

    18 марта 2018 г. 16:28
  • В итоге к каким выводам мы пришли?
    17 июля 2018 г. 12:34
  • В итоге к каким выводам мы пришли?

    Сегодня мы узнали много нового. :D

    Как работает DNS RR, немного поговорили про SMTP протокол и самую малость о почтовой системе в целом.

    17 июля 2018 г. 12:41
  • В итоге к каким выводам мы пришли?

    Что второй способ это ваще тру, по гуровски,  да ?) Только у Сереги в связи его специфики локальной сети он не подходит.

    17 июля 2018 г. 12:44