Делегирование DNS-домена на серверы Яндекса и подключение к бесплатной услуге Яндекса "Почта для домена"

Для правильной работы почтового сервера важно иметь правильно настроенную 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 для бизнеса»

Блог компании Mail.ru Group

В прошлом году мы запустили бесплатный DNS-хостинг на «Mail.Ru для бизнеса», а недавно он вышел из бета-тестирования. Сегодня я хочу рассказать, как мы его делали, какие технические решения принимались, и немного о том, как мы запускались на всю аудиторию.

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

Выбор DNS-сервера

При выборе DNS-сервера мы ориентировались на скорость, потребляемые ресурсы и удобство работы. Очень хотелось, чтобы он умел работать с БД из коробки. Рассматривались BIND, NSD и PowerDNS.

BIND - самый популярный сервер, имеет хорошую документацию, и, наверное, можно найти ответ на любой вопрос по нему. Однако он не умеет работать с БД из коробки. Есть, конечно, DLZ-патч, но последнее обновление датируется 2013 годом. Не отличается высокой производительностью.

NSD - безусловный лидер по скорости и потребляемым ресурсам, но вот ни с чем, кроме файлов, он работать не умеет. На практике это значит, что нужно писать скрипт, который с периодичностью достает все записи из базы, пишет их в файл и делает reload NSD.

PowerDNS имеет хорошую производительность, умеренно использует ресурсы сервера. Имеет много полезных и не очень родных патчей. Умеет работать с PostgreSQL из коробки.

В конечном счете при выборе между высокой производительностью NSD и хорошей производительностью и простотой работы PowerDNS победил PowerDNS.

Работать с PowerDNS - одно удовольствие: вносишь изменения в БД, а он сам их подхватывает. К тому же, так как все данные берутся из базы, не приходится настраивать master-slave на стороне PowerDNS, а можно переложить их репликацию на базу.

История имен

Для подтверждения домена мы выдаем две NS-записи - например, moscow.ens.mail.ru и spb.ens.mail.ru. Откуда взялись города? Чтобы объяснить это, нужно сначала рассказать о задаче, которую мы пытались решить.

Мы стремились сделать регистрацию на «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 уникальных комбинаций, что гарантирует однозначную идентификацию владельца домена, даже если несколько человек пытаются зарегистрировать один домен.

После того как регистрация завершена, имена серверов теряют техническое значение. Независимо от того, по какому из адресов придет запрос, мы всегда отдадим запрашиваемые записи.

Перебор

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

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

Пользуясь случаем, хочу напомнить, что у Mail.Ru Group есть программа поиска уязвимостей . Если ты, пытливый читатель, найдешь баги в DNS-хостинге (как и в целом на biz.mail.ru), ты можешь заработать плюс в карму и денег, подав заявку.

Система фич

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

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

По окончании закрытого бета-тестирования мы начали открывать доступ к хостингу всем пользователям: сначала 10%, потом 50%, а через неделю - всем нашим клиентам.

Вместо заключения

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

А если вы еще не успели попробовать наш сервис - оставляйте комментарии. Первые 100 хабраюзеров получат промокод на регистрацию бесплатного домена в зоне.ru с подключенным сервисом почты и DNS.

Сегодня практически любой виртуальный хостинг в качестве дополнительной услуги предлагает возможность создания почтовых ящиков для вашего домена, однако удобство работы с такими ящиками иногда оставляет желать лучшего. Чтобы поднять качество работы с почтой домена можно воспользоваться бесплатным сервисом от Яндекс Почта для домена . Данный сервис позволяет привязать почту вашего домена к почтовым серверам Яндекс с возможностью создания до 1000 безлимитных почтовых ящиков с использованием всех преимуществ сервиса Яндекс.Почта , таких как автоматическая проверка антивирусом, спам фильтры, доступ через веб-интерфейс, доступ с мобильных устройств и через прямое подключение по протоколам SMTP/POP3/IMAP.

Одним из основных этапов настройки привязки домена к почтовой системе Яндекса является создание специальных записей в DNS-зоне вашего домена. Чтобы максимально упростить и автоматизировать данную процедуру, можно произвести делегирование домена на NS-серверы Яндекса, то есть фактически воспользоваться ещё одним бесплатным сервисом DNS-хостинг Яндекса .

В этой заметке мы поэтапно рассмотрим процедуру подключения почты домена к почтовым серверам Яндекса а также делегирование домена серверам Яндекса на примере нашего домена IT-KB.RU

Регистрируем аккаунт на Яндексе

Для работы с Почтой для домена необходим аккаунт Яндекса, используя который, мы в дальнейшем будем управлять почтой. На данный момент к каждому аккаунту можно подключить до 50 доменов. Зарегистрируемся и получим аккаунт Яндекс, если этого ещё не было сделано ранее.

Подключаем домен к Яндексу

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

После добавления домена, нам нужно будет подтвердить то, что мы являемся его владельцем. На веб-странице будет отображаться статус Домен не подтверждён и будет предложено три варианта действий, которыми мы сможем подтвердить владение доменом.

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

После успешной проверки нас перенаправят на страницу настройки MX -записи для нашего домена. Внести указанные изменения в DNS-зоне нашего домена можно как самостоятельно, так и автоматически, если выполнить делегирование домена на Яндекс. Учитывая то, что помимо MX-записи в нашем домене для полноценной поддержки почты Яндекс потребуется внести ещё несколько служебных SRV-записей, проще всего выполнить делегирование домена, в результате которого все нужные записи в DNS-зоне нашего домена будут созданы автоматически.

Пройдём по справочной ссылке делегировать домен на Яндекс и ознакомимся с информацией о том, как делегировать DNS-домен NS-серверам Яндекса. Здесь всё предельно просто. Переходим на DNS-хостинг, на котором в данный момент расположен наш доменом и правим записи NS-серверов. Поменяем текущие NS-серверы на dns1.yandex.net и dns2.yandex.net

Ждём некоторое время (может пройти от нескольких часов до двух суток), чтобы изменения разошлись по нейм-серверам интернета и проверяем результат, например, с помощью утилиты nslookup

Как видим, теперь нейм-серверами нашего домена являются серверы Яндекса, и мы можем вернуться к настройке почты для домена. Вернёмся на консоль управления почтой домена и увидим, что теперь статус домена изменился на Домен подключён и делегирован на Яндекс .

Откроем ссылку Редактор DNS и просмотрим автоматически добавленные и настроенные после делегирования домена записи для поддержки сервисов Яндекса - MX ,CNAME записи для указания почтового сервера, SRV (SPF , DKIM ) записи для поддержки сервисов почты и системы обмена сообщениями по XMPP.

Создадим новый почтовый ящик для нашего домена и ознакомимся с доступными возможностями по управлению ящиками

Чтобы DNS-серверы Яндекса обеспечивали работоспособность вашего домена, нужно делегировать домен на серверы Яндекса . После делегирования, управлять DNS домена можно с помощью DNS-редактора Почты для домена или API .

Примечание. Вы можете добавлять нужные DNS-записи для домена до делегирования на серверы Яндекса, если вы подтвердили владение доменом . Но эти записи вступят в силу только после делегирования.

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

Вы можете настраивать DNS-записи следующих типов:

MX. Приоритет нужно указывать в пределах от 1 до 90. API .

SRV. Приоритет нужно указывать в пределах от 1 до 90. Значение приоритета, которое нельзя выбрать в выпадающем списке, можно установить с помощью API .

TXT. При настройке DKIM-подписи длина значения TXT-записи не должна превышать 255 символов.

CNAME. Помните, что настроить CNAME-запись для корневого домена нельзя, так как это запрещено RFC .

Значения параметров можно менять в следующих пределах:

Имя параметра	Рекомендуемые значения	Допустимый диапазон значений
REFRESH	14400 секунд	от 900 до 86400 секунд
RETRY	900 секунд	от 90 до 3600 секунд
EXPIRE	1209600 секунд	от 604800 до 2419200 секунд
MINIMUM	14400 секунд	от 90 до 86400 секунд
TTL	21600 секунд	от 900 до 1209600 секунд

Имя параметра	Рекомендуемые значения	Допустимый диапазон значений
REFRESH	14400 секунд	от 900 до 86400 секунд
RETRY	900 секунд	от 90 до 3600 секунд
EXPIRE	1209600 секунд	от 604800 до 2419200 секунд
MINIMUM	14400 секунд	от 90 до 86400 секунд
TTL	21600 секунд	от 900 до 1209600 секунд

DNS-редактор

Чтобы перейти в DNS-редактор:

При создании DNS-записи в поле Хост следует указывать:

«@» , если вы настраиваете запись для корневого домена.

часть имени поддомена до первой точки, например:

если имя поддомена bar .yourdomain.tld, в поле Хост укажите « bar » ;

если имя поддомена foo.bar .yourdomain.com , в поле Хост укажите «foo.bar» .

Бесплатный сервис от яндекса. Поддержка почтовых ящиков от вашего домена и поддержка ДНС вашего домена.

Почта для домена.

Вы можете создать 1000 почтовых аккаунтов от своего домена, которые вы сможете раздать своим друзьям, родственникам, знакомым или пользоваться сами.
Каждый такой почтовый аккаунт имеет свой отдельный доступ к вебинтерфейсу почты яндекса и имеет все те же функции почты яндекса.
Неограниченный объём почтового ящика.
Защиты от спама и вирусов.
Различные цветовые схемы интерфейса.
Доступ к почте по протоколам POP3/IMAP.
Доступ к почте с мобильных устройств.
Я.Онлайн на страницах Почты и т.д.

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

DNS-хостинг Яндекса

Кроме почты для домена Яндекс запустил бесплатную поддержку ДНС серверов для доменов. Это полноценный сервис Primary и Secondary. До этого момента в России не было бесплатных ДНС серверов, бесплатно их предлагали только в дополнение к платным услугам, например на платных хостингах или при поддержке домена в webnames. За пределами России есть бесплатные ДНС, но все они тормозные и глючные.

04.02.2013 Админ
18.01.2013 Юрий, что значит весь домен? Не нужен яндексу весь домен. Все работает нормально. У меня у самого почтой двух доменов рулит яндекс, а сайты находятся на других хостингах.

23.02.2013 Дмитрий
Яндекс отдался REG.ru. ~500 рублей домен стоит в зоне Ру.

12.01.2014 Иван
Перерыл весь инет. Не нашёл ни слова про услугу хостинга от яндекса. Конкретно, сколько места выделяется для домена, какое ПО стоит итд Что за развод??