«DNS и BIND»

5. DNS и электронная почта

Тут Алиса почувствовала, что глаза у нее слипаются.
Она сонно бормотала: - Едят ли кошки мошек? Едят ли кошки мошек? Иногда у нее получалось: - Едят ли мошки кошек?
Алиса не знала ответа ни на первый, ни на второй вопрос, и потому ей было все равно, как их ни задать.

Вероятно, на вас уже тоже напала сонливость, вызванная предыдущей длинной главой. К счастью, эта глава посвящена теме, которая, вероятно, заинтересует системных и почтовых администраторов: взаимодействию DNS и электронной почты. И даже если эта тема вас не интересует, времени на ее обсуждение потребуется гораздо меньше, чем на предыдущую главу.

Одним из преимуществ DNS перед таблицами узлов является усовершенствованная поддержка маршрутизации почты. В те времена, когда почтовым программам был доступен только файл HOSTS.TXT (и его наследник /etc/hosts), они в лучшем случае могли попытаться доставить почту по IP-адресу узла. В случае неудачи оставалось только продолжать периодические попытки отправить письмо или вернуть его отправителю.

В DNS предусмотрены способы указания резервных узлов для передачи почтовых сообщений. Этот механизм позволяет одним узлам выполнять обязанности других узлов, связанные с доставкой почты. Это, к примеру, позволяет возлагать обработку почты для узлов, являющихся бездисковыми станциями, на обслуживающий их сервер.

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

Также можно добавлять в произвольную зону доменные имена, которые будут использоваться только в адресах электронной почты и не связаны с какими-либо конкретными узлами сети. Кроме того, один логический адрес электронной почты может представлять несколько почтовых серверов. Напротив, при использовании таблиц узлов в почтовых адресах можно было употреблять только имена узлов, и все.

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

MX-записи

Для реализации усовершенствованной маршрутизации электронной почты в DNS используется единственный тип RR-записи: MX-запись. Изначально функции MX-записи были поделены между двумя записями: MD-записью (mail destination) и MF-записью (mail forwarder). MD-запись содержала конечный адрес, по которому следует доставить почтовое сообщение, адресованное определенному домену; MF-запись содержала информацию об узле, который передаст почту конечному адресату, если этот адресат не может получить почту обычным маршрутом.

Ранние опыты с использованием DNS в сети ARPAnet показали, что разделение этих функций на практике не очень эффективно. Почтовой программе требовалось наличие как MD-, так и MF-записей для каждого доменного имени, чтобы принять решение о том, куда посылать почтовые сообщения, - одной из них было бы недостаточно. Явный же поиск информации какого-либо одного типа (будь то MD или MF) приводил к кэшированию DNS-сервером записей только этого типа. Так что почтовым программам приходилось либо делать два запроса (по одному на каждый тип записи), либо просто отвергать кэшированные результаты. В результате затраты на маршрутизацию почты значительно превышали затраты на работу остальных служб, что в конечном итоге было сочтено недопустимым.

Для решения проблемы эти типы записей были объединены в один тип - MX. Почтовые программы стали обходиться набором MX-записей для конкретного доменного имени в целях принятия решения по маршрутизации почтовых сообщений. Использование кэшированных MX-записей стало абсолютно допустимым при условии соблюдения значений TTL.

MX-записи определяют почтовый ретранслятор (mail exchanger) для доменного имени, то есть узел, который обработает или передаст дальше почтовые сообщения, предназначенные адресату в указанном домене (например, через брандмауэр). Обработка почты относится либо к доставке почтовых сообщений конечному адресату, либо к передаче их через шлюз другому почтовому транспорту, например X.400. Ретрансляция означает передачу почты конечному домену либо другому почтовому ретранслятору, расположенному «ближе» к конечному адресату в мерах расстояний STMP (Simple Mail Transfer Protocol, интернет-протокол доставки почтовых сообщений). Иногда при ретрансляции почтовые сообщения на некоторое время ставятся в очередь почтового ретранслятора.

Чтобы предотвратить появление петель маршрутизации почты, в записях типа MX, помимо доменного имени почтового ретранслятора, содержится вторичный параметр: приоритет (preference value). Приоритет - это шестнадцатибитное положительное целое (может принимать значения от 0 до 65535), которое определяет приоритет для почтового ретранслятора. Скажем, вот такая MX-запись:

peets.mpk.ca.us.    IN  MX    10 relay.hp.com.

идентифицирует relay.hp.com в качестве почтового ретранслятора для peets.mpk.ca.us с приоритетом 10.

При выборе приоритета почтовых ретрансляторов для конкретного адреса определяют, в каком порядке они будут использоваться почтовой программой. Само по себе значение не особенно важно, важно его отношение к приоритетам, определенным для остальных почтовых ретрансляторов: больше оно или меньше прочих значений? В случае отсутствия других записей следующие записи

plange.puntacana.dr.   IN  MX    1 listo.puntacana.dr.
plange.puntacana.dr.   IN  MX    2 hep.puntacana.dr.

абсолютно эквивалентны таким:

plange.puntacana.dr.   IN  MX    50 listo.puntacana.dr.
plange.puntacana.dr.   IN  MX   100 hep.puntacana.dr.

Почтовые программы должны пытаться доставить почту почтовым ретрансляторам, начиная с тех, которые имеют наименьшие значения приоритета. Может показаться не очень естественным, что наиболее предпочтительный ретранслятор имеет наименьший приоритет. Но, поскольку приоритет суть беззнаковая величина, это позволяет присвоить «лучшему» почтовому ретранслятору приоритет 0.

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

Так, к примеру, могут выглядеть MX-записи для oreilly.com:

oreilly.com.    IN MX     0    ora.oreilly.com.
oreilly.com.    IN MX    10   ruby.oreilly.com.
oreilly.com.    IN MX    10   opal.oreilly.com.

Эти MX-записи дают почтовым программам указания пытаться доставить почту для oreilly.com путем передачи:

1. ora.oreilly.com.
2. Затем один из ruby.oreilly.com или opal.oreilly.com.
3. Оставшийся ретранслятор с приоритетом 10 (тот, который не использовался на шаге 2).

Разумеется, после доставки почты одному из почтовых ретрансляторов oreilly.com процесс опроса прекращается. После успешной доставки почты через ora.oreilly.com нет смысла отправлять ее через ruby.oreilly. com или opal.oreilly.com.

Обратите внимание, что oreilly.com - не узел сети; это доменное имя основной зоны прямого отображения компании O'Reilly. Компания O'Reilly использует это доменное имя в качестве пункта назначения почты для всех, кто в ней работает. Гораздо легче запомнить единственный e-mail, oreilly.com, чем помнить на каком из узлов - ruby.oreilly.com или amber.oreilly.com - в действительности создана учетная запись электронной почты для каждого конкретного сотрудника.

Разумеется, такая система требует, чтобы администратор почтовой программы на ora.oreilly.com вел файл псевдонимов для всех учетных записей электронной почты сотрудников O'Reilly, ретранслируя их почту на машины, с которых сотрудники будут эту почту читать, или создал сервер, позволяющий пользователям читать свою почту удаленно по протоколу POP или IMAP.

Что произойдет, если ни одной MX-записи для пункта назначения не существует, но присутствует хотя бы одна A-запись? Неужели почтовая программа попросту не доставит почту в пункт назначения? Разумеется, более поздние версии программы sendmail можно собрать именно с таким алгоритмом работы. Тем не менее большинство поставщиков собирает sendmail с более мягким алгоритмом: если не существуют MX-записи, но существует хотя бы одна A-запись, будут делаться попытки доставить почту для указанного адреса. Версия 8 программы sendmail, собранная «из коробки», пытается доставить почту по указанным адресам в отсутствие MX-записей. Сверьтесь с документацией, включенной в поставку системы, если необходимо уточнить, посылает ли почтовый сервер сообщения по указанным адресам в случае наличия одной лишь адресной записи.

Несмотря на тот факт, что практически все почтовые программы доставляют сообщения по соответствующим адресам даже в случае присутствия только адресной записи, имеет смысл создать хотя бы по одной MX-записи для каждого допустимого пункта назначения. При необходимости доставить почтовые сообщения большинство почтовых программ, включая sendmail, прежде всего проверяет наличие MX-за- писей для указанных пунктов назначения. Если таковые отсутствуют, DNS-сервер - обычно один из авторитетных - все равно должен среагировать на этот запрос, после чего sendmail переходит к поиску A-записей. Это занимает дополнительное время, замедляет процесс доставки почтовых сообщений и создает дополнительную нагрузку на авторитетные DNS-серверы вашей зоны. Если же просто добавить MX-запись для каждого пункта назначения, указав доменное имя, которое отображается в тот же самый адрес, что и возвращаемый поиском по адресным записях, почтовой программе останется отправить единственный запрос, после чего локальный DNS-сервер почтовой программы кэширует эту MX-запись для последующего использования.

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