Несмотря на то что формирование стратегии маршрутизации почты на приоритетах записей MX выглядит достаточно просто, почтовые администраторы должны обратить внимание на несколько нюансов. Это сможет помочь в дальнейшем при определении места, в котором могла появиться проблема с маршрутизацией почты.
Алгоритмы маршрутизации, основанные на приоритетах записей MX, в некоторых ситуациях могут приводить к зацикливанию. Понимание логики работы почтовых серверов поможет избежать появления таких ситуаций. Рассмотрим пример:
companyabc.com IN MX 10 m1.companyabc.com companyabc.com IN MX 20 m2.companyabc.com companyabc.com IN MX 30 m3.companyabc.com
Когда сообщение отправляется по адресу LSomi@companyabc.com с адреса, находящегося вне домена companyabc.com, почтовый сервер ищет доступный почтовый сервер в домене companyabc.com, просматривая записи MX этого домена. Если первый сервер с самым низким приоритетом (m1.companyabc.com) недоступен, почтовый сервер пытается обратиться ко второму серверу (m2.companyabc.com). Сервер m2 делает попытку переслать сообщение на m1.companyabc.com, поскольку этот сервер имеет наименьший приоритет в списке серверов. Когда m2 замечает, что m1 недоступен, он пытается соединиться со следующим сервером в списке (то есть с самим собой), создавая замкнутый цикл. Если m2 попытается отправить сообщение серверу m3, тот, в свою очередь, будет соединяться с m1, потом с m2, потом с самим собой, снова попадая в замкнутый цикл. Для обхода ситуаций подобного рода почтовые серверы убирают определенные адреса из списка до начала процесса отправки сообщения. Почтовый сервер сначала сортирует список доступных узлов по приоритетам, потом проверяет каноническое имя домена, в котором они запущены. Если узел локальный (находится в том же домене) и является сервером обмена почты, почтовый сервер убирает из списка запись MX этого узла и записи MX всех узлов с таким же или большим приоритетом. В вышеприведенном примере сервер m2 не будет предпринимать попытки доставить почту через серверы m1 и m3.
Использование в записи MX псевдонима (alias), а не канонического имени сервера - другая частая ошибка администраторов почты. Большинство почтовых серверов осуществляют поиск не по псевдониму, а по каноническому имени. Пока администратор не будет использовать канонические имена в записях MX, нет никакой гарантии, что сервер не попадет в бесконечный цикл, не найдя других серверов и снова и снова обращаясь к самому себе.
Каждый хост обмена почтой должен иметь соответствующую запись А в файле зоны, что позволит почтовым серверам найти запись с IP-адресом, соответствующую записи MX, и попытаться доставить почту.
Еще одна частая ошибка возникает при настройке почтовых хостов, находящихся в том же домене, что и сервер имен. Часто в организациях почту для нескольких доменов обрабатывают на одном почтовом сервере. Слияния и приобретения компаний делают эту ситуацию еще более распространенной.
Приведенная ниже запись MX показывает, что почтовый сервер для companyabc.com -это сервер mail.companyabc.com.
companyabc.com IN MX 10 mail.companyabc.com
Пока mail.companyabc.com не настроен на распознавание companyabc.com как локального домена, он будет пытаться переслать сообщение самому себе и в результате выдаст ошибку:
554 MX list for companyabc.com points back to mail.companyabc.com
В этой ситуации, если mail.companyabc.com был настроен на то, чтобы не пересылать письма в неизвестные домены, он будет отказывать в доставке почты.
Записи служб (SRV)
Записи служб, или записи SRV указывают, какой ресурсы выполняют определенную службу. Например, на контроллеры домена в Active Directory ссылаются записи SRV, определяющие такие службы, как Global Catalog (глобальный каталог), LDAP и Kerberos. Записи SRV в DNS появились относительно недавно, и в первоначальной реализации их не было.
Каждая запись SRV хранит информацию о функциональности, которую предоставляет определенный ресурс. Например, LDAP-сервер может добавить в DNS запись SRV, которая показывает, что сервер может обрабатывать LDAP-запросы в определенной зоне. Записи SRV широко используются в Active Directory в связи с тем, что контроллеры домена с помощью этих записей могут извещать ресурсы сети о том, что контроллеры могут обрабатывать запросы к глобальному каталогу (GC). Поскольку записи SRV в DNS появились не так давно, некоторые ранние реализации DNS, такие как Unix BIND 4.1 и NT 4.0 DNS, их не поддерживают. Следовательно, окружение DNS, используемое с Windows Server 2003 Active Directory, обязательно должно поддерживать возможность создания записей SRV. Для серверов Unix BIND рекомендуется использовать версию 8.2.1 или выше.