Делегирование домена на Яндекс 360: как перенести DNS-зону к другому провайдеру и не уронить сайт и почту

Если DNS вашего домена у почтового провайдера, то в день его аварии вы не можете даже переключить почту на резерв — ключи от двери лежат в горящем доме. Если и почта, и DNS домена у одного облачного провайдера, его авария отрезает компанию от мира полностью — это первое, что стоит исправить. Если домен делегирован на Яндекс 360 — в NS указаны dns1.yandex.net и dns2.yandex.net, — все его DNS-записи, включая записи сайта, ведутся в кабинете организации. Перед переездом почты зону переносят к другому DNS-провайдеру как есть, сверяют ответы старых и новых серверов командой dig, меняют NS у регистратора и ждут применения — по справке Яндекса до 72 часов. Только после этого отдельным шагом переключают почту. Ниже — пошаговый порядок, команды для сверки, проверенные на нашем DNS-стенде, и что делать с записями Яндекса после переезда.

Почта и DNS у одного облака — двойная зависимость

Если и почта, и DNS домена у одного облачного провайдера, его авария бьёт сразу по всему: не открывается сайт, не приходят письма, не работают сервисы, привязанные к домену. Компания исчезает из сети целиком.

Первое, что стоит сделать при уходе из облака, — забрать домен под своё управление. Ниже — как перенести зону без сбоев.

Не держите ключи в чужом сейфе

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

Вынести DNS к регистратору или независимому DNS-сервису — работа на вечер. После этого авария почтового провайдера перестаёт быть тупиком: вы открываете свою панель, меняете MX на резервный сервер — и компания продолжает работать. Это самый короткий путь от беспомощности к контролю.

Как понять, что DNS домена у Яндекса

При подключении домена к Яндекс 360 его часто делегируют на DNS-серверы Яндекса: по справке для этого у регистратора указываются два сервера — dns1.yandex.net и dns2.yandex.net. После этого все DNS-записи домена, включая записи сайта, ведутся в кабинете организации Яндекс 360, а не у регистратора.

Проверить это можно одной командой:

dig +short company.ru NS

Если в ответе dns1.yandex.net. и dns2.yandex.net., зона домена обслуживается Яндексом. Тогда переезд почты состоит из двух независимых задач: перенести DNS-зону к другому DNS-провайдеру и перенести саму почту. Делать их одновременно не стоит.

Общий план переезда почты — в руководстве по переносу почты с Яндекс 360.

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

Почему сначала DNS, потом почта

Если перенести почту, оставив DNS у Яндекса, всё будет работать: MX и SPF меняются в кабинете организации. Но тогда домен по-прежнему зависит от того же поставщика, от которого вы уходите, и при отключении организации в Яндекс 360 придётся срочно переносить зону.

Если переносить DNS и почту одновременно, любая проблема будет непонятна: письма не приходят из-за новой зоны или из-за нового почтового сервера? Поэтому порядок такой: сначала переносится зона — со всеми записями как есть, включая MX на Яндекс, — и проверяется, что сайт и почта работают как раньше. И только потом, отдельным шагом, переключается почта.

Так каждое изменение проверяемо и обратимо, а в момент переключения почты вы меняете записи там, где будете управлять ими и дальше. И если что-то пойдёт не так, понятно, какой шаг откатывать. Это экономит время.

Куда переносить DNS-зону

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

Выбирая, проверьте: можно ли создать все нужные типы записей (TXT длиной больше 255 символов для DKIM, SRV, CAA), какой минимальный TTL допускается, есть ли у руководителя доступ к кабинету и включена ли двухфакторная аутентификация. И главное — новый DNS-провайдер не должен совпадать с новым почтовым провайдером, иначе зависимость от одного поставщика вернётся.

Для небольшой компании обычно разумен DNS у регистратора: домен и зона в одном месте, а почта — у отдельного поставщика.

Шаг 1. Составить полный список записей

Главный риск переноса зоны — забыть запись. Пропавшая запись сайта видна сразу, а пропавшая TXT-запись подтверждения какого-нибудь сервиса обнаружится через месяц, когда этот сервис перестанет работать.

Откройте управление DNS в кабинете организации и перепишите все записи: тип, имя, значение, TTL, для MX — приоритет. Типичный набор для небольшой компании:

Затем проверьте список запросами к текущим серверам — так вы убедитесь, что ничего не пропустили и значения записаны без опечаток:

for t in A AAAA MX TXT CAA NS; do dig +noall +answer @dns1.yandex.net company.ru $t; done
dig +noall +answer @dns1.yandex.net www.company.ru A
dig +noall +answer @dns1.yandex.net mail._domainkey.company.ru TXT
dig +noall +answer @dns1.yandex.net _dmarc.company.ru TXT

Запросы к поддоменам нужно делать по именам, которые вы знаете: полный список имён зоны по DNS обычно получить нельзя, поэтому основой остаётся список из кабинета.

Записи, о которых чаще всего забывают

Записи сайта и почты видны сразу. Но в зоне обычно есть и неочевидные записи, которые без проверки легко потерять.

TXT-подтверждения владения доменом для поисковых систем, сервисов аналитики, облачных сервисов и выдачи сертификатов. Если их потерять, сервис может перестать считать вас владельцем домена.

CNAME для поддоменов, которые смотрят на внешние сервисы: CRM, онлайн-кассы, конструкторы лендингов, службы поддержки. Их часто добавлял подрядчик, который давно не работает с компанией.

SRV-записи для телефонии, корпоративных мессенджеров и автонастройки почтовых программ. CAA-записи, ограничивающие, какие центры сертификации могут выпускать сертификаты для домена. Записи поддоменов, на которых живут тестовые и внутренние сервисы.

Если не уверены, нужна ли запись, переносите её. Удалить лишнее можно позже, а вспомнить потерянное — сложнее.

Шаг 2. Создать зону у нового DNS-провайдера

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

Создайте зону и внесите все записи из списка без изменений, включая MX и SPF, которые пока указывают на Яндекс. На этом шаге задача — получить точную копию, а не улучшить зону.

Если провайдер позволяет загрузить зону текстом в формате файла зоны, подготовьте файл и проверьте его синтаксис. На нашем DNS-стенде с bind9 мы проверяли зону так:

named-checkzone company.ru db.company.ru

Ответ OK и строка с серийным номером означают, что синтаксис верный. Длинные TXT-записи (например, ключ DKIM) разбиваются на несколько строк в кавычках — DNS-серверы склеивают их при ответе.

Обратите внимание на запись SOA: её создаёт сам новый провайдер, переносить её из старой зоны не нужно. А NS-записи внутри новой зоны должны указывать на серверы нового провайдера — если оставить в них dns1.yandex.net и dns2.yandex.net, часть резолверов будет продолжать обращаться к Яндексу.

Шаг 3. Сравнить ответы старых и новых серверов

До смены NS новая зона уже отвечает на запросы — если спросить её серверы напрямую. Сравните ответы для каждой записи из списка:

for n in company.ru www.company.ru mail._domainkey.company.ru _dmarc.company.ru; do
  for t in A MX TXT; do
    a=$(dig +short @dns1.yandex.net $n $t | sort)
    b=$(dig +short @ns1.new-dns.ru $n $t | sort)
    [ "$a" = "$b" ] || echo "РАЗЛИЧИЕ: $n $t"
  done
done

Здесь ns1.new-dns.ru — сервер вашего нового DNS-провайдера. Если скрипт ничего не вывел, ответы совпадают. Добавьте в цикл все имена и типы из вашего списка.

Проверка сайта и почты через новую зону до смены NS

Кроме сравнения ответов, полезно проверить, что сайт и сервисы работают, если обращаться к ним через новую зону. Для сайта это проверяется командой curl с явным указанием адреса из новой зоны:

IP=$(dig +short @ns1.new-dns.ru www.company.ru A | head -1)
curl -sI --resolve www.company.ru:443:$IP https://www.company.ru/ | head -3

Ответ с кодом 200 или 301 означает, что сайт отвечает по адресу из новой зоны и сертификат подходит. Для почты достаточно сравнения MX, SPF и DKIM: на этом шаге они ещё указывают на Яндекс и должны совпадать со старой зоной полностью.

Такие проверки занимают полчаса и снимают главный страх смены NS — что после неё что-то перестанет работать.

Шаг 4. Сменить NS у регистратора

В кабинете регистратора замените серверы dns1.yandex.net и dns2.yandex.net на серверы нового DNS-провайдера. По справке Яндекса на применение изменений делегирования может уйти до 72 часов; в этот период часть пользователей интернета видит старые серверы, часть — новые. Поскольку обе зоны одинаковые, для сайта и почты это незаметно.

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

dig +short company.ru NS @8.8.8.8
dig +short company.ru NS @77.88.8.8
dig +short company.ru NS @1.1.1.1

Когда все отвечают серверами нового провайдера, перенос зоны завершён. Если домен подписан DNSSEC, перед сменой NS нужно разобраться с ключами: неправильный порядок действий делает домен недоступным для проверяющих резолверов. Это отдельная процедура, её стоит согласовать с регистратором.

Запишите дату и время смены NS: если что-то пойдёт не так, по ним проще восстановить картину.

TTL при переносе зоны

TTL записей в новой зоне лучше на время переезда оставить такими же или ниже, чем в старой. Низкий TTL пригодится, если после смены NS выяснится, что какая-то запись перенесена неточно: исправление разойдётся быстрее.

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

Когда смена NS применилась везде и всё работает, TTL основных записей можно вернуть к обычным значениям — кроме MX и SPF, если впереди переключение почты: их TTL снижают заранее, как описано в статье о смене DNS при переезде почты.

Шаг 5. Переключить почту

Теперь зона у нового провайдера, и почта переключается обычным порядком: заранее снижается TTL MX и SPF, публикуются SPF и DKIM нового почтового сервера, DMARC переводится в режим наблюдения, затем меняется MX. Всё это — в кабинете нового DNS-провайдера.

Подробно, с примерами записей, проверенными на нашем стенде, — в статье «MX, SPF, DKIM, DMARC и TTL при смене почтового провайдера». Перенос писем — в инструкции по imapsync.

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

Что делать с записями Яндекса после переезда

После того как почта переехала и переходный период закончился, в зоне остаются записи, указывающие на Яндекс: SPF с include:_spf.yandex.net, DKIM с селектором mail, иногда TXT-подтверждение домена для Яндекс 360. Их удаляют, когда через Яндекс больше никто не отправляет почту.

Порядок: убедиться по отчётам DMARC, что письма от вашего домена через серверы Яндекса больше не идут; удалить include Яндекса из SPF; удалить DKIM-запись Яндекса; удалить подтверждение домена, если организация в Яндекс 360 больше не нужна.

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

Если Яндекс 360 остаётся для других сервисов

Иногда почта уезжает, а другие сервисы Яндекс 360 — например, диск или видеозвонки — компания пока оставляет. Тогда организация в Яндекс 360 продолжает работать, и подтверждение домена в ней удалять нельзя.

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

О переносе диска и документов — в отдельной статье серии про Яндекс Диск компании.

Кто должен иметь доступ к DNS после переезда

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

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

Подробнее о том, почему важно продлевать домен и следить за доступами, — в статье «Домен просрочен: сайт и почта легли — чек-лист».

Частые ошибки

Чек-лист переноса DNS-зоны с Яндекса

Перед переключением почты.

• dig NS показывает dns1.yandex.net и dns2.yandex.net — зона у Яндекса
• составлен полный список записей из кабинета организации
• у нового DNS-провайдера создана зона — точная копия, включая MX на Яндекс
• named-checkzone или проверка провайдера — без ошибок
• ответы старых и новых серверов совпадают для всех записей
• NS у регистратора заменены, организация в Яндекс 360 не удалена
• публичные резолверы отвечают новыми NS
• проверен DNSSEC, если он был включён
• только после этого — переключение почты по отдельному плану

Частые вопросы