Доброго времени суток!
Пишу в разделе DNS, но вопрос наверное по большей части касательно почтовых серверов...Есть один почтовик с двумя провайдерами; надежность провайдера, у которого скорость выше хромает.
Я создаю MX запись mail.xxx.yy. A записей на домен mail.xxx.yy две. По одной на каждый IP каждого провайдера. Для "распределения" нагрузки.
Вопрос: Если я укажу на A записи "кошерный" TTL 3600 сек, почтовый сервер пытающийся отправить нам письмо забирает сразу обе A записи и, в случае неудачи по одному IP пытается отправить на второй, или "запоминает" первую попавшуюся A запись и долбится в нее до окончания TTL? И мне тогда надо указывать TTL 5-10 секунд?
P.S. Сейчас TTL 10 сек.
Заранее спасибо за помощь!
>[оверквотинг удален]
> хромает.
> Я создаю MX запись mail.xxx.yy. A записей на домен mail.xxx.yy две. По
> одной на каждый IP каждого провайдера. Для "распределения" нагрузки.
> Вопрос: Если я укажу на A записи "кошерный" TTL 3600 сек, почтовый
> сервер пытающийся отправить нам письмо забирает сразу обе A записи и,
> в случае неудачи по одному IP пытается отправить на второй, или
> "запоминает" первую попавшуюся A запись и долбится в нее до окончания
> TTL? И мне тогда надо указывать TTL 5-10 секунд?
> P.S. Сейчас TTL 10 сек.
> Заранее спасибо за помощь!Сделайте две MX записи с разным весом. Если есть MX запись, наврядли почта пойдёт по A.
> Сделайте две MX записи с разным весом. Если есть MX запись, наврядли
> почта пойдёт по A.MX может содержать FQDN, а то и имя внутри @, в обоих случаях предполагая ещё один заход за A.
tc спрашивал про другое - что вытворят конкретный resolver + конкретный почтовик с этими записями.
Ответ простой - возьми той травы, которую курили программёры, написавшие эти конкретные реализации, и тебе станет всё ясно.
P.S. TTL 10 сек. не спасут отца русской демократии. Нужно решать проблему на другом уровне. Подсказка - round-robin DNS. Работает за несколько мсек.
> Подсказка - round-robin DNS. Работает за несколько мсек.Интересно как rr решит проблему запрета отдачи временно нерабочего ip?
Если канал отваливается не на неделю, то проблемы вообще никакой нет - почта не реалтайм протокол.
Это не проблема. Если адрес нерабочий, почтовик сразу же попробует другой.
> забирает сразу обе A записи и,
> в случае неудачи по одному IP пытается отправить на второй, или
> "запоминает" первую попавшуюся A запись и долбится в нее до окончания
> TTL? И мне тогда надо указывать TTL 5-10 секунд?TTL это хранение RR в кеше, ты вообще не туда думаешь.
>> забирает сразу обе A записи и,
>> в случае неудачи по одному IP пытается отправить на второй, или
>> "запоминает" первую попавшуюся A запись и долбится в нее до окончания
>> TTL? И мне тогда надо указывать TTL 5-10 секунд?
> TTL это хранение RR в кеше, ты вообще не туда думаешь.Знаю что такое TTL. Вопрос был в другом: в поведении клиента.
> Есть один почтовик с двумя провайдерами; надежность провайдера, у которого скорость выше
> хромает.
> Я создаю MX запись mail.xxx.yy. A записей на домен mail.xxx.yy две. По
> одной на каждый IP каждого провайдера. Для "распределения" нагрузки.Лучше сделайте две записи A с разными именами. Типа mail.xxx.yy на IP одного провайдера, и mail-aux.xxx.yy на IP второго провайдера. И две записи MX, одну приоритетнее на A адрес через провайдера пошире, вторую менее приоритртную через провайдера понадёжнее.
xxx.yy. MX 5 mail.xxx.yy.
xxx.yy. MX 10 mail-aux.xxx.yy.
mail.xxx.yy. А 1.1.1.1
mail-aux.xxx.yy. А 2.2.2.2
"Распределения" нагрузки не надо, если сервер всё равно один, от попытки распределения будет больше вреда чем пользы.> Вопрос: Если я укажу на A записи "кошерный" TTL 3600 сек, почтовый
> сервер пытающийся отправить нам письмо забирает сразу обе A записи и,
> в случае неудачи по одному IP пытается отправить на второй, или
> "запоминает" первую попавшуюся A запись и долбится в нее до окончания
> TTL? И мне тогда надо указывать TTL 5-10 секунд?Заберёт обе A записи, запомнит результат на 3600 секунд и будет их использовать как ему вздумается. Пока TTL не истечёт, будет пользоватся тем ответом который уже добыл. Когда истечёт - спросит снова. TTL не влияет на выбор из нескольких записей A, а только на то, как часто их будут спаршивать у авторитативного DNS.
> Лучше сделайте две записи A с разными именами. Типа mail.xxx.yy на IP
> одного провайдера, и mail-aux.xxx.yy на IP второго провайдера. И две записи
> MX, одну приоритетнее на A адрес через провайдера пошире, вторую менее
> приоритртную через провайдера понадёжнее.Наверное так и придется поступить.
Хотелось распределения нагрузки... Но придется обойтись только резервированием.
Спасибо всем кто помог и/или пытался.
>> Лучше сделайте две записи A с разными именами. Типа mail.xxx.yy на IP
>> одного провайдера, и mail-aux.xxx.yy на IP второго провайдера. И две записи
>> MX, одну приоритетнее на A адрес через провайдера пошире, вторую менее
>> приоритртную через провайдера понадёжнее.
> Наверное так и придется поступить.
> Хотелось распределения нагрузки... Но придется обойтись только резервированием.
> Спасибо всем кто помог и/или пытался.а головой подумать и поставить одинаковый вес на обе MX записи что мешает? И зачем трогать ttl если совем для другого?
>>> Лучше сделайте две записи A с разными именами. Типа mail.xxx.yy на IP
>>> одного провайдера, и mail-aux.xxx.yy на IP второго провайдера. И две записи
>>> MX, одну приоритетнее на A адрес через провайдера пошире, вторую менее
>>> приоритртную через провайдера понадёжнее.
>> Наверное так и придется поступить.
>> Хотелось распределения нагрузки... Но придется обойтись только резервированием.
>> Спасибо всем кто помог и/или пытался.
> а головой подумать и поставить одинаковый вес на обе MX записи что
> мешает? И зачем трогать ttl если совем для другого?А вы головой думали когда прошли мимо первого поста?
Советую прочитать после слова "Вопрос:"
>[оверквотинг удален]
>>>> одного провайдера, и mail-aux.xxx.yy на IP второго провайдера. И две записи
>>>> MX, одну приоритетнее на A адрес через провайдера пошире, вторую менее
>>>> приоритртную через провайдера понадёжнее.
>>> Наверное так и придется поступить.
>>> Хотелось распределения нагрузки... Но придется обойтись только резервированием.
>>> Спасибо всем кто помог и/или пытался.
>> а головой подумать и поставить одинаковый вес на обе MX записи что
>> мешает? И зачем трогать ttl если совем для другого?
> А вы головой думали когда прошли мимо первого поста?
> Советую прочитать после слова "Вопрос:"Ещё раз. при чём тут ttl? зачем его трогать и как он относится к решению задачи "распределения нагрузки"?