Как перенести домен к другому регистратору

Межрегистраторский перенос меняет компанию, которая поддерживает регистрационную запись, но не должен автоматически менять сайт, почту или DNS. Процедура зависит от доменной зоны. Правила ICANN применяются к gTLD, а .ru и .рф используют отдельные документы Координационного центра. У других ccTLD могут быть собственные коды, сроки и способы подтверждения.

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

Что такое AuthInfo и как его хранить

AuthInfo — уникальный секретный код, который используется для авторизации межрегистраторского переноса gTLD и передачи поддержки .ru/.рф. Его может называть AuthInfo-кодом, authorization code или EPP-кодом. Это не пароль от аккаунта и не публичное поле регистрационных данных.

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

Наличие AuthInfo не отменяет проверку ограничений и личности держателя. Для некоторых ccTLD этот механизм вообще не применяется, поэтому сначала нужна политика конкретной зоны.

Подготовка, общая для обеих процедур

Проверьте регистратора и доступ к аккаунту

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

Полный вывод надёжнее фильтра при первой диагностике:

whois example.com

Для gTLD статус clientTransferProhibited означает, что реестр должен отклонять запрос переноса. После снятия проверьте именно отсутствие этого статуса. Результат не обязан стать ok: у домена могут одновременно оставаться другие допустимые статусы.

Проверьте DNS до переноса

Смена регистратора сама по себе обычно сохраняет текущие NS. Риск возникает, если DNS предоставляется старым регистратором как связанная услуга и будет отключён после завершения договора. Получите у него явный ответ о судьбе зоны.

Если DNS продолжит обслуживаться, менять делегирование только ради переноса не нужно. Если услуга прекратится:

1. Экспортируйте все записи, включая A, AAAA, CNAME, MX, TXT, CAA и служебные записи.
2. Создайте зону у выбранного DNS-провайдера и получите назначенные именно вашему домену NS.
3. Сравните ответы каждого нового авторитетного сервера со старой зоной.
4. Измените делегирование у текущего регистратора до начала переноса.
5. Дождитесь, пока старые кеши с прежним TTL перестанут влиять на проверку.
6. Не удаляйте старую зону, пока новые NS не обслуживают сайт и почту устойчиво.

Фиксированного ожидания «48 часов» нет. Результат зависит от прежнего TTL, обновления делегирования и состояния авторитетных серверов. Проверяйте фактические ответы через DNS-инструмент.

Перенос gTLD

Проверьте ограничения

Текущий регистратор может отклонить gTLD-перенос, запрошенный в течение 60 дней после создания регистрационной записи или в течение 60 дней после предыдущего межрегистраторского переноса. Отдельный 60-дневный запрет может возникнуть после Change of Registrant. Регистратор вправе предложить отказ от последнего запрета, но такой отказ оформляется до запроса на изменение регистранта, а не после него.

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

Само наступление даты окончания не является универсальным основанием отказа в gTLD-переносе. Однако состояние регистрации имеет значение: в redemptionPeriod попытки переноса запрещены, и сначала требуется восстановление через удалившего запись регистратора. Если авторизация истекла до отправки реестрового запроса, новый регистратор может потребовать повторное подтверждение.

Запустите и подтвердите запрос

1. Снимите clientTransferProhibited у текущего регистратора.
2. Получите уникальный AuthInfo-код.
3. Подайте заявку и код новому регистратору.
4. Выполните его безопасную процедуру авторизации держателя регистрации.
5. Следите за уведомлениями обоих регистраторов в кабинете и по сохранённым контактным каналам.

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

Передача поддержки .ru и .рф

Для .ru/.рф используется AuthInfo-код, но сроки отличаются от gTLD.

1. Администратор запрашивает код у регистратора-донора.
2. При отсутствии препятствий донор передаёт код не позднее трёх рабочих дней после заявки.
3. Код действует не более 20 календарных дней с момента передачи в Реестр.
4. Администратор подаёт заявку регистратору-реципиенту и сообщает действительный код.
5. Реципиент проверяет код и данные, затем запрашивает подтверждение. Общий срок направления запроса и получения ответа не может превышать пяти календарных дней.
6. Подтверждение выполняется предусмотренным способом: письменным заявлением, SMS- или email-авторизацией по контактам, хранящимся в Реестре для этой процедуры.
7. После инициации донор вправе одобрить или отклонить передачу в течение пяти календарных дней. При его бездействии передача считается одобренной.

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

Проверка после завершения

Не ориентируйтесь только на письмо «готово». Проверьте несколько независимых признаков:

• в регистрационных данных указан новый регистратор;
• ожидаемые NS остались в делегировании;
• авторитетные серверы возвращают полный набор записей;
• сайт открывается по HTTPS, а почта принимает и отправляет тестовые сообщения;
• DNSSEC, если он использовался, не потерял корректную цепочку DS и DNSKEY;
• у нового регистратора включены нужные блокировки, многофакторная аутентификация и уведомления.

Если регистратор изменился, а сайт не работает, сначала сравните NS и записи, а не запускайте перенос повторно. Регистрация и DNS — связанные, но разные системы.

Практический сценарий без привязки к провайдеру

Организация переносит example.com, а DNS обслуживает текущий регистратор. Сначала она получает подтверждение, что DNS-услуга завершится вместе с договором. Команда создаёт эквивалентную зону у нового DNS-провайдера, использует назначенные им NS, проверяет авторитетные ответы и только затем меняет делегирование. После стабилизации DNS снимается clientTransferProhibited, запрашивается AuthInfo и запускается gTLD-перенос.

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

Типичные ошибки

• Применять gTLD-ограничения 60 дней к .ru/.рф или наоборот.
• Считать публичный WHOIS-email обязательным каналом подтверждения.
• Ожидать, что снятие одного статуса обязательно даст общий статус ok.
• Передавать AuthInfo посреднику или хранить его в открытой задаче.
• Менять NS без проверки, прекратится ли прежняя DNS-услуга.
• Использовать чужие примерные NS вместо значений, назначенных DNS-провайдером.
• Начинать .ru/.рф-процедуру в последние семь дней регистрации.
• Пытаться перенести gTLD из redemptionPeriod без восстановления.

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

Сколько времени занимает перенос домена?

Единого срока нет. Для gTLD реестр завершает принятый запрос раньше или по истечении пяти календарных дней, если текущий регистратор не отклонил его по допустимому основанию. Для .ru/.рф отдельно предусмотрены подтверждение у нового регистратора и пятидневное окно решения регистратора-донора.

Что такое AuthInfo-код и где его получить?

AuthInfo — секретный код для межрегистраторского переноса gTLD и передачи поддержки .ru/.рф. Его получают у текущего регистратора и вводят только у выбранного нового регистратора. Процедуры других ccTLD могут использовать иной механизм.

Нужно ли менять DNS при переносе?

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