LINUX.ORG.RU
ФорумAdmin

DNS для мейл-сервера с failover

 ,


0

1

привет,

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

Подскажите, логично ли выглядит такая схема (VIP перекидывается на активную ноду по чеку tcp 25 open, mail - ip основной ноды, fail - ip failover-ноды):

MX:
example.com → mail.example.com (pref 10)
example.com → mail-primary.example.com (pref 20)
example.com → mail-backup.example.com (pref 30)

A:
mail.example.com → VIP
mail-primary.example.com → MAIL
mail-backup.example.com → FAIL

PTR:
VIP → mail.example.com
MAIL → mail-primary.example.com
FAIL → mail-backup.example.com

TXT/SPF - ip:VIP ip:MAIL ip:FAIL -all

CallerID - <r>VIP</r> <r>MAIL</r> <r>FAIL</r>

Небольшое уточнение - VIP работает только на вход. На выход нода использует свой собственный внешний IP

★★★★★

Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от DiMoN

Может я и ошибаюсь, но MX-записи разве не для этого сделаны

МХ вроде как только для входящей почты и для проверок. Входящую почту 3 МХ с разным preference должны переварить норм (будет всегда использоваться VIP). А вот проверки бывают разные и тут не силен. Зобанят за какое-нибудь несоответствие домена фазе луны и упс

upcFrost ★★★★★
() автор топика

Подскажите, логично ли выглядит такая схема

Нет. VIP должен быть вторым по приоритету и закрыт файрволом с доступом только с доверенных IP.

Не мгновенный, пара минут простоя ок

Ржу. Пара минут - это пуля. Почитай https://tools.ietf.org/html/rfc5321#section-4.5.4

AS ★★★★★
()
Ответ на: комментарий от AS

Пара минут - это пуля. Почитай https://tools.ietf.org/html/rfc5321#section-4.5.4

ну так норм же. пара минут сильно меньше 30 минут или 4-5 дней. Не мгновенный но быстрый - в плане без обновления днс

Нет. VIP должен быть вторым по приоритету и закрыт файрволом с доступом только с доверенных IP

обоснуй. По идее на него должны приходить запросы, идущие на указанный в MX-записи FQDN. Точнее они конечно должны конечно по идее делать retry в каждую из mx-записей в указанном порядке, но чет те самые 30 минут меня сильно напрягают

upcFrost ★★★★★
() автор топика
Последнее исправление: upcFrost (всего исправлений: 2)
Ответ на: комментарий от upcFrost

В плане если бы не опасения за логику сторонних серверов что мол «отлуп значит через 2 дня» или еще лучше «отлуп значит нишмог» - можно и без VIP обойтись по идее, просто двумя MX+A+PTR

upcFrost ★★★★★
() автор топика
Ответ на: комментарий от upcFrost

обоснуй.

Полностью открытые MX могут заDoSить. В этом случае из доверенных сетей дойдёт через VIP.

но чет те самые 30 минут меня сильно напрягают

По идее 30 минут - это между циклами попыток доставки по всем MX. Хотя в явном виде вроде не регламентировано.

AS ★★★★★
()
Ответ на: комментарий от AS

Хотя в явном виде вроде не регламентировано

я на это и триггерюсь. В rfc сказано мол «неплохо б 30 мин, но если можете лучше - делайте как можете».

После телефонии такие формулировки вызывают стойкую ассоциацию с фразой «каждый точит как хочет»

Полностью открытые MX могут заDoSить. В этом случае из доверенных сетей дойдёт через VIP

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

upcFrost ★★★★★
() автор топика

Долго пытался вкурить, всё выше по топику описанное. Но так и не понял общей идеи, точнее концепта, что и как делать хотите.

VIP перекидывается на активную ноду по чеку tcp 25 open, mail - ip основной ноды, fail - ip failover-ноды

Перекидывайте, это не запрещено. Или вас смущает что потом отправитель будет не соответствовать принимающему MX? Есть такие товарищи кто проверяет, но их минимум и на них можно забить. Однако вы даже тут подстраховались.

anc ★★★★★
()

В части 30 минут - 2 минуты. Представьте у вас нормально работает сервак, вам отправляют из Австралии, сбой «по дороге» из Австралии, ну что же, ничего делать в части повтора не будем? Вариант простоя 2-е или 30 минут? Это же могло попасть и на 30 минут.
Но вы в чем-то правы. На бОльшие сроки такие как yahoo/aol были замечены. Простой на два часа, не пытаемся переслать.

anc ★★★★★
()
Ответ на: комментарий от anc

Или вас смущает что потом отправитель будет не соответствовать принимающему MX? Есть такие товарищи кто проверяет, но их минимум и на них можно забить

все так. один из таких товарищей - АОЛ, который все никак не сдохнет. И он к сожалению нужен (много писем идут в/из штатов)

Но так и не понял общей идеи, точнее концепта, что и как делать хотите

суть - есть мейл-сервер. Сервер пихается в сварм и разрешается лейблами на 2 ноды, макс 1 инстанс. Потом вешается virtual IP который автоматом цепляется к ноде где сейчас живет сервер. Хранилище реплицированное обе машины.

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

upcFrost ★★★★★
() автор топика
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от anc

Однако вы даже тут подстраховались.

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

Вот блин за это и не люблю почту, хотя 2 всего блеклиста для нового сервера имхо неплохо. Надо ещё dkim и dmarc добавить, авось и яху пропустят без лишних заявок

upcFrost ★★★★★
() автор топика
Ответ на: комментарий от upcFrost

Вот блин за это и не люблю почту, хотя 2 всего блеклиста для нового сервера имхо неплохо. Надо ещё dkim и dmarc добавить, авось и яху пропустят без лишних заявок

Сейчас бы в 2020 руками весь этот цирк настраивать. И зачем ты его вообще юзать начал недонастроенным? Мда.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

И зачем ты его вообще юзать начал недонастроенным

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

Знаешь что такое легаси и почему нельзя просто так взять и вырубить все нахрен?

upcFrost ★★★★★
() автор топика
Ответ на: комментарий от upcFrost

Прикольный прорыв, бро, но

для нового сервера

я интерпретирую как отсутствие завязанного на это легаси.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

upcFrost ★★★★★
() автор топика
Ответ на: комментарий от upcFrost

Подстраховались, а yahoo таки забанил, гомосеки.

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

Надо ещё dkim и dmarc добавить, авось и яху пропустят без лишних заявок

А вот это вообще нужно, без относительно именно вашей задачи.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.