Базовые DNS-записи для почтового сервера
- Базовые DNS-записи для почтового сервера
- Базовые DNS-записи для почтового сервераПокупка доменного имениВ качестве напутствия
- Покупка доменного имени
- В качестве напутствия
Для меня загадка почему развертывание даже примитивной конфигурации почтового сервера для многих системных администраторов является столь серьезной проблемой. Тем не менее, это так. Мне бы никогда не пришло в голову писать об этом целую статью, но судя по неиссякаемому количеству вопросов, это сделать все же необходимо. Больше всего сложностей вызывают базовые DNS-записи для почтового сервера, о них и поговорим.
- – это индивидуальный, уникальный
адрес в интернете или локальной сети. - – это любое устройство или
компьютер, подключенное к Интернету. - – электронная почта домена, почтовый
сервис предоставляется в настоящее время всеми хостинг-провайдерами.
Указывается адрес администратора. - – учетная запись, идентифицирующая
почту, указывает на почтовый сервер для обмена почтой домена. - указывает допустимое время, которое
сохраняется кэш ресурсной записи на неответственном DNS- сервере. - – необходим вторичным
серверам для проверки изменения Зоны. - – это те записи, которые указывают
на сервер имен для конкретного домена, важнейшая функция NS это делегирование
домена. - указывает на сервер, хранящий
начальную (эталонную) информацию о домене. - перенаправляет имя хоста на другое
имя, псевдоним. - определяет класс используемых сетей.
- предназначается для дополнительной
информации, которую может указать владелец домена. - — указание на серверы для сервисов
(в частности, Active Directory и Jabber).
Я все это дело предпочитаю проверять на юниксовой машине, поэтому команды оттуда
1. Команда dig — имя домена
gate# dig mail.ru
;; global options: +cmd
;; Got answer:
;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY:
6, ADDITIONAL: 3
;; QUESTION SECTION:
;mail.ru.
IN A
;; ANSWER SECTION:
mail.ru.
48 IN A
94.100.191.247
mail.ru.
48 IN A
94.100.191.248
mail.ru.
48 IN A
94.100.191.249
mail.ru.
48 IN A
94.100.191.250
mail.ru.
48 IN A
94.100.191.201
mail.ru.
48 IN A
94.100.191.202
mail.ru.
48 IN A
94.100.191.203
mail.ru.
48 IN A
94.100.191.204
mail.ru.
48 IN A
94.100.191.205
mail.ru.
48 IN A
94.100.191.206
mail.ru.
48 IN A
94.100.191.207
mail.ru.
48 IN A
94.100.191.208
mail.ru.
48 IN A
94.100.191.209
mail.ru.
48 IN A
94.100.191.210
mail.ru.
48 IN A
94.100.191.241
mail.ru.
48 IN A
94.100.191.242
mail.ru.
48 IN A
94.100.191.243
mail.ru.
48 IN A
94.100.191.244
mail.ru.
48 IN A
94.100.191.245
mail.ru.
48 IN A
94.100.191.246
;; AUTHORITY SECTION:
mail.ru.
143 IN NS
ns2.mail.ru.
mail.ru.
143 IN NS
ns4.mail.ru.
mail.ru.
143 IN NS ns3.mail.ru.
mail.ru.
143 IN NS
ns1.mail.ru.
mail.ru.
143 IN NS
ns.mail.ru.
mail.ru.
143 IN NS
ns5.mail.ru.
;; ADDITIONAL SECTION:
ns.mail.ru.
544 IN A 217.69.129.230
ns.mail.ru.
561 IN AAAA
2a00:1148:1:1322::1:c0de
ns1.mail.ru.
359 IN A
94.100.179.159
;; Query time: 5 msec
;; SERVER: 195.94.224.4#53(195.94.224.4)
mx-записи нет (
gate# host -t mx
mail.ru
mail.ru mail is
handled by 10 mxs.mail.ru.
Что то похоже — mxs.mail.ru
mail.ru mail exchanger
= 10 mxs.mail.ru.
Authoritative answers
can be found from:
mail.ru nameserver =
ns5.mail.ru.
mail.ru nameserver =
ns2.mail.ru.
mail.ru nameserver =
ns1.mail.ru.
mail.ru nameserver =
ns4.mail.ru.
mail.ru nameserver =
ns.mail.ru.
mail.ru nameserver =
ns3.mail.ru.
mxs.mail.ru internet address = 94.100.176.20
ns.mail.ru internet address = 217.69.129.230
ns.mail.ru has AAAA address 2a00:1148:1:1322::1:c0de
ns1.mail.ru internet address = 94.100.179.159
ns1.mail.ru has AAAA address 2a00:1148:1:1311::1:a002
ns2.mail.ru internet address = 94.100.186.189
ns2.mail.ru has AAAA address 2a00:1148:1:1322::1:a003
ns3.mail.ru internet address = 94.100.179.93
ns3.mail.ru has AAAA address 2a00:1148:1:1311::1:a001
ns4.mail.ru internet address = 94.100.178.100
ns4.mail.ru has AAAA address 2a00:1148:1:1310::1:b0de
ns5.mail.ru internet address = 217.69.129.241
ns5.mail.ru has AAAA address 2a00:1148:1:1322::1:a002
тут уже видно, что и как 🙂
В windows в принципе есть похожие команды, по крайней мере — nslookup
Базовые DNS-записи для почтового сервера
В статье рассмотрены базовые записи, которые либо необходимы, либо крайне желательны для нормального функционирования почтового сервера.
Рекомендую к прочтению перечень статей ниже:
- Технология DKIM для почтового сервера
- SPF-запись для почтового сервера
- 10 DNS-запросов для одной SPF-записи
Ну а теперь начнем разбираться что нужно сделать перед созданием записей.
Покупка доменного имени
Начать необходимо с покупки доменного имени. Это не так сложно, как кажется и не так дорого. Новый домен в .ru-зоне может стоить не больше от 100-1000 рублей.
Как только домен куплен, можно приступать к созданию записей. У всех регистраторов разные админки, но зная теорию, в специфике добавления записей разобраться проще простого.
Примечание: когда вы указываете A-запись, на которую ссылается CNAME при её создании, у некоторых регистраторов может потребоваться прописывать A-запись полностью с точкой (например record.bissquit.com.), а у кого-то достаточно вписать просто часть до домена (просто record без всего, как в прошлом примере).
Хочу сразу предупредить, что распространение только что созданных записей занимает некоторое время, обычно это от 15 минут и до нескольких часов (или в теории даже суток, но мне такое не встречалось).
Первым делом создайте основную A-запись, которая будет указывать на внешний адрес вашего почтового сервера. Допустимы любые варианты, но обычно выбирают что-то похожее на mail.domain.tld или mx1.domain.tld. Если вы используете собственный DNS-сервер bind, то A-запись внутри зоны может выглядеть так:
mail IN A 1.2.3.4
На эту запись в последствии будет указывать MX.
Эта запись переводится как mail-exchanger и, собственно, она и является основной для почтовых серверов. Таких записей может быть несколько и каждая из них обязательно имеет значение приоритета — чем оно меньше, тем приоритет выше. Для чего это используется? Главным образом для определения очередности обращения к MX-записям, если их несколько.
Часто встречается, что несколько MX-записей для одного и того же домена имеют одинаковый приоритет. В этом случае входящий трафик будет равномерно балансироваться между серверами.
Примечание: строго говоря, наличие связанной MX-записи для вашего отправляющего сервера не так уж и обязательно. Отправить почту вы сможете без проблем и серверы целевого домена её даже получат. Но, вероятно, на принимающих серверах почта мгновенно попадет в спам, поскольку отправляющие домены без MX сразу же помечаются как подозрительные. Возникнуть проблемы могут также и с получением почты, хотя в теории доставка письма в отсутствии записи MX должна выполняться на основную A-запись домена (согласно RFC 5321 1).
Сколько MX надо для счастья
Сообразительному читателю может прийти в голову очень интересная мысль: «А что лучше — две записи MX или одна запись MX, но ссылающаяся на две одинаковые A-записи?». Визуально это выглядит вот так:
В случае b. получается своеобразный Round Robin. Но, если отбросить нюансы, вариант a. аналогичен! Ведь одинаковый приоритет MX-записей обеспечивает такую же функцию.
Тем не менее, и в этом случае у многих возникают сомнения. Главным образом они обуславливаются мнением, что в случае b., если отправляющий сервер в первой попытке отправки попадет на неработающий сервер, то он отложит отправку и попробует в следующий раз, спустя таймаут. Но это в корне неверно — он попробует отправить на второй сервер из выдачи RR сразу же. Это демонстрирует наглядный эксперимент.
Когда на запросы отвечают оба сервера из варианта b., мы видим следующую запись в smtp-сессии при попытке отправки на них письма (Queued mail for delivery — письмо принято к доставке):
Примечание: если кого-то заинтересует дилемма выбора «правильной» иерархии MX, советую обратиться к топику DNS — MX, A, TLL и почтовый сервер на форумах Technet. Пример с логами отправки взят именно оттуда, я же являюсь и его автором.
А теперь вернемся от теории к практике и посмотрим как же обстоят дела у крупных публичных почтовых сервисов:
# dig -t MX mail.ru +short
10 mxs.mail.ru.
# dig -t A mxs.mail.ru +short
94.100.180.104
94.100.180.31
#
#
# dig -t MX yandex.ru +short
10 mx.yandex.ru.
# dig -t A mx.yandex.ru +short
213.180.204.89
77.88.21.89
213.180.193.89
87.250.250.89
93.158.134.89
Mail и Yandex используют для своих сервисов именно вариант с RR для A-записей, а вот Google — нет:
# dig -t MX gmail.com +short
5 gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
Поэтому именно вам решать какой вариант выбрать.
Но в реальности это явно избыточный перфекционизм. К тому же, что вы будете делать, если ваш сервер будет обслуживать несколько доменов одновременно (а ведь это очень частая ситуация)?
Ради интереса давайте проверим тех же публичных провайдеров:
# dig -t MX mail.ru +short
10 mxs.mail.ru.
# dig -t A mxs.mail.ru +short
94.100.180.104
94.100.180.31
# dig -x 94.100.180.104 +short
mxs.mail.ru.
Но! ведь этот же сервер обслуживает и другие домены mail.ru, например list.ru, bk.ru:
# dig -t MX bk.ru +short
10 mxs.mail.ru.
Ну и, разумеется, их адреса будут иметь PTR абсолютно не связанную с именем, например, bk.ru. Таким образом, по сути жесткое соответствие не обязательно и вы можете использовать PTR с любым вашим доменным именем. Главное, чтобы запись существовала, ведь очень много серверов проверяют наличие PTR и, если её нет, резко повышают спам-рейтинг ваших сообщений.
TXT — обычная текстовая запись. Она применяется достаточно широко — от подтверждения владения доменом и до использования самыми разными механизмами фильтрации нежелательных/вредоносных сообщений (DKIM, DMARC).
В контексте изучения базовых записей DNS, TXT нас интересует прежде всего с точки зрения использования SPF (Sender Policy Framework).
Примечание: как и PTR, SPF тоже не является обязательной, но её наличие резко повышает шансы пройти антиспам-фильтры получателя. Скажем так: как минимум любую из двух записей вы иметь просто обязаны.
Назначение SPF очень простое — определить список серверов, которые имеют право отправлять почту от указанных доменов. Не вникая в особенности самого расширения, вы можете легко сгенерировать подходящую SPF для вашего домена, в этом вам помогут многочисленные онлайн-генераторы 2.
Ваша запись может иметь следующий вид:
bq-srv.ru. IN TXT «v=spf1 ip4:1.2.3.4 ~all»
Ничего сложного. Не так ли? На стороне почтового сервера ничего делать не нужно, в этом ещё один плюс SPF.
Никогда не игнорируйте возможность создания записи, даже если имеете дело с тестовой инфраструктурой. Например вот что может вам ответить принимающий сервер, если засомневается в вашей «чистоте» как отправителя:
Это кусок лога SMTP-сессии с сервером Mail.ru. Абсолютно неинформативная ошибка и ответ — 451 Try again later — могут легко ввести в ступор, а безрезультатная гуглежка заставит сильно приуныть. Тем не менее, после создания SPF все стало хорошо и статус вновь отправляемых сообщений изменился на Queued mail for delivery.
В качестве напутствия
Также никогда не бойтесь писать вашим коллегам-админам почтовых серверов из других компаний, на адреса которых почему-то не доходят ваши сообщения. И наоборот — всячески помогайте обратившимся к вам админам со стороны. Совместный траблшутинг проблемы сделает опытнее вас обоих.
Даже без MX записи письмо должно дойти. Согласно RFC, если MX запись не найдена, то будет предпринята отправки письма через A запись. Это не будет работать в 100% случаев
