Базовые DNS-записи для почтового сервера

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

Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующим тегам на моем блоге — Postfix и Exchange Server.

Базовые DNS-записи для почтового сервера

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

Рекомендую к прочтению перечень статей ниже:

• Технология DKIM для почтового сервера
• SPF-запись для почтового сервера
  • 10 DNS-запросов для одной SPF-записи

Ну а теперь начнем разбираться что нужно сделать перед созданием записей.

Покупка доменного имени

Начать необходимо с покупки доменного имени. Это не так сложно, как кажется и не так дорого. Новый домен в .ru-зоне может стоить не больше 100-200 рублей.

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

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

A

Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld. Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:

На эту запись в последствии будет указывать MX.

MX

Эта запись переводится как mail-exchanger и, собственно, она и является основной для почтовых серверов. Таких записей может быть несколько и каждая из них обязательно имеет значение приоритета — чем оно меньше, тем приоритет выше. Для чего это используется? Главным образом для определения очередности обращения к MX-записям, если их несколько.

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

Если углубляться в архитектуру почтовых решений, то очень часто запись MX указывает на mail-relay или сервер антиспама (spamassasin, например, или Exchange Server Edge), а не на конечный почтовый сервер, сохраняющий входящие/исходящие письма. Это вполне разумный подход, когда отдельный сервер выступает в качестве пограничного шлюза, а другой — с критически важными данными для бизнеса — своеобразным бэкэндом. Я скажу больше — это даже best practice.

Сколько MX надо для счастья

Сообразительному читателю может прийти в голову очень интересная мысль: «А что лучше — две записи MX или одна запись MX, но ссылающаяся на две одинаковые A-записи?». Визуально это выглядит вот так:

В случае b. получается своеобразный Round Robin. Но, если отбросить нюансы, вариант a. аналогичен! Ведь одинаковый приоритет MX-записей обеспечивает такую же функцию.

Тем не менее, и в этом случае у многих возникают сомнения. Главным образом они обуславливаются мнением, что в случае b., если отправляющий сервер в первой попытке отправки попадет на неработающий сервер, то он отложит отправку и попробует в следующий раз, спустя таймаут. Но это в корне неверно — он попробует отправить на второй сервер из выдачи RR сразу же. Это демонстрирует наглядный эксперимент.

Когда на запросы отвечают оба сервера из варианта b., мы видим следующую запись в smtp-сессии при попытке отправки на них письма (Queued mail for delivery — письмо принято к доставке):

Если же по каким-то причинам один из серверов отключился и отправляющая сторона попала в первую попытку на него, сразу же пойдет вторая попытка отправить почту на второй сервер из выдачи (после Connection timed out в первый раз идет удачная вторая попытка):

А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:

Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google — нет:

Поэтому именно вам решать какой вариант выбрать.

PTR

С PTR нет такого пространства для творчества, как в случае с MX и от этого только легче. PTR-запись принадлежит обратной зоне и призвана сопоставить ip-адрес с DNS-именем (то есть, адрес должен разрешаться в имя).

В самом идеальном случае должно происходить «круговое» разрешение записей. Что это такое, легко понять на примере: из MX получаем A-запись, из A-записи получаем ip-адрес, от этого адреса берем PTR-запись, которая в идеале должна разрешиться в A-запись, на которую указывала MX изначально. И так по кругу:

Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?

Ради интереса давайте проверим тех же публичных провайдеров:

Но! ведь этот же сервер обслуживает и другие домены mail.ru, например list.ru, bk.ru:

Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.

И, самое главное, PTR-запись создается на стороне владельца ip-адреса. То есть, если адреса вам предоставляет интернет-провайдер, запрашивать создание записи вы должны именно у него (в админке или через менеджера).

TXT

TXT — обычная текстовая запись. Она применяется достаточно широко — от подтверждения владения доменом и до использования самыми разными механизмами фильтрации нежелательных/вредоносных сообщений (DKIM, DMARC).

В контексте изучения базовых записей DNS, TXT нас интересует прежде всего с точки зрения использования SPF (Sender Policy Framework).

Назначение SPF очень простое — определить список серверов, которые имеют право отправлять почту от указанных доменов. Не вникая в особенности самого расширения, вы можете легко сгенерировать подходящую SPF для вашего домена, в этом вам помогут многочисленные онлайн-генераторы ².

Ваша запись может иметь следующий вид:

Ничего сложного. Не так ли? На стороне почтового сервера ничего делать не нужно, в этом ещё один плюс SPF.

Никогда не игнорируйте возможность создания записи, даже если имеете дело с тестовой инфраструктурой. Например вот что может вам ответить принимающий сервер, если засомневается в вашей «чистоте» как отправителя:

Это кусок лога SMTP-сессии с сервером Mail.ru. Абсолютно неинформативная ошибка и ответ — 451 Try again later — могут легко ввести в ступор, а безрезультатная гуглежка заставит сильно приуныть. Тем не менее, после создания SPF все стало хорошо и статус вновь отправляемых сообщений изменился на Queued mail for delivery.

В качестве напутствия

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

Также никогда не бойтесь писать вашим коллегам-админам почтовых серверов из других компаний, на адреса которых почему-то не доходят ваши сообщения. И наоборот — всячески помогайте обратившимся к вам админам со стороны. Совместный траблшутинг проблемы сделает опытнее вас обоих.