Коротко. Под «переносом домена» скрываются три разные задачи: смена регистратора, смена владельца и переезд сайта на другой хостинг. При трансфере домен остаётся вашим — ломается почти всегда не он, а DNS-зона, которая жила у старого регистратора. Безопасный порядок: выгрузить все записи, поднять зону у нового провайдера, снизить TTL, сверить ответы и только потом переключать NS.
«Перенос домена» — это три разные задачи
Прежде чем что-то нажимать, определите, что именно вы переносите. Три сценария называются одинаково, но делаются в разных интерфейсах, ломают разные вещи и требуют разных проверок.
- Смена регистратора (трансфер). Домен остаётся ваш, меняется только компания, которая ведёт запись о нём в реестре. Технически это операция в реестре доменной зоны, а не на вашем сервере.
- Смена владельца / администратора. Домен остаётся у того же регистратора, но меняется человек или организация, за которой он числится. Это юридическая операция, а не техническая.
- Перенос сайта на другой хостинг при том же домене. Домен вообще не трогают — меняются A/AAAA-записи или NS. Это не «перенос домена», хотя ищут его именно так.
Если ваш случай — третий, вам сюда: чеклист переезда сайта, подключение домена к хостингу и смена DNS-серверов. Дальше в статье речь идёт о первых двух сценариях — смене регистратора и смене владельца.
| Тип задачи | Что реально меняется | Что может сломаться | Как проверить |
|---|---|---|---|
| Смена регистратора, gTLD (.com, .net, .org, .io и подобные) | Поле registrar в реестре; домен переходит под договор с новой компанией | DNS-зона, если она хостилась у старого регистратора; автопродление; уведомления об истечении | whois — новый registrar и новые статусы; dig NS — делегирование не изменилось |
| Смена регистратора, .RU / .РФ | Регистратор, обслуживающий домен по правилам Координационного центра | То же плюс потеря подтверждённых данных администратора, если они не совпали | whois — поля registrar, state, paid-till, nserver |
| Смена владельца / администратора | Контактные и паспортные данные, на кого оформлен домен | Возможная блокировка трансфера на срок после смены; потеря доступа в личный кабинет | whois — контактные поля; письмо на новый адрес администратора реально доходит |
| Перенос сайта на другой хостинг | A/AAAA-записи или целиком NS; сам домен не двигается | Сайт, почта, SSL, cron, интеграции по IP | dig A, dig MX, проверка HTTPS и тестовое письмо |
Смена регистратора в gTLD: код авторизации, замок, подтверждение
Для международных зон — .com, .net, .org, .info, .io и большинства новых gTLD — порядок трансфера задан политикой ICANN и одинаков у всех регистраторов. Отличаются только интерфейсы.
Снять замок трансфера
По умолчанию домен обычно стоит в статусе clientTransferProhibited — это «замок регистратора» (registrar lock), защита от угона. Пока он висит, реестр отклонит любую заявку на перенос. Снимается в панели текущего регистратора одной галочкой, но иногда после снятия статус обновляется в whois не сразу.
Отдельно существуют статусы, наложенные реестром: serverTransferProhibited. Их регистратор снять не может — это либо судебное решение, либо мера реестра, и разбираться придётся не в панели.
Получить код авторизации
Код авторизации — общее название для того, что регистраторы называют по-разному: auth-код, EPP-код, AuthInfo, Transfer Authorization Code (TAC). Это одноразовый секрет, который доказывает новому регистратору, что заявку подаёт человек с доступом к домену.
Код авторизации — это пароль от домена. Не пересылайте его в открытом чате, не диктуйте по телефону и не оставляйте в тикете поддержки. Утёкший код плюс снятый замок — это готовый сценарий угона.
Практические особенности: код обычно выдаётся по запросу и живёт ограниченное время, после чего его нужно запросить заново; у некоторых регистраторов он приходит письмом на адрес администратора, а не показывается в панели; регистр символов важен; символы вроде 0/O и l/1 лучше копировать, а не перепечатывать.
Подтвердить по e-mail администратора
Заявку на перенос подтверждает контакт администратора домена — тот адрес, который виден (или скрыт) в whois. Если адрес неактуален, ящик закрыт или письмо не доходит, трансфер просто не состоится, и вы даже не поймёте почему. Проверьте доступ к этому ящику до начала переноса — а если он на переносимом домене, заранее убедитесь, что почта продолжит работать всю неделю переезда.
Сколько это занимает
После подачи заявки у нового регистратора текущий регистратор получает уведомление и берёт паузу на возможный отказ. Если владелец ничего не делает, трансфер обычно одобряется автоматически по истечении этого срока — на практике это несколько дней. Если явно подтвердить перенос в панели текущего регистратора, домен переезжает заметно быстрее, иногда за часы.
Важно понимать, чего трансфер не делает: он не меняет NS-серверы автоматически, не переносит содержимое DNS-зоны и не трогает ваш сайт. Домен просто начинает обслуживаться другой компанией. Всё остальное вы делаете руками. Официальные материалы о политике трансфера публикует ICANN.
Смена регистратора в зонах .RU и .РФ: порядок другой
Для .RU и .РФ действует не политика ICANN, а Правила регистрации доменных имён, которые устанавливает Координационный центр доменов .RU/.РФ. Отличий достаточно, чтобы инструкция «получите EPP-код» просто не сработала.
- Нет привычного auth-кода. Смена регистратора в .RU/.РФ оформляется не одноразовым кодом, а заявлением администратора домена по процедуре, которую регистратор описывает в своём регламенте. У части регистраторов заявление подаётся текущему регистратору, у части — новому.
- Личность администратора подтверждается. Данные администратора в реестре должны совпадать с документами заявителя: для физлица — ФИО и паспортные данные, для организации — реквизиты. Расхождение хотя бы в одной букве — типовая причина отказа. Про подтверждение личности при регистрации есть отдельный разбор: регистрация домена через Госуслуги.
- Срок регистрации не меняется. Смена регистратора в .RU/.РФ не продлевает домен: поле
paid-tillостаётся прежним. Это принципиальное отличие от gTLD. - Есть периоды, когда перенос недоступен. Правила и регламенты регистраторов ограничивают смену регистратора в некоторые периоды жизненного цикла домена — например, когда домен не оплачен, снят с делегирования или находится в процедуре преимущественного продления. Конкретные сроки читайте в действующей редакции правил и регламенте вашего регистратора: они меняются, и заучивать их наизусть бессмысленно.
- Whois выглядит иначе. В .RU/.РФ нет EPP-статусов вида
clientTransferProhibited. Вместо них есть полеstateсо значениями вродеREGISTERED,DELEGATED,VERIFIED, а такжеpaid-tillиfree-date.
Не переносите инструкцию для .com на .RU. В gTLD ключ к домену — код авторизации, в .RU/.РФ — подтверждённая личность администратора. Это разные модели доверия, и ошибки в них выглядят по-разному.
Что блокирует трансфер
Заявка на перенос отклоняется чаще, чем кажется, и сообщение об ошибке обычно бесполезное. Вот полный список причин, которые стоит проверить до подачи.
- Включён замок трансфера.
clientTransferProhibitedв whois. Снимается у текущего регистратора. - Свежая регистрация. После первичной регистрации домен некоторое время нельзя переносить. Правило существует и в gTLD, и в национальных зонах; точная длительность зависит от действующей редакции политики.
- Недавний предыдущий трансфер. Домен, который только что сменил регистратора, тоже блокируется на период «остывания». Если вы переезжаете второй раз за месяц — почти наверняка получите отказ.
- Недавняя смена владельца. В gTLD изменение данных регистранта традиционно влекло временный запрет на трансфер. Правило и способ отказаться от него менялись — уточняйте у регистратора актуальный порядок.
- Неактуальный или недоступный e-mail администратора. Самая частая и самая незаметная причина: подтверждение уходит в никуда. Особенно опасно, если ящик расположен на самом переносимом домене.
- Приватность whois скрывает контакт. Услуга privacy protection подменяет адрес администратора прокси-адресом. Часть регистраторов корректно проксирует письмо, часть — нет. Приватность безопаснее временно отключить на время переноса и включить обратно после.
- Спор или претензия. Домен под UDRP, судебным иском или досудебной претензией не переносится — на нём висит серверный статус.
- Задолженность. Неоплаченный домен или отрицательный баланс у текущего регистратора блокируют операцию.
- Домен в периоде восстановления. Просроченный домен в redemption или pendingDelete перенести нельзя: сначала восстановление и продление, потом трансфер.
Если домен уже просрочен, порядок действий другой — про жизненный цикл и сроки восстановления есть отдельный разбор: освобождающиеся домены.
Что происходит со сроком регистрации при трансфере
Распространённый страх — «при переносе домен обнулится и я потеряю оплаченный год». Это не так, но детали различаются по зонам.
- gTLD. Успешный трансфер, как правило, добавляет год к текущему сроку, а не заменяет его. Если домен был оплачен до 2028 года, после переноса он будет оплачен до 2029-го. Есть верхний предел общей длительности регистрации: если домен уже оплачен на максимальный срок вперёд, год может не добавиться.
- .RU / .РФ. Смена регистратора не продлевает домен.
paid-tillостаётся прежним, и продлевать нужно отдельно, уже у нового регистратора. - Трансфер просроченного домена. Если домен переносится после истечения срока, поведение зависит от зоны и стадии жизненного цикла. Безопаснее сначала продлить, потом переносить — это правило работает всегда.
Отдельная ловушка: автопродление привязано к регистратору, а не к домену. Если у старого регистратора стояло автопродление и привязанная карта, у нового по умолчанию не стоит ничего. Домен, который «всегда продлевался сам», молча истечёт через год. Проверьте настройку сразу после переезда и поставьте внешний контроль срока — как это делается, разобрано в статье про мониторинг истечения домена.
Главный подводный камень: DNS уезжает вместе с регистратором
Домен переносится за минуты. Ломается — DNS. Причина в том, что у большинства регистраторов услуга регистрации и услуга DNS-хостинга — это одна учётная запись. Вы уходите — аккаунт закрывается — зона удаляется вместе с MX, TXT, CNAME и всем остальным.
Типовая картина инцидента выглядит так: трансфер прошёл, письмо «домен успешно перенесён» получено, сайт ещё работает — потому что резолверы отдают закешированные записи. Через несколько часов кеш истекает, и всё падает разом: сайт, почта, вебхуки, авторизация через поддомен.
Второй сценарий ещё быстрее: новый регистратор при приёме домена подставляет свои NS по умолчанию с пустой зоной. Делегирование меняется на живые, но пустые серверы имён — и вместо старых записей мир немедленно получает NXDOMAIN. Это не отложенная авария, а мгновенная.
Пока зона не поднята и не сверена у нового провайдера, NS не переключают. Ни при каких обстоятельствах, ни «на пять минут», ни «просто проверить».
Архитектурный вывод: держите DNS отдельно от регистратора. Зона у независимого DNS-провайдера — у хостера, у облака (например, Selectel) или у специализированного сервиса — делает смену регистратора нулевой по риску: вы меняете компанию, ведущую запись в реестре, а делегирование и записи не трогаете вообще.
Как выгрузить всю зону до переезда
Первое действие любого переноса — снимок зоны. Не «посмотрел глазами в панели», а сохранённый в файл вывод, к которому потом можно применить diff. Если панель провайдера умеет экспорт в формате BIND-зоны — используйте его, это самый надёжный вариант. Если нет — собирайте dig.
# Полная выгрузка ключевых типов записей одной командой
for t in SOA NS A AAAA MX TXT CAA SRV DS DNSKEY; do
echo "== $t"
dig +noall +answer example.com "$t"
done | tee zone-before.txt
# Имена, о которых забывают чаще всего
for n in www mail smtp imap ftp api cdn static autodiscover autoconfig \
_dmarc _domainkey default._domainkey selector1._domainkey \
selector2._domainkey _acme-challenge _sip._tls _autodiscover._tcp; do
for t in A AAAA CNAME TXT SRV; do
dig +noall +answer "$n.example.com" "$t"
done
done | tee -a zone-before.txt
# Если провайдер разрешает трансфер зоны — самый полный снимок
dig AXFR example.com @ns1.old-provider.exampledig AXFR у публичных провайдеров почти всегда запрещён — это нормально и правильно. Тогда остаётся перебор типов и имён. Чтобы не пропустить поддомены, о которых вы забыли, пройдитесь по домену поиском поддоменов и сверьте список с тем, что нашли сами.
Снимок зоны нужен не только для переезда. Это ваша единственная возможность восстановить конфигурацию, если панель старого провайдера закроется раньше, чем вы вспомните про SRV-запись для телефонии.
| Тип записи | Зачем нужна | Что ломается при потере |
|---|---|---|
| A | IPv4-адрес, на который резолвится имя | Сайт полностью недоступен: браузер не знает, куда идти |
| AAAA | IPv6-адрес | Тихая деградация: часть пользователей и мониторинг ходят по IPv4 и ничего не замечают, остальные ловят таймаут |
| CNAME | Алиас имени на другое имя: www, CDN, внешние сервисы | Поддомены не резолвятся; отваливаются подтверждения владения у внешних сервисов |
| MX | Куда доставлять входящую почту | Входящая почта не приходит; отправители получают отбойники или молча теряют письма |
| TXT (SPF) | Список серверов, которым разрешено отправлять почту от домена | Исходящие письма помечаются как спам или отклоняются принимающей стороной |
| TXT (DKIM) | Публичный ключ для подписи писем, лежит на селектор._domainkey | Подпись не проверяется, доверие к домену падает, письма уходят в спам |
| TXT (DMARC) | Политика обработки писем, не прошедших SPF/DKIM, на _dmarc | При политике reject и сломанных SPF/DKIM почта отвергается жёстко и сразу |
| TXT (верификации) | Подтверждение владения доменом для поисковиков, почтовых и облачных сервисов | Сервисы теряют подтверждение владения и отключают функции — иногда с задержкой в недели |
TXT _acme-challenge | DNS-валидация при выпуске сертификата | Автопродление сертификата падает; узнаёте об этом в день истечения |
| SRV | Адрес и порт службы: SIP, XMPP, Autodiscover, игровые серверы | Телефония и корпоративные клиенты не находят сервер |
| CAA | Разрешает выпуск сертификатов только указанным центрам | Потеря — риск выпуска чужого сертификата; неверное значение — отказ в выпуске вашего |
| NS | Делегирование зоны: какие серверы имён авторитетны | Ломается весь DNS домена целиком, включая почту и поддомены |
| DS / DNSKEY | Цепочка доверия DNSSEC | Валидирующие резолверы возвращают SERVFAIL — домен исчезает для части интернета |
Правильный порядок переключения NS
Переключение делегирования — единственный необратимо заметный шаг. Всё остальное можно откатить, а переключённые NS живут в кешах и в родительской зоне по своим правилам. Порядок ниже даёт нулевой простой.
- За неделю: инвентаризация. Снимок зоны, список внешних сервисов, которые держат в вашем DNS свои записи (почта, CDN, платёжки, аналитика, вебхуки), список поддоменов.
- За 2–3 дня: поднять зону у нового провайдера. Создать все записи один в один, но не переключать NS. Зона существует, но никто её ещё не спрашивает.
- За 2–3 дня: снизить TTL. Уменьшить TTL записей до 300 секунд на старом провайдере. Важный нюанс: снижать нужно заранее, потому что старое значение TTL само лежит в кешах — если у записи был TTL 86400, ваше изменение дойдёт до резолверов в худшем случае через сутки. Не забудьте про negative TTL в SOA: он определяет, как долго кешируется ответ «такого имени нет».
- За день: сверить ответы. Опросить обе группы серверов имён напрямую и убедиться, что они отвечают идентично. Пока
diffне пустой, переключать нечего. - Час X: переключить NS. Меняем делегирование в панели регистратора. С этого момента резолверы постепенно начинают спрашивать новые серверы.
- После: не удалять старую зону. Оставьте её живой минимум на неделю, а лучше на две. TTL NS-записей в родительской зоне вы не контролируете — он обычно измеряется днями, и часть резолверов будет ходить на старые серверы ещё долго. Пока обе группы отвечают одинаково, расхождение никто не заметит.
- Через неделю: вернуть TTL. Поднять обратно до нормальных значений (обычно от часа), иначе вы бесплатно раздаёте нагрузку на свои DNS-серверы.
# Сверка ответов старых и новых серверов имён, без учёта TTL
OLD=ns1.old-provider.example
NEW=ns1.new-provider.example
norm() { dig +noall +answer @"$1" "$2" "$3" | awk '{$2=""; print}' | sort; }
for t in A AAAA MX TXT CAA SRV NS; do
echo "== $t"
if diff <(norm "$OLD" example.com "$t") <(norm "$NEW" example.com "$t"); then
echo " identical"
fi
done
# То же для поддоменов
for n in www mail api _dmarc _acme-challenge; do
diff <(norm "$OLD" "$n.example.com" TXT) <(norm "$NEW" "$n.example.com" TXT)
doneПодробный разбор самой процедуры смены серверов имён и типовых ошибок — в статье как сменить DNS-сервер, а справочник по значениям и синтаксису записей — в гайде по DNS-записям. Как именно кеши отдают старые ответы и почему «распространение» не мгновенно — в разборе распространения DNS.
DNSSEC: как переезд роняет домен целиком
Если у домена включён DNSSEC, переезд перестаёт быть операцией «скопировал записи». В реестре опубликована DS-запись — отпечаток вашего ключа. Валидирующие резолверы (а это все крупные публичные и большинство провайдерских) проверяют по ней подписи, которые отдаёт ваша зона.
Что происходит при неаккуратном переезде: новый DNS-провайдер подписывает зону своими ключами, а в реестре всё ещё лежит DS от старых. Подпись не сходится с цепочкой доверия — резолвер не отдаёт «старый ответ» и не деградирует до незащищённого режима, он возвращает SERVFAIL. Для пользователя это выглядит как полное исчезновение домена, причём выборочное: у кого резолвер валидирует — сайт мёртв, у кого нет — работает. Отсюда классическое «у меня всё открывается, значит всё в порядке».
DNSSEC не прощает частичного переезда. Домен либо валидируется целиком, либо не резолвится вовсе. «Наполовину работает» — это не состояние DNSSEC.
Безопасные варианты:
- Самый простой: отключить DNSSEC у регистратора (удалить DS), дождаться, пока DS-запись уйдёт из кешей — это занимает время, равное её TTL в родительской зоне, — только потом менять NS, и уже после стабилизации включить DNSSEC заново с ключами нового провайдера.
- Правильный, но сложный: согласованная смена ключей, когда в реестре временно опубликованы DS обеих сторон, а обе зоны отдают обе подписи. Поддерживают не все провайдеры.
- Чего делать нельзя: переключать NS, оставив старый DS. Это гарантированная авария.
# Есть ли DNSSEC у домена: DS публикуется в родительской зоне
dig +short example.com DS
dig +dnssec +multi example.com DNSKEY
# Проверка цепочки доверия целиком
delv example.com A
# Признак сломанного DNSSEC: SERVFAIL от валидирующего резолвера
dig example.com A @1.1.1.1 +noall +comments
# А несломанный DNS при этом виден, если валидацию отключить
dig example.com A @1.1.1.1 +cd +shortЕсли +cd (проверка отключена) отдаёт адрес, а обычный запрос — SERVFAIL, диагноз однозначен: сломана цепочка DNSSEC.
Почта: почему MX и SPF/DKIM/DMARC теряются чаще всего
Почта ломается при переносах чаще сайта, и тому есть три причины.
Первая: почту не видно. Сайт вы открываете каждый день и заметите падение за минуты. Отсутствие входящих писем выглядит как «сегодня тихо» — и обнаруживается через сутки, когда клиент звонит с вопросом, почему не ответили.
Вторая: записей много и они разбросаны. MX лежит на корне домена, SPF — в TXT корня, DKIM — на именах вида selector1._domainkey, DMARC — на _dmarc, а Autodiscover — вообще на CNAME или SRV. При ручном переносе «основных записей» выживает обычно только MX.
Третья: провал частичный. Потеряли MX — входящая встала. Потеряли SPF при живом DMARC с политикой reject — исходящая почта отвергается принимающей стороной, и вы об этом не узнаете, потому что отбойники приходят не вам. Домен при этом «работает».
# Что должно быть на месте после переезда
dig +short example.com MX
dig +short example.com TXT | grep -i 'v=spf1'
dig +short _dmarc.example.com TXT
dig +short selector1._domainkey.example.com TXT
dig +short default._domainkey.example.com TXT
# Селектор DKIM неизвестен? Он написан в заголовке любого
# отправленного письма: DKIM-Signature: ... s=selector1; d=example.com
# Живой ли MX: сервер должен ответить приветствием 220
openssl s_client -starttls smtp -crlf -quiet -connect mail.example.com:25
# Сверка MX между старыми и новыми серверами имён
dig +short @ns1.old-provider.example example.com MX
dig +short @ns1.new-provider.example example.com MXПроверять почту нужно дважды: до переноса — чтобы получить эталон, и после — чтобы сравнить. И обязательно отправьте реальное тестовое письмо в обе стороны: с домена на внешний ящик и обратно. Автоматические проверки не заменяют факта доставки.
SSL: сертификат не привязан к регистратору, но ломается всё равно
Распространённое заблуждение — что при смене регистратора нужно перевыпускать сертификат. Не нужно: сертификат выдан на доменное имя, а не на договор с регистратором, и остаётся валидным. Ломается не сам сертификат, а механика его продления.
- DNS-валидация. Если сертификат выпускается по DNS-01 (обязательно для wildcard), центр сертификации проверяет TXT-запись
_acme-challenge.example.com. Запись создаётся автоматически через API DNS-провайдера. После переезда API другое, токен от старого провайдера не работает — автопродление молча падает. Обнаруживается через два-три месяца, в день истечения. - HTTP-валидация. Проверка по HTTP-01 переживает смену регистратора без проблем, но ломается, если во время переключения NS домен временно резолвится в другой IP.
- CAA-записи. Если в старой зоне была CAA, разрешающая выпуск только определённому центру, и вы её не перенесли — новый выпуск может быть отклонён, а если перенесли с неверным значением, тем более. Проверяйте
dig CAAотдельно. - Внутренние ссылки на старые имена. Если сертификат покрывал поддомены, которые вы забыли перенести, часть страниц отдаст ошибку имени.
# Что реально отдаёт сервер после переезда
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
# CAA — кому разрешено выпускать сертификаты для домена
dig +short example.com CAA
# Жив ли механизм DNS-валидации
dig +short _acme-challenge.example.com TXT
# Пробный прогон продления без выпуска (Let's Encrypt / certbot)
certbot renew --dry-runСертификат, который «ещё валиден», ничего не говорит о том, продлится ли он. Проверяйте не срок, а работоспособность продления — и делайте это сразу после переезда, а не за день до истечения.
Смена владельца или администратора — это не трансфер
Вторая задача, которую называют «переносом домена»: домен нужно передать другому человеку или юрлицу. Технически домен никуда не двигается — меняются данные регистранта.
- В gTLD смена регистранта оформляется у регистратора и традиционно сопровождается подтверждением от обеих сторон и временным запретом на трансфер после изменения. Если планируется и смена владельца, и смена регистратора — делайте их по очереди, а не одновременно, иначе вторая операция упрётся в блокировку от первой.
- В .RU/.РФ это передача прав администрирования: требуется подтверждение личности обеих сторон по документам, процедура описана в регламенте регистратора. Данные нового администратора проходят проверку так же, как при регистрации.
- Что проверить после: доступ в личный кабинет реально перешёл; e-mail администратора в whois — рабочий и принадлежит новой стороне; автопродление и способ оплаты привязаны к новому владельцу; технический доступ к DNS-зоне не остался у прежнего подрядчика.
Самая частая потеря домена — не угон, а обычная смена подрядчика. Домен зарегистрирован на веб-студию, студия сменилась, доступов нет. Проверьте в whois, на кого оформлен домен, до того, как это станет срочным вопросом.
Как читать поля whois и что означает каждое — разобрано в гайде по WHOIS. Выбор регистратора и критерии сравнения — в обзоре регистраторов доменов.
Проверка после переезда
Перенос считается завершённым не тогда, когда пришло письмо от регистратора, а тогда, когда сходятся четыре проверки: реестр, DNS, почта и HTTPS.
# 1. Реестр: кто теперь обслуживает домен
whois example.com | grep -Ei 'registrar|status|expir|name server'
# Для .RU / .РФ поля называются иначе
whois example.ru | grep -Ei 'registrar|state|nserver|paid-till|free-date'
# Машиночитаемо, для gTLD
curl -s https://rdap.org/domain/example.com | jq '{status: .status, events: .events}'
# 2. DNS: делегирование и совпадение ответов
dig +short example.com NS
for t in A AAAA MX TXT CAA; do
echo "== $t"
dig +short @8.8.8.8 example.com "$t"
dig +short @1.1.1.1 example.com "$t"
dig +short @77.88.8.8 example.com "$t"
done
# 3. Не осталось ли расхождений со снимком.
# Важно: dig не умеет несколько типов в одной команде — только цикл,
# иначе последний тип просто перезапишет предыдущие
for t in SOA NS A AAAA MX TXT CAA SRV DS DNSKEY; do
echo "== $t"
dig +noall +answer example.com "$t"
done > zone-after.txt
diff zone-before.txt zone-after.txtРазные публичные резолверы отдают разное — распространение ещё идёт, ждём. Разные авторитетные серверы отдают разное — это уже ошибка конфигурации, ждать бессмысленно.
Разбор типовых аварий
| Симптом | Вероятная причина | Проверка | Фикс |
|---|---|---|---|
| Сайт лёг через несколько часов после «успешного» трансфера | Зона удалена вместе с аккаунтом у старого регистратора, кеш истёк | dig +short example.com A пуст; dig NS показывает новые пустые серверы | Поднять зону из снимка у любого DNS-провайдера, переключить NS туда |
| Домен не открывается вообще, у части людей — работает | Сломана цепочка DNSSEC: DS в реестре от старых ключей | dig @1.1.1.1 example.com A — SERVFAIL, с +cd — ответ есть | Удалить DS у регистратора, дождаться истечения TTL, включить DNSSEC заново |
| Сайт работает, входящая почта пропала | MX не перенесены или указывают на старый почтовый сервер | dig +short example.com MX, сравнение со снимком | Восстановить MX из снимка, проверить приоритеты, отправить тестовое письмо |
| Исходящие письма уходят в спам или отбиваются | Потеряны TXT со SPF и DKIM при живой политике DMARC | dig +short example.com TXT, dig +short _dmarc.example.com TXT | Вернуть SPF и все DKIM-селекторы; временно ослабить DMARC до p=none на время починки |
| Через два месяца упал сертификат | Автопродление по DNS-01 не может создать _acme-challenge у нового провайдера | certbot renew --dry-run возвращает ошибку валидации | Перевыпустить учётные данные API нового DNS-провайдера в конфиге ACME-клиента |
| Часть поддоменов не резолвится | CNAME и A поддоменов не попали в новую зону | Перебор имён из снимка через dig | Добавить недостающие записи; свериться со списком поддоменов |
| Домен молча истёк через год после переезда | Автопродление осталось у старого регистратора | whois — дата истечения; настройки нового кабинета | Включить автопродление, привязать оплату, поставить внешний мониторинг срока |
| Внешний сервис (почта, аналитика, CDN) отключил функции | Потеряна TXT-запись подтверждения владения | Сравнить TXT корня со снимком | Вернуть TXT или пройти подтверждение владения заново |
Когда лучше не переносить домен
Технически перенос можно запустить в любой момент. Практически есть окна, в которые этого делать не стоит — не потому, что не получится, а потому, что цена ошибки резко вырастает.
- За неделю до истечения срока регистрации. Худшее время из возможных: заявка может не успеть обработаться, домен уйдёт в просрочку, а из просрочки трансфер обычно уже недоступен. Сначала продлите, потом переносите.
- Перед распродажей, запуском кампании или сезонным пиком. Любая рекламная кампания идёт на домен. Простой в этот момент стоит не «часов недоступности», а бюджета.
- В пятницу вечером и накануне праздников. Классическое правило деплоя работает и здесь: поддержка регистратора отвечает в рабочие часы, а DNS-кеши не разбирают выходных. Оптимально — вторник или среда утром.
- Одновременно с переездом хостинга. Два изменения сразу — и вы не понимаете, что именно сломалось. Разнесите на разные дни.
- Пока не восстановлен доступ к e-mail администратора. Без рабочего ящика подтверждать нечем.
- Сразу после смены владельца. Скорее всего, упрётесь в блокировку трансфера.
- Когда некому дежурить. Переезд требует человека, который в ближайшие сутки посмотрит на алерты. Если такого человека нет — переносите тогда, когда он будет.
Правило дежурства: переносите домен в тот момент, когда у вас есть минимум сутки на реакцию и доступ ко всем панелям — старого регистратора, нового и DNS-провайдера. Потерянный доступ хотя бы к одной из трёх превращает мелкую ошибку в многочасовой простой.
Чеклист: до, в день и после
За неделю до переноса
- Определить, какая из трёх задач решается: регистратор, владелец или хостинг.
- Проверить в whois срок регистрации, статусы и адрес администратора.
- Продлить домен, если до истечения меньше месяца.
- Убедиться, что e-mail администратора доступен и не расположен на переносимом домене.
- Снять полный снимок зоны в файл и проверить его глазами на полноту.
- Составить список внешних сервисов, которые держат записи в вашем DNS.
- Выяснить, включён ли DNSSEC, и спланировать его отключение или согласованный перенос ключей.
- Проверить, работает ли автопродление сертификата и как именно он валидируется.
За 1–3 дня
- Поднять зону у нового DNS-провайдера, записи один в один.
- Снизить TTL на старом провайдере до 300 секунд, включая negative TTL в SOA.
- Сверить ответы старых и новых серверов имён через
diff, добиться пустого вывода. - Снять замок трансфера и получить код авторизации (gTLD) либо подготовить документы (.RU/.РФ).
- Временно отключить приватность whois, если она скрывает адрес администратора.
- Отправить тестовые письма в обе стороны и сохранить заголовки как эталон.
В день переноса
- Подать заявку у нового регистратора и подтвердить её по e-mail.
- Явно одобрить перенос в панели старого регистратора, чтобы не ждать автоодобрения.
- Убедиться, что новый регистратор не подставил свои NS автоматически.
- Переключить NS на нового DNS-провайдера — только после успешной сверки.
- Проверить A, AAAA, MX, TXT, CAA через несколько публичных резолверов.
- Открыть сайт по HTTPS, проверить сертификат и отправить тестовое письмо.
После переноса
- Дождаться совпадения ответов всех публичных резолверов.
- Сравнить снимок «после» со снимком «до» и объяснить каждое расхождение.
- Включить автопродление домена у нового регистратора и привязать оплату.
- Прогнать
certbot renew --dry-runили аналог, убедиться, что продление работает. - Включить DNSSEC заново с ключами нового провайдера, если он был отключён.
- Не удалять старую зону минимум неделю.
- Вернуть TTL к обычным значениям.
- Поставить мониторинг: срок домена, содержимое DNS-записей, MX, срок сертификата.
Как проверить
Всё, что описано выше, можно прогнать без консоли — прямо в браузере, включая машины, где нет dig.
- WHOIS-проверка домена — регистратор, статусы, дата истечения, контакты. Первое, что смотрят до и после трансфера.
- Проверка DNS-записей — все типы записей домена в одном месте: A, AAAA, MX, TXT, NS, CAA, SRV.
- Проверка распространения DNS — что отдают резолверы в разных точках мира; так видно, сошлось делегирование или ещё нет.
- Проверка MX-записей — куда сейчас доставляется почта домена и отвечают ли серверы.
- Проверка почтовых настроек — SPF, DKIM и DMARC вместе, с разбором ошибок синтаксиса.
- Проверка SSL-сертификата — срок, цепочка, покрытые имена, соответствие домену.
- Мониторинг сайта и домена — постоянный контроль срока домена, дрейфа DNS-записей и срока сертификата с оповещениями в Telegram, Slack или почту.
Разовая проверка ловит ошибку переезда. Мониторинг ловит то, что сломается через месяцы: молча отвалившееся автопродление, изменённую кем-то запись, истекающий сертификат.
Частые вопросы
Потеряю ли я оплаченный срок при переносе домена к другому регистратору?
Нет. В gTLD трансфер обычно добавляет год к текущему сроку, а не заменяет его. В .RU/.РФ смена регистратора срок не меняет вообще: paid-till остаётся прежним. Ни в одном из вариантов оплаченное время не сгорает.
Сайт упадёт во время переноса домена?
Сам трансфер сайт не трогает: он меняет запись в реестре, а не DNS. Падение случается, если вместе с регистратором вы теряете DNS-зону или если новый регистратор подставляет свои пустые серверы имён. Поднимите зону заранее у независимого провайдера — и простоя не будет.
Нужно ли перевыпускать SSL-сертификат после смены регистратора?
Нет, сертификат выдан на доменное имя и остаётся валидным. Проверить нужно другое — работает ли автоматическое продление: при DNS-валидации оно завязано на API старого DNS-провайдера и после переезда обычно перестаёт работать.
Почему при переносе домена .RU не спрашивают EPP-код?
Потому что в .RU и .РФ его нет. Смена регистратора там оформляется заявлением администратора домена с подтверждением личности по документам, по правилам Координационного центра и регламенту регистратора. Код авторизации — механика gTLD.
Сколько времени занимает перенос домена?
В gTLD — от нескольких часов, если явно подтвердить перенос у текущего регистратора, до нескольких дней при автоодобрении. В .RU/.РФ срок определяется правилами и регламентом регистратора. К этому нужно прибавить время на схождение DNS: при заранее сниженном TTL — минуты и часы, при высоком — до суток и дольше.
Можно ли перенести домен, если утерян доступ к почте администратора?
Сначала восстановите контакт. В gTLD его меняют у текущего регистратора, после чего может включиться временный запрет на трансфер. В .RU/.РФ изменение данных администратора проходит через процедуру подтверждения личности. Обходных путей нет — и это правильно, иначе домены угонялись бы через подмену контакта.
Что делать, если после переноса домен вообще перестал открываться?
Проверьте три вещи по порядку. Первое: dig +short example.com NS — какие серверы имён отвечают. Второе: отвечают ли они реальными записями или зона пустая. Третье: dig example.com A @1.1.1.1 — если SERVFAIL, а с флагом +cd ответ есть, дело в DNSSEC и старой DS-записи в реестре. Восстановление зоны из снимка занимает минуты — если снимок вы сделали.
Стоит ли держать домен и хостинг у одной компании?
Удобно, но повышает связность: одна учётная запись — и регистрация, и DNS, и сайт. При смене подрядчика или конфликте вы теряете всё сразу. Разнесение регистратора, DNS-провайдера и хостинга по разным компаниям делает любую последующую миграцию почти бесплатной.
Проверьте домен перед переносом — регистратор, статусы и срок регистрации на странице WHOIS, полный набор записей на странице проверки DNS, а после переезда поставьте мониторинг, чтобы не узнать об истёкшем домене от клиентов.