Думаю, многим будет интересно наконец-то узнать, как работает почта. В нескольких статьях я попытаюсь максимально простым языком расписать все основные вопросы, связанные с работой электронной почты вообще и нужными настройками - в частности.
Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию:
1 доменное имя (example.com).
1 почтовый домен (*@example.com).
1 почтовый сервер (mail.example.com).
1 IP-адрес (127.127.127.127).
Касательно почты, в DNS нас интересует четыре типа записей.
Второй - желательный, без него почта будет отправлятся на А запись. Без остальных, в принципе, можно обойтись, но шансы, что ваше письмо будет отвергнуто как спам возрастают в разы - тот же mail.ru отбрасывает практически всю почту, чьи IP-адреса не имеют PTR, либо PTR относится к dial-up провайдерам. И это правильно.
A (Address) - запись, указывающая IP-адрес нужного нам доменного имени. Для корректной работы почты требуется A-запись сервера почты (mail.example.com). Выглядеть, в нашем случае, она будет так:
mail IN A 127.127.127.127
Где:
mail - домен.
IN A - тип записи.
127.127.127.127 - IP нашего почтового сервера.
MX (Mail eXchange) - основная DNS-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена.
У нас есть один почтовый домен - @example.com. И один почтовый сервер - mail.example.com. Соответственно, запись будет выглядеть так:
example.com. IN MX 10 mail.example.com
Где:
example.com - домен, для которого обробатывается почта.
IN MX - тип записи.
10 - приоритет записи (Подробнее - ниже).
mail.example.com - A-имя почтового сервера.
MX-запись должна указывать именно на A-запись почтового сервера. Ставить MX указателем на IP или CNAME - не правильно.
Приоритет MX-записи нужен тогда, когда существует больше одного почтового сервера для одного домена (например у Google Mail их шесть). Он указывает, к какому серверу идет обращение в первую очередь, во вторую и так далее (если первый (второй, десятый) сервер недоступен или перегружен или по другим причинам не может принять письмо). Логика простая - приоритетнее тот, цифра которого меньше. Порядок цифр - не ограничен, хоть 10-20-30, хоть 1000-2000-3000.
Если у домена нет ни одной MX-записи, либо ни один из MX-серверов не доступен, сервер отправителя попытается доставить почту на IP, указанный в A-записи домена. Это назвается А-доставкой, но в принципе не кошерно и не используется многими серверами - нужно указывать MX, даже если он всего один.
PTR (PoinTeR) - так называемая «обратная запись». Она позволяет обратное разрешение (reverse resolving) IP-адреса в FQDN-хост.
Наш IP в виде reverse будет выглядеть так: 127.127.127.127.in-addr.arpa. В данном примере видно плохо, но адрес инвертируется в обратной зоне. Т.е. IP 192.168.0.1 будет выглядеть как 1.0.168.192.in-addr.arpa.
Для корректного распознования хоста, запись IP-адреса, с которого отправляется должна соответсовать hostname почтового сервера, отправляемому в HELO\EHLO.
PTR-запись в нашем случае, соответственно:
127.127.127.127.in-addr.arpa IN PTR mail.example.com.
Прописать эту запись может владелец блока IP-адресов (Читайте мою статью про распределение адресного пространства). Если вы таковым не являетесь и получили адреса от провайдера - обращайтесь к вашему провайдеру или дата-центру, чтобы запись установил он.
TXT (TeXT) - текстовая запись DNS. Нам она интересна только тем, что может (и в современном мире - должна) содержать в себе SPF.
SPF (Sender Policy Framework) - запись, позволяющая вам указать, какие сервера имеют право отправлять почту от имени вашего домена (представившись вашим сервером, либо с обратным адресом в вашем домене).
Если этой записи нет, и кто-то пытается отправить письмо (как правило, спам) с обратным адресом в вашем домене - оно будет отклонено большинством серверов. Или не будет, и вы получите большие проблемы со своим дата-центром или провайдером и репутацию спамера 🙂
SPF-запись выглядит так:
v=spf1 ip4:1.1.1.1 +a +mx -all (пример).
v=spf1 - версия протокола.
(+\-)a - разрешение или запрет отправки почты с IP, соответствующего A-записи домена.
(+\-)mx - разрешение или запрет отправки почты с IP, соответствующего MX-записи домена.
ip4:IP - явное указание IP, с которого можно принимать почту от имени домена.
(~\-all) - отвергать или принимать почту от IP, не перечисленных в списке и не указанных явно.
В нашем случае TXT SPF запись будет такой:
example.com. IN TXT «v=spf1 +mx +a -all»
Таким образом, мы разрешили прием почты от имени домена с IP, соотвествующих A или MX записям и запретили прием от других адресов - никто не сможет наспамить прикинувшись нами или обмануть наших пользователей, отправив фишинговую ссылку от имени тех. поддержки.
Руководство для системных администраторов
Тут Алиса почувствовала, что глаза у нее слипаются.
Она сонно бормотала: - Едят ли кошки мошек? Едят ли кошки мошек? Иногда у нее получалось: - Едят ли мошки кошек?
Алиса не знала ответа ни на первый, ни на второй вопрос, и потому ей было все равно, как их ни задать.
Вероятно, на вас уже тоже напала сонливость, вызванная предыдущей длинной главой. К счастью, эта глава посвящена теме, которая, вероятно, заинтересует системных и почтовых администраторов: взаимодействию DNS и электронной почты. И даже если эта тема вас не интересует, времени на ее обсуждение потребуется гораздо меньше, чем на предыдущую главу.
Одним из преимуществ DNS перед таблицами узлов является усовершенствованная поддержка маршрутизации почты. В те времена, когда почтовым программам был доступен только файл HOSTS.TXT (и его наследник /etc/hosts), они в лучшем случае могли попытаться доставить почту по IP-адресу узла. В случае неудачи оставалось только продолжать периодические попытки отправить письмо или вернуть его отправителю.
В DNS предусмотрены способы указания резервных узлов для передачи почтовых сообщений. Этот механизм позволяет одним узлам выполнять обязанности других узлов, связанные с доставкой почты. Это, к примеру, позволяет возлагать обработку почты для узлов, являющихся бездисковыми станциями, на обслуживающий их сервер.
В отличие от таблиц узлов, DNS позволяет использовать в адресах электронной почты произвольные имена. Возможно - что и делает большинство организаций в сети Интернет - использовать доменное имя основной зоны прямого отображения в адресе электронной почты.
Также можно добавлять в произвольную зону доменные имена, которые будут использоваться только в адресах электронной почты и не связаны с какими-либо конкретными узлами сети. Кроме того, один логический адрес электронной почты может представлять несколько почтовых серверов. Напротив, при использовании таблиц узлов в почтовых адресах можно было употреблять только имена узлов, и все.
В целом, перечисленные возможности предоставляют администраторам гораздо больше свободы в настройке маршрутизации электронной почты в сетях.
Для реализации усовершенствованной маршрутизации электронной почты в 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 путем передачи:
Разумеется, после доставки почты одному из почтовых ретрансляторов 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-адрес , но это относится далеко не ко всем программам, поэтому вы будете испытывать непредсказуемые проблемы с почтой.
Если у вас возникла необходимость управлять DNS-записями домена и при этом не предоставляет такой возможности, можно воспользоваться сторонними неймсерверами, например, бесплатной услугой «Яндекс DNS-хостинг», который идет в комплекте с «Яндекс Почтой для домена». В данной статье будет рассмотрено:
Сначала необходимо зарегистрировать учетную запись на Яндексе. Если у вас уже есть учетная запись, пожалуйста, перейдите к следующему разделу «Подключение домена к Яндекс».
После заполнения всех необходимых полей и подтверждения номера телефона путем ввода проверочного СМС-кода, рекомендуем зайти в детали учетной записи, нажав на ее имя в правом верхнем углу, и, выбрав раздел «Паспорт», указать персональные данные: в частности, контрольный вопрос и ответ на него. Данная информация упростит восстановление доступа к учетной записи, если будет утерян пароль или логин.
После этого можно приступить к подключению домена.
Осуществив вход в учетную запись, необходимо подключить домен. Это можно сделать по ссылке: https://pdd.yandex.ru/domains_add/
Также можно зайти в «Почту для домена» таким образом: в учетной записи в строке с доступными услугами нажать «еще», в выпадающем меню выбрать «Все сервисы».
После этого выберите пункт «Почта для домена».
Введите имя домена и нажмите «Подключить домен». После этого произойдет автоматическая переадресация на страницу подтверждения права владения доменом.
Делегирование домена на Яндекс подразумевает направление домена на соответствующие публичные неймсерверы и получение возможности управления DNS-записями в функционале этого сервиса. Если делегировать домен в течение суток после его подключения и при этом подключение не осуществлялось ранее в другой учетной записи Яндекса, то домен будет успешно делегирован после того, как пройдет процесс обновления DNS-записей (может занять до 72 часов с момента смены неймсерверов в панели регистратора). В ином случае вам потребуется подтвердить владение доменом.
Для делегирования домена на Яндекс укажите неймсерверы dns1.yandex.net и dns2.yandex.net в панели доменного регистратора. Если в функционале регистратора домена есть поля для указания IP-адресов неймсерверов - их заполнять не нужно.
После обновления DNS-записей статус домена будет изменен на «Домен подключен и делегирован на Яндекс»:
Для того, чтобы подтвердить владение доменом, есть 3 альтернативных метода, представленных ниже:
Если у вас уже есть размещенный на хостинге сайт, в его корневой каталог потребуется загрузить html-файл с именем и содержимым, указанными на странице «Мои домены ».
Для указанного поддомена настройте CNAME запись на адрес mail.yandex.ru.(с точкой в конце). Для этого необходимо иметь доступ к редактированию DNS записей у регистратора доменного имени или хостингового провайдера.
Если у вас с нами активна услуга виртуального хостинга, указать CNAME запись можно в хостинговой панели cPanel в разделе «Домены» - «Простой редактор DNS-зон» или «Расширенный редактор DNS-зон».
Если вы приобрели ВПС у сайт, то редактировать DNS-записи Вы можете в панели SolusVM согласно нашему руководству .
Добавленная CNAME-запись будет выглядеть таким образом:
Укажите e-mail со страницы «Мои домены » в качестве контактного почтового адреса регистранта домена. Обычно это можно сделать в функционале регистратора доменных имен. После того, как владение доменом будет подтверждено, можете снова изменить email на изначальный.
После того, как выполните действия согласно выбранному способу подтверждения, нажмите «Проверить владение доменом». Пожалуйста, обратите внимание, что процесс обновления DNS-записей занимает некоторое время и домен может быть подтвержден не сразу. В таком случае Яндекс также будет осуществлять автоматическую проверку через определенные промежутки времени. После подтверждения права владения доменом его статус домена на странице «Мои домены» изменится на «Ожидаем установки MX-записей», если домен еще не был направлен на публичные нейсерверы Яндекса. В таком случае обратитесь, пожалуйста, к разделу «Делегирование домена» в текущем руководстве, чтобы делегировать домен на Яндекс.
Если домен уже был ранее направлен на неймсерверы Яндекса, после обновления DNS-записей статус домена будет изменен на «Домен подключен и делегирован на Яндекс».
После делегирования домена на страничке «Мои домены », в его деталях появится такой (указано на скриншое) функционал:
Для управления DNS-записями необходимо перейти в «Редактор DNS».
Поскольку домен уже был делегирован на Яндекс, будут автоматически добавлены DNS-записи, необходимые для работы Яндекс.Почты и Jabber на вашем домене. Можно перенести DNS-записи с предыдущих неймсерверов на неймерверы Яндекса. Для этого нажмите «Перенести NS-записи», проверьте их корректность и нажмите «Перенести».
При необходимости добавьте недостающие записи. Если запись добавляется для основного домена, в поле «Хост» оставьте значок «@». Если запись добавляется для поддомена, укажите часть имени поддомена без имени основного домена. Выберите тип DNS-записи, введите значение и нажмите «Добавить DNS-запись». Например, для поддомена my.domain.com А-запись будет выглядеть так:
Для корректной работы сайта необходимо наличие таких DNS-записей:
| Хост | Тип | Значение записи |
|---|---|---|
| @ | A | XXX.XXX.XXX.XXX |
| * | A | XXX.XXX.XXX.XXX |
Вместо XXX.XXX.XXX.XXX укажите IP-адрес хостинга, с которого должен открываться сайт.
Пример DNS-записей для домена приведен ниже:
Ищете, где ? Мы предлагаем отличный . Если вы хотите или виртуальный хостинг, то вы можете заказать не только , но также получить -сертификат в подарок для виртуального хостинга на тарифе S4 и для VDS-плана xVPS40.
Для правильной работы почтового сервера важно иметь правильно настроенную DNS зону. В мы уже касались некоторых аспектов, связанных с системой DNS, сегодня мы остановимся на этом вопросе более подробно. Настройка DNS зоны относится к подготовительным операциям перед развертыванием почтового сервера и от нее непосредственно зависит работоспособность системы электронной почты.
Неправильные настройки способны привести к тому, что почту будет невозможно доставить вашему почтовому серверу или сервера получателей будут отклонять вашу почту. Действительно, если записи вашей зоны не содержат сведений о почтовом сервере, куда должна отправляться почта? На деревню дедушке? Можно, конечно, попросить настроить DNS зону вашего провайдера, но лучше сделать это самим.
Что нам понадобиться? Выделенный IP адрес (допустим 11.22.33.44), который вы должны получить у своего провайдера. Доменное имя (например example.com), его можно зарегистрировать у любого регистратора или их партнера. При регистрации у партнера уточняйте, предоставляет ли он доступ к управлению DNS зоной, иначе придется потратить дополнительное время, нервы и деньги на перенос домена к регистратору.
Если у вас уже есть домен и, скорее всего, на нем функционирует сайт, уточните, возможно ли управление DNS зоной из панели хостинг провайдера, в противном случае лучше перенести домен к регистратору, для этого обратитесь в поддержку провайдера.
Итак, домен у нас есть. Какие записи содержит его DNS зона? Во первых это SOA запись - описание зоны. Мы не будем подробно разбирать все записи, это выходит за рамки нашей статьи, но иметь общее представление о них необходимо. Также должны быть две NS записи, указывающие на сервера имен (DNS сервера) обслуживающие данный домен, это будут сервера регистратора или хостинг провайдера.
Первой записью, которую необходимо добавить будет A запись или запись имени. Она должна указывать на IP-адрес вашего сервера, если вы решите обслуживать все запросы к домену у себя или на IP адрес хостинг провайдера, если решите разместить свой сайт на хостинге. При размещении сайта у хостера домен обычно делегируется на его DNS сервера (прописываются соответствующие NS записи) и A запись будет сделана автоматически при парковке домена.
Чаще всего встречается этот вариант, но при необходимости вы всегда сможете создать A запись сами. Данная запись имеет вид
Example.com. IN A 22.11.33.44
В нашем примере 22.11.33.44 адрес нашего хостинг провайдера, у которого расположен сайт. Обратите внимание на точку в конце имени, это указывает что имя абсолютное, при отсутствии точки имя считается относительным и к нему добавляется доменное имя из SOA. Проверить запись можно командой nslookup .
Для работы почтового сервера нужно создать MX запись, которая должна указывать на наш почтовый сервер. Для этого создадим запись:
Example.com. IN MX 10 mail.example.com.
Также можно написать просто:
Example.com. IN MX 10 mail
К такому имени (без точки на конце) example.com будет добавлено автоматически. Цифра 10 определяет приоритет сервера, чем она меньше, тем выше приоритет. Кстати, DNS зона уже может содержать MX запись вида:
Example.com. IN MX 0 example.com.
Oбычно эта запись автоматически создается хостинг провайдером при размещении сайта, ее нужно удалить.
Теперь создадим A запись для mail.example.com
Mail.example.com. IN A 11.22.33.44
Теперь вся почта для домена example.com будет направляться хосту mail имеющему адрес 11.22.33.44, т.е. вашему почтовому серверу, в то-же время сайт example.com продолжит работать на сервере провайдера по адресу 22.11.33.44.
Может возникнуть вопрос, а почему нельзя сразу указать в MX записи IP адрес почтового сервера? В принципе можно, некоторые так и делают, но это не соответствует спецификациям DNS.
Также можно сделать алиасы для почтового сервера типа pop.example.ru и smtp.example.ru . Зачем это надо? Это позволит клиенту не зависеть от особенностей вашей инфраструктуры, один раз прописав настройки. Допустим, что ваша компания разрослась и выделила для обслуживания внешних клиентов отдельный почтовый сервер mail1 , все что вам понадобиться, это изменить две DNS записи, клиенты и не заметят того, что работают с новым сервером. Для создания алиасов используются записи типа CNAME:
Pop IN CNAME mail.example.com.
smtp IN CNAME mail.example.com.
На этом настройку прямой DNS зоны можно считать законченной, остается самое интересное - обратная зона. Обратная зона управляется провайдером, выдавшим вам IP адрес и самостоятельно управлять ей вы не можете (если только вы не владелец блока IP адресов). Но добавить как минимум одну запись в обратную зону необходимо. Как мы писали в прошлой статье, многие почтовые сервера проверяют PTR записи (записи обратной зоны) для отправляющего сервера и при их отсутствии или несовпадении с доменом отправителя такое письмо будет отклонено. Поэтому попросите провайдера добавить для вас запись вида:
44.33.22.11.in-addr.arpa. IN PTR mail.example.com.
Немного странный вид, не правда ли? Разберем структуру PTR записи более подробно. Для обратного преобразования имен используется специальный домен верхнего уровня in-addr.arpa. Это сделано для того, чтобы использовать для прямого и обратного преобразования имен одни и те же программные механизмы. Дело в том, что мнемонические имена пишутся слева направо, а IP адреса справа налево. Так mail.example.com. означает что хост mail находится в домене example, который находится в домене верхнего уровня com., 11.22.33.44 означает что хост 44 находится в подсети 33, которая входит в подсеть 22, принадлежащую сети 11. Для сохранения единого порядка PTR записи содержат IP адрес "задом наперед" дополненный доменом верхнего уровня in-addr.arpa.
Проверить MX и PTR записи также можно командой nslookup используя дополнительный параметр -type=MX или -type=PTR
Ну и конечно не стоит забывать, что любый изменения в DNS зонах происходят не мгновенно, а в течении нескольких часов или даже суток, необходимых для распространения изменений в мировой системе DNS. Это означает, что несмотря на то, что почтовый сервер у вас начнет работать через 2 часа после внесения изменений, у вашего партнера почта может не отправляться к вам в течении более длительного времени.
4 февраля 2016 в 16:05В прошлом году мы запустили бесплатный DNS-хостинг на «Mail.Ru для бизнеса», а недавно он вышел из бета-тестирования. Сегодня я хочу рассказать, как мы его делали, какие технические решения принимались, и немного о том, как мы запускались на всю аудиторию.
Мы внимательно прислушиваемся к пожеланиям наших пользователей и ведем учет всех хотелок. В этом списке DNS-хостинг стабильно держался в первых строчках. В результате мы решили две задачи: реализовали дополнительную услугу, о которой просили многие, и добавили еще один способ подтверждения домена для новых клиентов. К тому же после перехода на наш DNS-хостинг все необходимые для работы почты DNS-записи добавляются автоматически.
BIND - самый популярный сервер, имеет хорошую документацию, и, наверное, можно найти ответ на любой вопрос по нему. Однако он не умеет работать с БД из коробки. Есть, конечно, DLZ-патч, но последнее обновление датируется 2013 годом. Не отличается высокой производительностью.
NSD - безусловный лидер по скорости и потребляемым ресурсам, но вот ни с чем, кроме файлов, он работать не умеет. На практике это значит, что нужно писать скрипт, который с периодичностью достает все записи из базы, пишет их в файл и делает reload NSD.
PowerDNS имеет хорошую производительность, умеренно использует ресурсы сервера. Имеет много полезных и не очень родных патчей. Умеет работать с PostgreSQL из коробки.
В конечном счете при выборе между высокой производительностью NSD и хорошей производительностью и простотой работы PowerDNS победил PowerDNS.
Работать с PowerDNS - одно удовольствие: вносишь изменения в БД, а он сам их подхватывает. К тому же, так как все данные берутся из базы, не приходится настраивать master-slave на стороне PowerDNS, а можно переложить их репликацию на базу.
Мы стремились сделать регистрацию на «Mail.Ru для бизнеса» простой и удобной. Сейчас она работает следующим образом. Предположим, вы владеете доменом bestcompanyever.ru и хотите зарегистрироваться. Вы добавляете домен bestcompanyever.ru на нашем сайте, мы выдаем вам пару доменов для NS-записей. После того как вы их пропишете, вам станет доступно управление почтой и DNS-записями.
Однако возможна ситуация, когда два человека попытаются зарегистрировать bestcompanyever.ru в одно и то же время. Для таких случаев необходим алгоритм, который позволит выявлять настоящего владельца домена и выдавать ему права на управление почтой и DNS-сервером для этого домена.
Самое простое решение - выдавать имена в стандартном формате: dns1.mail.ru, dns2.mail.ru и т. д., а для идентификации использовать уникальное сочетание записей. Скажем, первому пользователю, добавившему bestcompanyever.ru, предлагается прописать dns7.mail.ru и dns23.mail.ru, а второму - dns3.mail.ru и dns84.mail.ru. Затем мы сверяем, какая пара NS-записей прописана для домена, и на основе этого определяем, кто истинный владелец. Казалось бы, отличная система - но есть нюанс. Часто пользователи, получив, например, dns3 и dns84 в качестве своих записей, прописывают и все остальные в этом диапазоне: dns3, dns4, dns5, dns6 и т. д. Никаких бонусов это не дает: единственное, что получает пользователь в результате таких действий, - это ошибка при верификации домена. Чтобы избежать таких ситуаций, мы выдаем имена, где последовательность неочевидна. Для этого мы задействовали названия городов. Сейчас у нас два списка по 50 городов.
Каждый, кто регистрируется в «Mail.Ru для бизнеса», получает одну запись из каждого списка. Это дает 2500 уникальных комбинаций, что гарантирует однозначную идентификацию владельца домена, даже если несколько человек пытаются зарегистрировать один домен.
После того как регистрация завершена, имена серверов теряют техническое значение. Независимо от того, по какому из адресов придет запрос, мы всегда отдадим запрашиваемые записи.
Безусловно, этот сценарий сложный, дорогой, и в целом доменов, из-за которых стоило бы так мучиться, не так уж много. Решили эту проблему следующим образом: добавили ограничение на количество неподтвержденных доменов с одним именем, причем для каждого домена гарантированно генерируется уникальная пара.
Пользуясь случаем, хочу напомнить, что у Mail.Ru Group есть программа поиска уязвимостей . Если ты, пытливый читатель, найдешь баги в DNS-хостинге (как и в целом на biz.mail.ru), ты можешь заработать плюс в карму и денег, подав заявку.
В случае с DNS-хостингом у нас был список пользователей, которые очень-очень хотели его попробовать. Они были включены в группу закрытого бета-тестирования. Этот шаг позволил нам выявить баги, связанные с редкими кейсами, а также поправить несколько проблем в юзабилити интерфейса.
По окончании закрытого бета-тестирования мы начали открывать доступ к хостингу всем пользователям: сначала 10%, потом 50%, а через неделю - всем нашим клиентам.
А если вы еще не успели попробовать наш сервис - оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне.ru с подключенным сервисом почты и DNS.
