Перенос домена к другому регистратору без простоев: EPP‑код, transfer lock и DNS

Если переносить домен «по-быстрому», чаще всего срывается почта, ломаются поддомены и часть трафика попадает на старый сервер. Причина почти всегда в DNS и неочевидных статусах домена. Ниже — практический разбор процесса domain transfer без простоя: от EPP‑кода и transfer lock до подготовки nameservers и грамотной миграции зоны.

Когда нужен перенос и что именно происходит при transfer

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

Типичные причины переноса:

• неудобная панель, медленная поддержка, невыгодные тарифы и продления;
• нужна унификация портфеля доменов у одного регистратора;
• блокирующие ограничения (например, невозможность управлять DNS на уровне записей, только через саппорт).

Если как раз консолидируете портфель, удобнее вести домены через регистрацию доменов в одном месте.

Компоненты процесса: EPP‑код, transfer lock, статусы в WHOIS

Что такое EPP‑код

EPP‑код (AuthInfo, authorization code) — одноразовый пароль, подтверждающий право переносить домен к другому регистратору. Получается в панели текущего регистратора или по запросу в поддержку. Код чувствителен к регистрозависимым правилам (срок действия, маскирование, способ выдачи). Храните его как секрет; не пересылайте в общие чаты и тикеты без необходимости.

Transfer lock и статусы

Чтобы предотвратить угон домена, многие включают блокировку переноса — clientTransferProhibited. Пока она активна, новый регистратор не сможет инициировать transfer, даже если у вас есть EPP‑код. Снимите блокировку в панели или через саппорт.

Другие статусы, на которые стоит взглянуть в WHOIS:

• clientHold/serverHold — домен отключён от DNS со стороны реестра; сайт и почта не резолвятся;
• clientUpdateProhibited и родственные — ограничения на обновление профиля, иногда мешают редактировать контактные данные перед переносом;
• serverTransferProhibited — реестровая блокировка; снимается по процедуре у текущего регистратора, иногда требуется дополнительная верификация.

Проверьте, не близка ли дата истечения регистрации. В большинстве зон успешный transfer продлевает домен на 1 год (исключения есть), но перенос домена, находящегося в периодах Redemption/Pending Delete, невозможен или экономически нецелесообразен. Подробно о периодах продления и выкупа мы разбирали здесь.

Почта и подтверждения

По правилам зон/регистраторов, в процессе transfer может потребоваться подтверждение по e‑mail контактного лица домена. Если включена приватность WHOIS (privacy/proxy), убедитесь, что пересылка писем работает. Иначе подтверждение не дойдёт, и вы потеряете время.

Коротко: перед стартом переноса разблокируйте домен, получите EPP‑код, проверьте, что контактный e‑mail доступен и принимает письма, и домен не висит на Hold.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Почему простои чаще всего из‑за DNS и nameservers

Технически transfer — это смена «обслуживающего» регистратора в реестре. DNS к этому отношения не имеет, пока вы сознательно не меняете nameservers. Но на практике многие держат DNS‑зону у текущего регистратора. И вот тут критичные сценарии:

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

Вывод: перед переносом определитесь с политикой DNS. Самый безопасный путь — вынести зону на нейтральный и контролируемый вами DNS (например, у хостинг‑провайдера или внешнего DNS‑провайдера) и не менять NS в момент transfer.

Пошаговый план переносa без простоя

T‑72–48 часа: аудит и снижение TTL

Проверьте актуальные NS и содержимое зоны. Снизьте TTL у ключевых записей до 300–600 секунд. Это позволит быстро переключаться между старыми и новыми настройками, если что-то пойдёт не так.

T‑48–24 часа: репликация зоны

Поднимите «зеркало» зоны там, где она будет жить после переноса: либо на NS нового регистратора, либо на нейтральном DNS. Синхронизируйте A/AAAA/CNAME, MX, SPF (TXT с v=spf1), DKIM (TXT с публикуемыми ключами), DMARC (TXT _dmarc), SRV, CAA и все критичные поддомены.

T‑24–12 часов: верификация зоны

Сделайте точечные проверки резолвинга из разных регионов, опрашивая конкретные NS:

dig +short A yourdomain.tld @ns1.your-dns.example
dig +short MX yourdomain.tld @ns1.your-dns.example
dig TXT _dmarc.yourdomain.tld @ns1.your-dns.example

Так вы проверяете будущие авторитетные серверы, не дожидаясь публикации NS в реестре.

T‑12–6 часов: подготовка домена

• Разблокируйте перенос (снимите clientTransferProhibited).
• Получите и проверьте EPP‑код.
• Убедитесь, что контактный e‑mail получает письма и не фильтруется.

T‑0: инициируйте перенос

Подавайте запрос на transfer у нового регистратора: домен + EPP‑код. Далее следите за почтой. Если потребуется подтверждение — подтвердите. Не меняйте контент на сайте в критическое окно, чтобы избежать несогласованных состояний кэшей и CDN.

T+часы/дни: завершение и пост‑действия

Обычно перенос в gTLD занимает от нескольких часов до 5–7 дней. В большинстве зон после успешного transfer домен продлевается на год. Когда получите уведомление о завершении:

• проверьте, что NS не были автоматически изменены;
• если планировали переносить DNS к новому провайдеру — измените NS уже после завершения transfer (на низком TTL это безопаснее);
• верните TTL в зону значений (например, 3600–14400 секунд), чтобы снизить нагрузку на рекурсоры.

Ключ к отсутствию downtime: не трогать NS во время самого transfer и заранее мигрировать DNS‑зону в контролируемое вами место.

Где хранить зону DNS: варианты и риски

Оставить старые nameservers

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

Перенести зону к новому регистратору

Хорошо, когда у него удобная панель/API. Важно: поднимите зону заранее, проверьте записи. Менять NS лучше после завершения transfer, в подготовленное окно, с низким TTL.

Вынести зону на нейтральный DNS

На практике самый предсказуемый путь: NS не завязаны на регистраторов, домен можно переносить сколько угодно — DNS остаётся прежним. В таком сценарии подойдут панели DNS на виртуальном хостинге или собственная BIND/PowerDNS на VDS.

Почта при переносе: MX, SPF, DKIM, DMARC

Почтовые остановки — частая боль. Проверьте:

• MX указывают на верные хосты (и на резервный, если он есть);
• SPF включает все исходящие каналы (include: релевантных провайдеров, либо ip4/ip6);
• DKIM ключи опубликованы для всех доменов и селекторов, которые реально подписывают письма;
• DMARC настроен корректно: p=none/quarantine/reject согласно вашей политике и боевому опыту.

Подробнее про SPF/DKIM/DMARC и типовые записи — в статье DNS-записи для почтовой аутентификации. Если вы меняете NS, убедитесь, что эти записи присутствуют в новой зоне до переключения. Для критичных доменов держите старые NS в актуальном состоянии ещё 24–48 часов после смены, чтобы пережить кэш рекурсоров.

WHOIS: контактные данные, приватность и 60‑дневные ограничения

В ряде зон изменение контактных данных владельца может включать 60‑дневную блокировку transfer. Поэтому:

• сначала выполните перенос, потом редактируйте контакты;
• если приватность WHOIS скрывает адрес, проверьте, что почта форвардится корректно;
• снимите блокировки, проверьте clientTransferProhibited в WHOIS до старта.

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

Хост‑объекты и «внутренние» NS (glue)

Если вы используете собственные NS внутри домена (например, ns1.example.tld и ns2.example.tld), у реестра существуют «host objects/glue records». Перед переносом убедитесь, что:

• адреса glue‑записей актуальны;
• после transfer вы сможете редактировать host‑объекты у нового регистратора;
• в случае смены IP NS обновите glue в реестре до переключения, иначе часть мира потеряет авторитетные NS.

Контроль и верификация: dig, кэш рекурсоров, распространение NS

Разделяйте проверки на «что видят рекурсоры сейчас» и «что ответят будущие авторитетные NS». Для первого достаточно обычного dig yourdomain.tld. Для второго всегда указывайте конкретный NS. Не путайте обновление NS в реестре (занимает минуты) с истечением TTL на рекурсорах (минуты–часы). Любые масштабные изменения проводите при низком TTL.

Частые подводные камни

• Перенос инициирован близко к истечению домена. Если текущий провайдер отключает зону в last‑minute, получите короткий «блэкаут». Решение: продлить заранее или переносить не у дедлайна.
• Непредсказуемые авто‑политики NS. Отключите «автонастройку» у нового регистратора, держите руку на пульсе в момент завершения transfer.
• Забытые записи в зоне. Часто ломаются API‑вебхуки, интеграции третьих сервисов, SSO‑редиректы на поддоменах, автоконфиг для почтовых клиентов (autoconfig/autodiscover).
• CDN и proxy. При смене NS проверьте CNAME на CDN‑зоны, валидность валидаций и санкционированных источников в SPF.
• DNSSEC. Если домен подписан, продумайте ротацию ключей и публикацию DS у реестра: либо временно отключайте DNSSEC на период смены NS, либо реплицируйте ключи на новом провайдере и обновите DS последовательно.

Минимальный чек‑лист без простоя

1. Понизить TTL у критичных записей до 300–600 секунд.
2. Подготовить идентичную DNS‑зону у будущего DNS‑провайдера.
3. Проверить зону через dig на конкретных NS.
4. Снять transfer lock, получить EPP‑код.
5. Проверить доступность контактного e‑mail для подтверждений.
6. Инициировать transfer и мониторить почту.
7. После завершения: убедиться, что NS не изменились самопроизвольно.
8. Если нужно — перевести NS в удобное место, вернуть TTL к норме.

Разбор сценариев смены NS без простоя

Если зону надо перенести на другие NS, делайте это не в момент transfer, а отдельно. Безопасная процедура:

1. Подготовить зону на новых NS и проверить её напрямую.
2. Снизить TTL у NS‑ссылок (если зона позволяет) и у A/AAAA/MX/CAA.
3. Переключить NS у регистратора.
4. Наблюдать в течение 24–48 часов, поддерживая актуальность записей на старых NS (двойное ведение).
5. Вернуть TTL к норме.

При наличии DNSSEC план дополняется управлением KSK/ZSK и DS‑записью в реестре. Не смешивайте эти изменения с переносом домена; делайте их отдельным окном.

Сроки и ожидания

В gTLD перенос нередко завершается за 1–3 дня, максимум — до недели. В ряде ccTLD сроки короче или длиннее, возможны офлайн‑проверки. Оцените окно изменений исходя из вашей аудитории и бизнес‑рисков: для высокой нагрузки лучше выбрать период минимального трафика и заранее уведомить заинтересованные команды (SRE, support, маркетинг для отслеживания конверсий).

Итоги

Нулевой простой при переносе домена — это дисциплина DNS, а не магия EPP‑кода. Делайте подготовку зоны заранее, не трогайте NS во время transfer, держите под рукой контактный e‑mail для подтверждений, не запускайте перенос на истекающем домене и внимательно следите за статусами в WHOIS. Такой подход исключает сюрпризы и позволяет переносить домены без риска для сайта и почты.