Перенос домена между регистраторами: как не потерять сайт

MAATRIX

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

Почему это вообще риск, а не просто формальность

Технически перенос домена — это смена регистратора, который администрирует запись о владении именем в реестре зоны (.com, .ru, .io и так далее). Сам по себе он не должен трогать ни сайт, ни почту: DNS-записи, которые указывают, где физически лежит сайт, при переносе обычно сохраняются. Но «обычно» — не «всегда», и весь риск сосредоточен в паре мест, где человеческий фактор или невнимательность к срокам ломают эту идиллию.

Проблема в том, что ошибки здесь заметны не сразу. Заявку на перенос можно подать, получить отказ или зависание в статусе «pending» на неделю, и узнать об этом только тогда, когда домен на грани истечения регистрации, а времени на исправление уже нет. Поэтому все шаги ниже стоит проверять заранее, а не по факту, когда что-то уже сломалось.

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

Риск №1: забытая блокировка трансфера (Registrar Lock)

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

Проблема в том, что эта блокировка стоит на пути и у легитимного переноса тоже. Пока она включена, новый регистратор физически не может инициировать процесс — попытка упрётся в ошибку вида «domain is locked for transfer» или «transfer prohibited». Снимается блокировка в панели управления доменом у текущего регистратора, обычно в разделе с названием вроде «Domain Lock», «Блокировка от переноса» или «Transfer Lock» — один переключатель.

Грабля здесь простая: снятие блокировки не всегда происходит мгновенно. У части регистраторов статус в реестре обновляется в течение нескольких минут, у части — до пары часов. Если вы подаёте заявку на перенос сразу после клика «разблокировать», не дав статусу обновиться, новый регистратор снова увидит блокировку и снова откажет. Практический совет — снимайте блокировку заранее, за день-два до старта переноса, и проверьте статус домена через WHOIS-запрос (whois yourdomain.com в терминале или любой публичный WHOIS-сервис) — там явно видно, стоит ли ещё clientTransferProhibited.

Риск №2: EPP-код — получить, скопировать, не перепутать

EPP-код (он же auth-код, transfer-код, authorization code) — это уникальная строка, обычно 16-32 символа, буквы и цифры вперемешку, которая подтверждает: именно владелец домена запускает перенос. Без него новый регистратор не может даже начать процесс — это не опциональный шаг.

Получить код можно там же, в панели текущего регистратора, обычно рядом с блокировкой трансфера — кнопка «Get Auth Code» или «Получить код передачи». У некоторых регистраторов код показывается сразу на экране, у некоторых приходит на контактный email домена отдельным письмом — если код не появляется в панели, проверьте почту.

Практическая грабля, которая встречается чаще, чем кажется: при копировании кода легко зацепить лишний пробел в начале или в конце строки, особенно если код скопирован из письма или PDF. Форма нового регистратора в этом случае выдаёт ошибку «invalid auth code», хотя код на самом деле правильный — просто с невидимым пробелом. Вставляйте код в текстовый редактор без форматирования перед тем, как переносить его в форму, и визуально проверяйте, что в начале и конце нет пустых символов.

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

Риск №3: домен в периоде, когда перенос технически невозможен

Реестры доменных зон обычно вводят период после регистрации или после предыдущего переноса, в течение которого повторный перенос технически заблокирован — независимо от того, снята блокировка Registrar Lock или нет. Смысл ограничения — не дать домену «летать» между регистраторами слишком часто, что усложняет отслеживание владения и создаёт почву для мошенничества.

Точная длительность этого периода различается по зонам и может со временем меняться на уровне правил конкретного реестра, поэтому здесь мы намеренно не приводим точные цифры дней — уточняйте актуальное значение у текущего регистратора или в базе знаний нового регистратора перед стартом, для вашей конкретной зоны. Если домен только что зарегистрирован или недавно уже переносился — прежде чем что-либо предпринимать, проверьте статус в панели или через WHOIS: там обычно видна информация о дате последнего изменения регистратора.

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

Риск №4: устаревший контактный email — самая частая причина провала

Это, пожалуй, самая недооценённая точка риска во всём процессе. Подтверждение переноса почти всегда уходит на контактный email, зарегистрированный в WHOIS-данных домена (обычно это поле Registrant Contact, иногда дублируется на Admin Contact). Если этот ящик не проверяется — письмо просто улетает в никуда, а перенос зависает в состоянии ожидания подтверждения.

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

Что делать заранее: зайдите в панель управления доменом у текущего регистратора, найдите раздел с WHOIS-контактами и проверьте email в поле Registrant. Если он устарел — обновите его на актуальный до старта переноса, а не во время. У части регистраторов смена контактного email тоже требует небольшого времени на обработку (иногда с дополнительным подтверждением по старому адресу, если он ещё доступен) — ещё одна причина не делать это в последний момент.

Если у домена включена приватность WHOIS (WHOIS Privacy/Proxy), убедитесь, что вы всё равно можете получить письмо — приватность обычно скрывает email от публичного просмотра, но не должна мешать доставке подтверждений на реальный ящик. Если сомневаетесь — временно отключите приватность на время переноса, чтобы исключить лишнюю переменную.

Риск №5: не отключайте DNS-хостинг у старого регистратора раньше времени

Здесь ошибаются даже опытные администраторы, потому что интуитивно кажется логичным «раз мы уходим от этого регистратора, отменим у него всё сразу». Но если старый регистратор одновременно был и DNS-хостом для вашего домена (то есть NS-записи домена указывали на его серверы имён, и там же были настроены A- и MX-записи) — досрочная отмена этой услуги обрывает DNS раньше, чем перенос вообще завершится.

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

1. Перенос домена инициирован, идёт (может занимать от нескольких часов до недели-двух в зависимости от зоны).
2. Если вы также хотите сменить DNS-провайдера — настройте новую DNS-зону у нового провайдера параллельно, но не переключайте NS-записи домена, пока перенос не завершён полностью.
3. Перенос завершён, домен официально у нового регистратора.
4. Только теперь, отдельным шагом, либо оставляете DNS как было (если старый DNS-хостинг продолжает работать и вас устраивает), либо переключаете NS-записи на новый DNS-провайдер и проверяете резолвинг.
5. И только после того, как убедились, что новый DNS отдаёт правильные ответы (сайт открывается, почта ходит) — отменяете старую услугу DNS-хостинга, если она была платной и больше не нужна.

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

После переноса: обязательно проверьте DNS-записи

Перенос домена сам по себе — операция про реестр, а не про DNS: она не обязана трогать ни A-запись, ни MX-записи. Но на практике DNS-записи не переносятся автоматически в двух случаях: если вы сознательно меняете DNS-провайдера вместе с регистратором, или если новый регистратор при завершении переноса сам предлагает (и по умолчанию включает) собственный DNS-хостинг — тогда домен «переезжает» на серверы имён нового регистратора, а старая зона с вашими записями там просто не существует, пока вы её не создадите заново.

Чек-лист после завершения переноса, до того как считать процесс закрытым:

• Проверьте NS-записи домена (dig NS yourdomain.com или любой онлайн-инструмент) — указывают ли они туда, куда вы ожидаете.
• Проверьте A-запись (dig A yourdomain.com) — резолвится ли домен в правильный IP-адрес вашего сервера.
• Проверьте MX-записи (dig MX yourdomain.com), если на домене настроена почта — часто про них забывают, потому что сайт при этом продолжает открываться нормально, а почта тихо перестаёт доставляться.
• Проверьте TXT-записи, если использовались для SPF/DKIM или подтверждения владения доменом в сторонних сервисах (Google Search Console, Яндекс.Вебмастер и подобные) — их тоже нужно перенести вручную, если DNS-зона создавалась заново.
• Если домен открывается по IP-адресу сервера, но не по имени — это почти всегда именно проблема с DNS-записями после переноса, а не с самим сервером. Разбор этой конкретной ситуации есть в материале сайт открывается по IP, но не по домену.

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

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