Несколько А для MX

mx in A 1.1.1.1
mx in A 2.2.2.2

вопрос в том, чтоб 2.2.2.2 работал как бэкапный (т.е. только! тогда когда лежит 1.1.1.1

Не будет так. Почта будет пытаться доставиться на выбранный случайным образом. Точнее, DNS выдаёт адреса циклически.

слабое железо, слабый канал, потеря писем.

Это нифига не повод письма терять.

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

В чём проблема указать больше одной?

у MX записей есть приоритет. Делай N серверов и пробивай их с разными приоритетами.

Скажи мне, вот отпал у тебя по какой-то причине основной сервер. В это время тебе отправили почту и оно пришло на резервный. Через 5 минут основной снова доступен. Как ты будешь собирать почту с резервных серверов на основной?

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

Ну вы и вопросы задаёте, он же пишет из горящего танка:

если он работает мин 30-50 раз в неделю-две, то норм,

В чём проблема указать больше одной?

Понятия не имею, ТС спрашивай. :-) Только задача на 100% не решаема всё равно в том виде, как ТС хочет: при более, чем одном MX, почта на низкоприоритетный MX всё равно будет пытаться доставляться время от времени даже при живом высокоприоритетном.

Так приоритетом же, если один лежит то на второй полетит все, если оба работают то полетит на первый. У ТС нет в задании синхронизации поэтому как то так...

mx in A 1.1.1.1 10 
mx in A 2.2.2.2 20

Это в каком демоне ns такой синтаксис?

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

ладно, с потерей писем погорячился.

вопрос в том, что вроде как все норм, пусть летает через разные (все равно придет по назначению), но если серв 1.1.1.1 лежит, а днс в этот момент выдал его адрес, то письма возвращаются с ошибкой, а не пытаются идти на 2.2.2.2

вот тут и вопрос как и можно ли с этим бороться.

несколько МХ нельзя по разным причинам. можно это оставить как «потому что».

конкретизирую вопрос. как сделать к примеру как у гугуля или яндекса. для домена указывается МХ и все, а если копнуть глубже, то эта запись (МХ) имеет немеренно А записей. т.е. почта летает через разные сервы (на всех релеи на хранилище)

Кто же вам запрещает тоже самое сделать. Куча А записей не у mx, а у хоста, на который указывает один MX, по имени же. Как там у гугла организованно не особо важно, скорее всего кластер с балансировщиком и кучей каналов до него. Это сделано не для того, чтобы был ровно один MX, а для обработки чудовищной нагрузки.

вопрос в том, что вроде как все норм, пусть летает через разные (все равно придет по назначению), но если серв 1.1.1.1 лежит, а днс в этот момент выдал его адрес, то письма возвращаются с ошибкой, а не пытаются идти на 2.2.2.2

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

несколько МХ нельзя по разным причинам. можно это оставить как «потому что».

Как раз несколько MX и вписываются для того, чтобы решить вашу задачу. Что за причины?

но если серв 1.1.1.1 лежит, а днс в этот момент выдал его адрес,
то письма возвращаются с ошибкой, а не пытаются идти на 2.2.2.2

Нет, они пойдут на 2.2.2.2. Если, конечно, на той стороне не произведение DJB, а вменяемый MTA. Они на 2.2.2.2 не пойдут только в том случае, если 1.1.1.1 выдал 5xx, а не лежит. И даже если на той стороне произведение DJB, то неответ сервера не будет воспринят, как ошибка. Сообщение останется в очереди на определённый срок.

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

domain.tld.                3600    IN      MX      10 aspmx.l.google.com.
domain.tld.                3600    IN      MX      20 alt1.aspmx.l.google.com.
domain.tld.                3600    IN      MX      30 aspmx5.googlemail.com.
domain.tld.                3600    IN      MX      30 aspmx3.googlemail.com.
domain.tld.                3600    IN      MX      30 aspmx4.googlemail.com.
domain.tld.                3600    IN      MX      30 aspmx2.googlemail.com.
domain.tld.                3600    IN      MX      20 alt2.aspmx.l.google.com.

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

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

на всех резервных настроена пересылка на основной

расскажи как реализовал

расскажи как реализовал

Это как-бы не очень то особеная конфигурация, что требует трудного поиска ответа. Вбиваете в гугл backup mx и имя вашего почтовика.

все поиски свелись к нескольким МХ.

Спасибо, разобрался, перечитал логи...

действительно, основной не ложился «как таковой» а из-за непонятных причин (разбираюсь) 1.1.1.1 выдает 554 ошибку, естественно, почта летит назад.

от AS:

«Они на 2.2.2.2 не пойдут только в том случае, если 1.1.1.1 выдал 5xx, а не лежит.»

бывает выдает 450ю, вроде как из-за reject_unknown_sender_domain (хотя хз почему, письмо с гугля) и шлет назад отправителю...

по правде, я пошел путем меньшего сопротивления. в нете масса статей по поводу pastfix as backup, exim as backup..

Я взял готовую рабочую сборку postfix+spamassasin и втулил relay_domains

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

Если правильно распарсил. Не пофиг ли что повторной пересылкой займется отправляющая сторона?

Не правильно распарсили. «если он работает мин 30-50 раз в неделю-две» — это у него mx такой, единственный :) Не будет у него почты, если «запасной» не подопрёт этот горящий танк. :)

Не правильно распарсили. «если он работает мин 30-50 раз в неделю-две» — это у него mx такой, единственный :) Не будет у него почты, если «запасной» не подопрёт этот горящий танк. :)

Упс. Точно не правильно распарсил. Тогда вопрос к ТС а это такое нафейхуа? Нестабильный почтарь? Для себя лично?

все гут работает. признаюсь, хотел на...ь систему и поставил зимбру на слабое железо (i3 4х1.7ghz 4gb dd3 мало для нее оказывается...) и она блин регулярно тушила МТА. поставил на e2630 6x2.2 24Gb ram - пашет аж гудит ))

сделал несколько А записей и почту изначально бросил на другой серв (там 4х2,2 и 12гб и канал 1Гбит), он на грудь принимает весь спам. как показали результаты постфикс+спамассасин намного менее прожорливы и на порядок быстрее переваривают около 2500 писем\час чем штатные зимбры.

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

Итог получился:

dom.tld in MX 10 mail1.tld

dom.tld in MX 20 mail2.tld

dom.tld in MX 20 mail3.tld

.....

mail1.tld in A 1.1.1.1

mail2.tld in A 2.2.2.2

mail2.tld in A 3.3.3.3

mail3.tld in A 4.4.4.4

mail3.tld in A 5.5.5.5

это пришлось навернуть т.к. к-во ящиков выросло до 800 а писем до 13-15000... народ дуреет и пользуют почту как месенджер. пофиг. с таким раскладом теперь все работает без задержек. приоритеты специально стоят одинаковые чтоб разгрузить каналы.

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

Так у вас dom.tld in MX 10 mail1.tld практически вся почта туда и пойдет.

именно так. он «на амбразуре». за ним зимбра. а те, как резервные. как показала практика за последние 4 дня из 10000 писем на него идет порядка 6-6500 остальные раскидываются по 4м остальным. почему - хз.

за последние 4 дня

Вы уж простите, но что-то не сходиться
13.09.2017 13:26:43
16.09.2017 20:41:11

ЗЫ А вот то что пойдут и на меньший приоритет, об этом AS писал выше. Но вот процент считать рано, вы же за эти <4-х дней шаманили.