Несколько обслуживаемых доменов, один IP. Как настраивать DNS?
 

Добрый день, коллеги!

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

Имеется один внутренний Exchange, который обрабатывает почту с нескольких доменов:
domain.com (по умолчанию)
domain.ru
domain2.ru
domain3.ru
domain.pro

В соединителе на отправку ответом на HELO/EHLO стоит mail.domain.com.

Есть TMG-сервер, который смотрит на двух провайдеров, один основной, другой резервный (только отработка отказа).
Сейчас почта нормально ходит с домена по умолчанию, а на другие домены идёт ругань, что нет обратного DNS.

Что я хотел бы сделать:

1) Установить второй TMG-сервер в массив с первым, назначив ему IP-адреса на единицу больше, чем у первого TMG.
2) Прописать DNS-записи для почты таким образом, чтобы любой отказ - одного из провайдеров или одного из серверов - не прерывал работы почты и интернета и переключение шло автоматически.

Я зашёл на хостинг и прописал там для каждого из доменов mx-записи типа:

5 mail.<домен> (первый ip основного провайдера, первый TMG)
10 mail2.<домен> (второй ip основного провайдера, второй TMG)
15 mail3.<домен> (первый ip резервного провайдера, первый TMG)
20 mail4.<домен> (второй ip резервного провайдера, второй TMG)

Вопросы:
1) Правильно ли я начал делать, и если неправильно, то как сделать правильно?
2) Как мне прописать PTR-запись у провайдера, если она возможна только одна для одного ip-адреса, обеспечив требования к бесперебойности работы и успешного прохождения проверки на обратный DNS? Доменов-то у меня пять, и прописать несколько PTR-записей разных доменов к одному IP невозможно.

Заранее спасибо.

Корень зла здесь :)
TMG для отказоустойчивости лучше собрать в NLB-массив. Имхо.
PTR-запись, или запись в обратной зоне.
Логика ее использования:
При установлении SMTP-сессии сервер отправляет команду helo\ehlo, представляесь тем FQDN, который прописан в коннекторе отправки. Т.е. в вашем случае mail.domain.com. Следовательно, каждый IP-адрес должен иметь запись в зоне in-arpa что он, это mail.domain.com. Два провайдера - для каждого прова есть своя зона обратных записей, PTR-запись должна быть на каждый адрес, который попадает в SMTP-пакет, как Source. Да. И каждому из пяти доменов пофиг, что отправляющий сервер представляется, как mail.domain.com.
В принципе неплохо. НО! Я бы сделал на каждом провайдере DNS RR. У каждого провайдера - две МХ-записи с одинаковым приоритетом, по одной на каждый TMG (но заострю внимание - WNLB, имхо опять же, лучше).
Правильно, рассмотрите варианты с NLB и DNS RR.
Одну на каждый IP, с которого почта будет уходить. Все PTR-записи должны указывать на FQDN, прописанный в свойствах Send Connector.
Для более корректной работы со спам-фильтрами, рекомендую создать так же записи SPF (Sender Policy Framework). Вот тут есть вполне себе мастер по созданию этих записей: http://www.microsoft.com/mscorp/safe...nderid/wizard/
Удачи, коллега :) Будут вопросы - welcome!

Надо посмотреть, энтерпрайз ли у меня лицензия на TMG... А синхронизация настроек только в балансирующем кластере бывает, или можно синхронизировать настройки без кластеризации?

У меня пока один сервер TMG, второй сервер освободится после вывода из продакшна старой ISA 2006. Причём роль пограничного сервера Exchange установлена прямо на сервер TMG. Я планировал поступить так же и со вторым сервером.

Что касается карусели DNS - будет ли принимающий сервер заморачиваться перебором всех обратных DNS, относящихся к этому адресу, прежде чем дать отлуп по отсутствию обратного DNS? Или карусель надо делать для прямого DNS? Но тогда я не совсем понимаю её назначения...

Пока я понимаю так:
1) У всех обслуживаемых доменов в прямой зоне на хостинге прописываются четыре МХ-записи от domain.com.
2) Для МХ-записей domain.com создаются PTR-записи на четыре разных IP-адреса.
3) На каждом Edge делаются два соединителя отправки с указанием адреса HELO/EHLO с названиями соответствующих МХ-записей.

Так как пока Edge у меня не настроен, можно на самом сервере Exchange создать все четыре коннектора.
Верно?

у меня для 8 доменов 8 записей МХ указывающих на одно и тоже имя (т.е. МХ mail.domain.tld для всех доменов) - и один коннектор.

Чем критично то, что у меня 8 доменов ссылаются на одно имя? или всё равно?

Автоматики нет, то есть при сбое надо руками всё переделывать. А я хочу, чтобы у меня 4 IP-адреса одновременно торчали в интернете, и при сбое какого-либо из серверов или какого-либо из провайдеров переключение на другие МХ шло автоматически.

так для этого вроде и есть приоритеты МХ записей... вроде всё просто.

не-не, парни, МХ в Reverse DNS Lookup не участвует. DJ Mogarych, у тебя же получится 4 записи PTR с одним именем (mail.domain.com) и 4 IP. RDNS Lookup делает запрос по IP-адресу к своему DNS. Типа: "Скажи-ка дядя, а вот этот 10.10.10.10 он правда mail.domain.com или врет?", вернее даже "Кто такой 10.10.10.10?" И если он получит совпадающее с предствалением в HELO\EHLO имя, значит Lookup Success.Это балансировка примитивная. Сервер получит адреса списком и выберет рандомно один из них. Если он мертвый, то сессия оборвется с кодом выхода, и через Retry-интервал повторится, тогда возьмется другой адрес.
Нет. В каждой зоне пишешь 4 записи МХ ОТДЕЛЬНО для каждого домена. Т.е. 4 для domain.com, 4 для corp.domain.com и т.д.
Нет. Создаются 4 записи в зонах PTR каждого диапазона все на одно имя mail.domain.com. Пример:
10.10.10.10.in-addr.arpa name = mail.domain.com
20.10.10.10.in-addr.arpa name = mail.domain.com
10.10.16.172.in-addr.arpa name = mail.domain.com
20.10.16.172.in-addr.arpa name = mail.domain.com
Вот так.
Нет. Один. А балансировка на TMG при помощи Source Routing, слава богам оно теперь это умеет и линуксоиды перестали смеятся и тыкать пальцем :) Главное для проверки - он должен представляться тем именем, которое в PTR для этого адреса. А оно у нас одно.
Нет. Коннектор один на всех. Его, кстати, так и так правильнее создавать на хабах, а не на Edge. Конфа хранится в АД и синхронится на Edge при помощи Edge Sync. Кстати, настройка Edge - 20 минут :)

Угу, с обратным dns более-менее понятно. Одно имя - несколько IP.

Ещё раз, пожалуйста, для туго соображающих: я прописываю для каждого домена свои МХ-записи, то есть для domain2.ru они будут
mail.domain2.ru
mail2.domain2.ru и т. д.,

или для всех обслуживаемых доменов я прописываю четыре одинаковые МХ-записи от основного домена вида
mail.domain.com
mail2.domain.com и т. д.?

И если второй вариант, то А-записи DNS мне нужны только в основном домене, остальные записи типа mail3.domain.pro мне можно удалить?

То есть, пользователь отправляет письмо с адреса user@domain2.ru, оно проходит через коннектор с записью HELO/EHLO mail.domain.com, и принимающий сервер проверяет обратный DNS, глядя на соответствие HELO/EHLO и IP-адреса? Иначе как проверка обратного DNS сможет пройти, если домен отправителя - domain2.ru, а обратный DNS mail.domain.com?

То есть, настройка двух Эджей идентична - везде по одному одинаковому коннектору?
А если TMG-серверы будут в кластере, это не значит, что и Эджи, которые установлены на них, тоже будут в кластере автоматически?
Если знать Эдж, то наверное, да. А я первый раз его вижу в смысле самостоятельной настройки. :)

работоспособны оба варианта. у меня по второму.

по-поводу Reverse Zone - попробую уточнить сейчас... Но она вообще хранится в зоне ответственности провайдера IP...

нашёл про обратный ДНС - на один IP можно прописывать сколько угодно доменных имён.

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

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

К примеру, когда у нас почта корпоративная была на гугле, но домен был свой:
старые записи ещё не удаляли...

Что-то я сам запутался :) Перейдем к примерам.
У нас есть 4 IP-адреса, которые должны принимать почту. И несколько доменов, в которых есть почтовые ящики с разными суффиксами.
1. В домене domain.com создаем 4 МХ записи:mx1.domain.com, mx2.domain.com, mx3.domain.com и mx4.domain.com. Это записи типа А.
2. В каждом домене создаем записи типа МХ. Начнем с домена domain.com:
domain.com MX preference = 10, mail exchanger = mx1.domain.com
domain.com MX preference = 20, mail exchanger = mx2.domain.com
domain.com MX preference = 30, mail exchanger = mx3.domain.com
domain.com MX preference = 40, mail exchanger = mx4.domain.com

Продолжаем для домена subdomain1.domain.com:
subdomain1.domain.com MX preference = 10, mail exchanger = mx1.domain.com
subdomain1.domain.com MX preference = 20, mail exchanger = mx2.domain.com
subdomain1.domain.com MX preference = 30, mail exchanger = mx3.domain.com
subdomain1.domain.com MX preference = 40, mail exchanger = mx4.domain.com

Далее у нас не связаный общим пространством имен с основным, домен domain.ru
domain.ru MX preference = 10, mail exchanger = mx1.domain.com
domain.ru MX preference = 20, mail exchanger = mx2.domain.com
domain.ru MX preference = 30, mail exchanger = mx3.domain.com
domain.ru MX preference = 40, mail exchanger = mx4.domain.com

Заметь, в КАЖДОМ домене свой набор МХ-записей, но все они указывают на ОДНИ И ТЕ ЖЕ записи А. Это будет работать без всяких проблем. Да, в примерах приориеты выставлены от балды, будешь думать в сторону RR - поставишь для узлов основного и резервного каналов попарно одинаковые. Типа mx1 и mx2 - 10, mx3 и mx4 - 20.
У тебя для всех доменов письма будут уходить через один коннектор. Он представляется mail.domain.com. Как выглядит сессия:
220 l-s-exch01.exchange.lab Microsoft ESMTP MAIL Service ready at Sat, 16 Jun 2012 17:22:10 +0400 (это банер приветствия)
helo mail.domain.com (это твой сервер поздоровался и представился тем FQDN, какой у него прописан в коннекторе)
Дальше мой сервер в фоне делает запрос:nslookup -t=ptr 10.10.10.10 и получает в фоне же ответ: 10.10.10.10.in-addr.arpa name = mail.domain.com. Видит, что сервер с адресом 10.10.10.10, представившийся именем mail.domain.com действительно тот, за кого себя выдает. И отправляет ответ уже серверу в SMTP-сессию:
250 l-s-exch01.exchange.lab Hello [10.10.10.10] (все хорошо, стартуй сессию)
В противном случае ответ будет:
554 5.7.1 - Connection refused. IP name lookup failed for 10.10.10.10 (это необязательно прям вот так выглядит, каждый сервер отвечает по своему, но смысл один).
Кстати, сам Exchange в чистом виде RDNS Lookup не умеет, только в сочетании с SenderID. Это так, для информации :)
Да, настройка идентична. Емнип, TMG не кластеризуется в классическом понимании кластеризации (Windows Failover Cluster), взамен этого там массив серверов и балансировщик сетевой нагрузки (ну типа тоже кластер, но он и не кластер совсем). Так вот массив нужен для общей конфигурации членов массива, а балансировщик, понятно, для балансировки. Балансировка настраивается по портам. Скажешь балансировать TCP 25 (SMTP) будет балансировать, не скажешь - не будет. MS в качестве балансировки и отказоустойчивости Edge Transport рекомендует именно DNS RoundRobin.

Вот я умник, да? :) Конечно же создаем 4 А записи.
А так как выше описано, так и пройдет. Она не смотрит в прямую зону, только в обратную. А обратная, как заметил exo, лежит у провайдера.
Все, ничего не забыл? :D

WOW! Автообъединение ответов!!!! Круть! :D

Отлично, теперь всё ясно, спасибо огромное!
Может, потом, если руки дойдут, нарисую схему сети, выложу её здесь.