Массовый перенос доменов: подробное руководство 2026
Перенести один домен — административная задача. Перенести четыреста — проект. Портфели, которые росли годами, обычно распределены между тремя или четырьмя регистраторами и несколькими платёжными аккаунтами, где рядом стоят международные и национальные зоны, и у каждой своё поведение блокировки и своя дата окончания. Сами шаги несложные. Сложно выполнить их в правильном порядке, в большом объёме и не уронив при этом сайт клиента или его почту. Это руководство описывает подготовку, выполнение, разбор отказов и проверку, которых на самом деле требует крупная миграция.
Что такое массовый перенос доменов?
Массовый перенос доменов переводит множество имён от одного регистратора к другому одной скоординированной отправкой. Каждый домен при этом всё равно разблокируется отдельно, подтверждается собственным кодом переноса и рассматривается реестром индивидуально. Поэтому результат определяет подготовка: корректные контактные данные, действующие коды и проверенная пригодность до отправки.
| Главное
|
|---|
Как работает массовый перенос доменов?
Массовый перенос — это сгруппированная отправка нескольких заявок на смену регистратора: списком в панели или последовательностью вызовов API. Группировка происходит на уровне интерфейса. Под ней каждый домен проходит тот же путь, что и одиночный перенос: принимающий регистратор передаёт заявку в реестр вместе с кодом переноса, реестр проверяет код, отдающий регистратор получает определённое окно на реакцию, и реестр выносит решение по этому конкретному домену. Полезно разделять три роли. Реестр обслуживает зону и хранит основную запись. Регистратор имеет аккредитацию или договор с этим реестром и подаёт заявку от вашего имени. Администратор домена — законный владелец имени. Перенос меняет регистратора. Он не меняет владельца и не переносит DNS, пока вы не сделаете это отдельно. Отсюда самая частая неожиданность. Партия из 300 доменов, вернувшая 274 подтверждения и 26 отказов, не провалилась частично как партия. Она дала 26 отдельных отказов, у каждого своя причина и своё решение.
Чек-лист перед переносом домена
Пройдите эти пункты до того, как что-либо отправите. Почти любая сорвавшаяся миграция объясняется пунктом из этого списка, пропущенным для части портфеля.
| Проверка | Почему это важно | Что сделать |
|---|---|---|
| Блокировка переноса | Заблокированный домен реестр отклонит независимо от того, как была отправлена заявка. | Снять блокировку со всех доменов партии и подтвердить статус на стороне реестра, а не только в панели. |
| Действующий код авторизации | Большинство зон требует код, проверяемый реестром, и у многих кодов ограниченный срок. | Получать коды близко к отправке, проверять их полноту и заново запрашивать просроченные. |
| Данные администратора домена | Подтверждения и уведомления уходят на адрес, указанный в записи. Терминология сместилась: текущая работа ICANN строится вокруг владельца имени, а не отдельного административного контакта. | Убедиться, что этот адрес читает человек, способный действовать, и исправить его до старта. |
| Недавняя регистрация или перенос | В международных зонах политика ICANN обычно вводит ограничение на 60 дней после регистрации, после предыдущего переноса и после отдельных изменений владельца. | Отметить такие домены и запланировать их в более позднюю партию вместо того, чтобы принимать отказ. |
| Близость даты окончания | Домен на грани окончания может в процессе уйти в льготный период и усложнить операцию. | Продлить до миграции или перенести такие имена отдельной партией под плотным контролем. |
| Коды состояния домена | Удерживающие статусы реестра или регистратора блокируют перенос и не видны, если их не смотреть. | Проверить коды состояния через WHOIS или RDAP и снять удержания до отправки. |
| DNSSEC | У подписанного домена валидация ломается, если DS-записи в реестре перестают соответствовать цепочке подписи. | Если провайдер DNS и ключи не меняются, запланировать перенос существующих DS-записей принимающим регистратором. Удалять только если цепочка меняется или перенести записи невозможно. |
| Сервисы приватности | Прокси-контакт может встать между реестром и человеком, который должен подтвердить. | Проверить, влияет ли сервис на авторизацию и уведомления в этой зоне, и отключать только если этого требует регистратор или реестр. |
| Баланс аккаунта | Переносы платные, и отклонённый платёж останавливает партию. | Пополнить принимающий аккаунт на всю партию, включая премиальные и ограниченные зоны. |
| Правила конкретной зоны | Национальные реестры могут требовать документы, локальное присутствие или дополнительное согласование. | Выделить такие зоны и подтвердить процедуру каждого реестра до планирования сроков. |
Как перенести несколько доменов: пошаговая инструкция
Последовательность рассчитана на портфель в несколько сотен доменов у нескольких отдающих регистраторов. Размер партий подстраивайте под свой объём, порядок не меняйте.
- Соберите инвентарь. Выгрузите всех регистраторов и все аккаунты в одну таблицу: домен, зона, текущий регистратор, дата окончания, серверы имён, состояние DNSSEC, состояние блокировки, адрес владельца, ответственный со стороны бизнеса и критичность.
- Сгруппируйте. Отсортируйте по зоне и по отдающему регистратору. Эти две оси определяют, какие правила применяются и в какой панели вы работаете, а значит определяют и партии.
- Разделите по критичности. Отдельно домены, приносящие выручку, домены с почтой, простые редиректы и спящие защитные регистрации. Две последние группы — идеальные кандидаты на пилот.
- Уберите препятствия. Пройдите чек-лист по каждой группе: снять блокировку, исправить контактные данные, продлить то, что скоро заканчивается, и отложить всё, что попадает под ограничение.
- Запустите пилотную партию. Пять-десять неответственных доменов одной зоны. Пилот проверяет вашу работу с кодами, маршрут подтверждений и отчётность по статусам до того, как ошибка дойдёт до чего-то важного.
- Соберите коды безопасно. Получайте их в той же сессии, в которой планируете отправку, храните в контролируемом хранилище, а не в общей таблице, и относитесь к ним как к учётным данным.
- Отправляйте партиями. Группируйте по зоне и отдающему регистратору, держите партии достаточно небольшими, чтобы системная ошибка осталась локальной, и оставляйте паузу между отправками.
- Следите за статусами ежедневно. Ведите состояния в обработке, подтверждено и отклонено по каждому домену. Тишина не означает движение: подтверждения часто лежат непрочитанными в общем ящике.
- Проверяйте непрерывность после каждой партии. Проконтролируйте серверы имён, откройте сайт, отправьте и получите тестовое письмо на доменах с почтой и убедитесь, что продление сертификатов через проверку домена по-прежнему работает.
- Завершите аудитом. Верните блокировки, проверьте даты окончания и автопродление, сверьте итоговое количество доменов с исходным инвентарём.
Код авторизации и EPP-код: как их подготовить
Код переноса — это учётные данные, подтверждающие правомерность заявки. В панелях и документации он встречается под разными названиями: код авторизации, EPP-код, AuthInfo, а в текущей работе ICANN — Transfer Authorization Code, или TAC. Речь об одном и том же механизме, и требования к обращению с ним одинаковые. Три свойства дают большую часть сбоев при объёме. Коды часто ограничены по сроку, поэтому таблица, собранная за три недели до отправки, в день отправки частично бесполезна. Некоторые регистраторы отправляют код только на адрес владельца, вместо того чтобы показать его в панели, и тогда заброшенный почтовый ящик превращается в жёсткое препятствие. И коды чувствительны к регистру и достаточно длинные, чтобы обрезанный при копировании символ обнаружился только при отказе реестра. Относитесь к ним как к паролям: получайте близко к моменту использования, храните в менеджере секретов, а не в общем документе, ограничьте доступ командой миграции и удаляйте после завершения переноса. Утекший список действующих кодов по целому портфелю — это готовый набор для перехвата доменов.
Как сделать массовый перенос доменов в панели
Сама отправка обычно проще, чем предшествующая ей подготовка. В реселлерской панели Domain Name API переносы находятся в разделе Domain Management, где две вкладки разделяют сценарии: запрос по одному имени и групповой запрос для партии.
Групповой запрос на перенос в панели Domain Name API: в каждой строке домен и его код переноса. Поле ожидает по одному домену в строке, затем пробел и код этого домена. Ожидаемый формат показан прямо над полем, поэтому подготовленный список вставляется напрямую, а запрос выполняется до того, как что-либо станет обязательством. Этот формат важен уже на подготовке, потому что определяет структуру вашей инвентарной таблицы: домен и код в соседних столбцах и в одном порядке строк, и тогда финальная выгрузка превращается во вставку, а не в сверку. Ограничения по размеру партии и по запросам показаны в самой панели и могут меняться, поэтому уточните действующие значения в своём аккаунте до планирования крупного портфеля.
Пять вещей, которые нужно проверить перед вставкой списка
У подготовки длинный хвост, но несколько проверок отлавливают почти всё, что идёт не так.
- Код ещё жив? Коды стареют. Получайте их в день отправки, а не за неделю.
- Блокировка действительно снята? Панель говорит «снята». Решает реестр.
- Кто получит подтверждение? Если это бывший сотрудник, перенос уже остановлен.
- Что заканчивается в ближайшие тридцать дней? Продлевайте сейчас, а не посреди переноса.
- На каких именах почта? Эти идут последними, малой партией и под наблюдением.
Почему перенос домена срывается и как это исправить?
Сбои укладываются в небольшое число сценариев. Таблица связывает видимый симптом с вероятной причиной и с действием, которое его снимает.
| Проблема | Вероятная причина | Решение |
|---|---|---|
| Немедленный отказ | Блокировка всё ещё активна или её снятие не дошло до реестра. | Проверить статус через WHOIS или RDAP, а не в панели, снять блокировку заново и отправить повторно. |
| Код авторизации недействителен | Код просрочен, обрезан при копировании или зона использует другой механизм. | Сгенерировать код заново, вставить без пробелов и уточнить реальное требование зоны. |
| Подтверждение не приходит | Указанный адрес устарел или фильтруется, либо сервис приватности перенаправляет уведомление. | Обновить запись, проверить спам-карантин и запросить повторную отправку до того, как менять что-то ещё. |
| Отказ из-за ограничения 60 дней | Домен зарегистрирован, перенесён или сменил владельца в последние 60 дней. | Зафиксировать дату снятия ограничения и запланировать домен в более позднюю партию. |
| Перенос застревает у даты окончания | Домен закончился или ушёл в льготный период в процессе. Обработка зависит от регистратора и зоны. | Продлить у отдающего регистратора, дать продлению закрепиться и запустить перенос заново. |
| Домен недоступен после переноса | DS-записи больше не соответствуют цепочке подписи, либо серверы имён были сброшены. | Немедленно восстановить серверы имён, затем привести DS-записи в соответствие с реально используемыми ключами. |
| Отказ в национальной зоне | Зона работает по собственной процедуре, а не по стандартному коду авторизации. | Действовать по опубликованному регламенту этого реестра, который может требовать документы или дополнительное согласование. |
| Один домен блокирует всё | На имени висит спор, судебное решение или удержание реестра. | Сначала решить сам вопрос; спорные домены не должны попадать в партию. |
| Партия незаметно неполная | Отказы не всплыли, потому что никто не сверил отправленный список с полученным. | Сверять количества после каждой партии и любую разницу вести как открытый вопрос. |
Влияет ли перенос домена на DNS, сайт и почту?
Смена регистратора переносит регистрационную запись, а не привязанные к ней сервисы. Делегирование на серверы имён обычно переживает переход, поэтому большинство переносов проходит незаметно. Риск возникает тогда, когда отдающий регистратор одновременно хостил DNS: эта зона может быть удалена после ухода домена и заберёт с собой каждую запись A, MX, TXT и CNAME. Безопасная последовательность разводит два изменения: сначала перенесите DNS-хостинг туда, где он должен остаться, убедитесь, что зона корректно резолвится, дайте ей поработать несколько дней и только потом переносите регистрацию. Если оба шага должны произойти одновременно, выгрузите все зонные файлы до начала и восстановите их у нового провайдера до переключения делегирования. Снизьте TTL критичных записей за день-два, тогда ошибка исправляется за минуты, а не за часы. Почта заслуживает отдельного внимания, потому что её сбои тихие. Убедитесь, что записи MX, SPF, селекторы DKIM и политика DMARC воспроизведены в точности. Отсутствующий селектор DKIM не останавливает почту: он тихо увеличивает долю исходящих писем, попадающих в спам, и через неделю никто уже не свяжет это с миграцией. DNSSEC требует решения, а не рефлекса. Если провайдер DNS и подписывающие ключи не меняются, DS-записи в реестре остаются действительными, и задача сводится к тому, чтобы принимающий регистратор смог их вести. Удалять DS-записи уместно только тогда, когда меняется цепочка подписи, когда DNS уходит к провайдеру с другими ключами или когда новый регистратор не может поддерживать эти записи. В таких случаях сначала удалите, дайте старым значениям истечь и подпишите заново после миграции. Несоответствующая DS-запись делает домен недоступным для любого валидирующего резолвера, и это самый тяжёлый исход всего процесса.
Безопасность при переносе большого портфеля доменов
Миграция собирает нетипичные привилегии в одном окне: разблокированные домены, действующие коды и расширенный доступ к аккаунтам. Относитесь к этому периоду как к зоне повышенного риска.
- Включите двухфакторную аутентификацию на отдающем и принимающем аккаунтах до начала, а не после.
- Ограничьте круг людей, которые могут запрашивать коды и снимать блокировки, и используйте именные учётные записи.
- Раздавайте коды через менеджер паролей. Почтовые и мессенджерные переписки живут гораздо дольше, чем срок действия кода.
- Возвращайте блокировку на каждый домен сразу после завершения переноса. Портфель, оставшийся разблокированным после миграции, — постоянный риск.
- Отслеживайте запросы кодов, которых вы не инициировали. Неожиданная генерация кода во время миграции требует немедленной проверки.
Если вы работаете через API, примените ту же дисциплину к учётным данным. Материал Domain Name API о безопасности API-ключей и ошибках доступа разбирает переменные окружения, списки разрешённых IP, ротацию ключей и порядок действий при утечке.
Перенос домена .ru: правила Координационного центра и gTLD
Международные зоны вроде .com, .net и .org работают по политике переноса ICANN, которая унифицирует авторизацию, сроки ответа и основания для отказа между аккредитованными регистраторами. Национальные реестры устанавливают свои регламенты и не обязаны следовать этой модели. Зоны .ru и .рф администрируются по правилам Координационного центра доменов .RU/.РФ, и порядок смены регистратора там задан этими правилами, а не моделью кода авторизации из международных зон. На практике это значит, что процедура, набор подтверждений и сроки могут заметно отличаться от привычных по .com. Уточните действующий порядок у текущего регистратора до планирования и ведите блок .ru и .рф как отдельное направление, а не как часть общей партии. В других национальных зонах различия ещё более структурные. Перенос .uk завершается сменой метки IPS, идентифицирующей обслуживающего регистратора, а не отправкой кода. Другие реестры требуют документы, локальное присутствие или согласование в собственном портале. Международные зоны движутся крупными партиями; национальные обычно нет, и планирование по обратному допущению — самая частая причина срыва сроков миграции.
После переноса: чек-лист проверки
Статус «завершено» у переноса не означает завершённую миграцию. Пройдите этот список по каждой партии, пока причины ещё можно связать со следствиями.
- Сверьте количество принятых доменов с количеством отправленных и объясните каждое расхождение.
- Проверьте серверы имён относительно задуманной конфигурации, а не относительно того, что случайно резолвится.
- Разрешите каждое рабочее имя и откройте сайт по HTTPS, чтобы поймать проблемы с сертификатами.
- Отправьте и получите тестовое письмо на каждом домене с почтой, затем проверьте согласованность SPF, DKIM и DMARC.
- Проверьте даты окончания. Большинство международных зон добавляют год при переносе, часть национальных — нет.
- Настройте автопродление единообразно и убедитесь, что к аккаунту привязан действующий способ оплаты.
- Верните блокировку переноса и, где уместно, восстановите сервисы приватности.
- Если домен был подписан, убедитесь, что DNSSEC валидируется и DS-записи соответствуют используемым ключам.
- Обновите реестр активов и мониторинг, чтобы они указывали на нового провайдера.
Панель реселлера или API: что выбрать для миграции
Ни один из подходов не лучше сам по себе. Всё решает то, как часто вы будете повторять эту работу и какую её часть можно безопасно автоматизировать.
| Сценарий | Реселлерская панель | API | Что подходит |
|---|---|---|---|
| Разовая миграция до нескольких сотен доменов | Достаточно, разработка не нужна | Затраты превышают выигрыш | Панель |
| Регулярные миграции для клиентов | Однообразно и подвержено ошибкам | Воспроизводимо и поддаётся аудиту | API |
| Смешанный портфель с национальными зонами | Хорошо переносит исключения и ручные шаги | Исключения требуют собственной логики | Панель, API для стандартных зон |
| Отслеживание статусов между партиями | Ручная сверка | Программный опрос и отчётность | API |
| Синхронизация с биллингом | Вручную или через выгрузку | Нативно через модуль или интеграцию | API или модуль |
| Команда без ресурсов разработки | Можно использовать сразу | Нереализуемо без инженерии | Панель |
| Постоянная работа с портфелем после миграции | Достаточно при небольшом объёме | Масштабируется вместе с портфелем | API |
Если автоматизируете, соблюдайте ограничения провайдера с первой строки кода. Domain Name API публикует политику лимитов, троттлинга и массового использования API, которая разделяет вызовы в реальном времени на /api и автоматизированную работу на /api-bulk, задаёт предел в один запрос в секунду на API-ключ и описывает ожидаемое экспоненциальное отступление после ответа HTTP 429. Очередь, соблюдающая этот предел с самого начала, обходится дешевле, чем достроенная после ограничения доступа.
Массовый перенос доменов с Domain Name API
Для миграции важны три вещи. Панель и REST API покрывают регистрацию, перенос, продление и управление DNS, поэтому портфель можно вести через тот интерфейс, который удобен команде. Есть модули для WHMCS, WiseCP, HostBill, Blesta и ClientExec, что существенно, когда биллинг не должен разъехаться во время перехода. И опубликованная политика массового использования говорит о допустимой автоматической нагрузке до того, как вы напишете код, а не после. На странице реселлерской программы также сказано, что реселлерам, приходящим с другой платформы, помогают с переездом: вы передаёте список доменов, снимаете блокировки и предоставляете коды переноса, а процесс переноса ведёт команда поддержки. Эта же страница указывает на проблему, описанную выше в руководстве: уведомления о подтверждении приходят на контакты в записи домена, а не реселлеру. Максимальный размер партии не опубликован, и здесь он не утверждается. Domain Name API — реселлерская программа на инфраструктуре аккредитованного ICANN регистратора Atak Domain. Опубликованные цифры стоит сопоставить со своими требованиями: доступ более чем к 800 доменным зонам, более 40 000 активных реселлеров в более чем 200 странах и более двадцати лет работы в доменной отрасли. Для портфелей со сложными требованиями по национальным зонам обсудите их с поддержкой до планирования сроков. Тем, кто оценивает переход, помогут описание реселлерской программы и варианты интеграции через API и модули.
Заключение
Массовый перенос доменов — прежде всего работа по подготовке. Сама отправка занимает минуты; инвентарь, снятие препятствий, порядок изменений в DNS и проверка — вот где сосредоточены и работа, и риск. Соберите инвентарь, уберите препятствия, потренируйтесь на именах, которые не могут вам навредить, переносите контролируемыми партиями и проверяйте каждую партию до отправки следующей. Если вы выбираете, куда переводить портфель, сравните цены переноса и продления по своему реальному набору зон, откройте реселлерский аккаунт и попробуйте панель до отправки крупной партии, а также уточните, как провайдер работает с национальными зонами, от которых вы зависите.
Частые вопросы
Каждый ответ начинается с прямого утверждения и только затем добавляет необходимую оговорку. Такая структура выбрана намеренно: она позволяет системам ответов извлечь короткий и точный ответ, не потеряв оговорку.
Что такое массовый перенос доменов?
Это сгруппированная отправка нескольких заявок на смену регистратора одной операцией. Группировка происходит на уровне интерфейса; каждый домен по-прежнему проверяется и обрабатывается своим реестром индивидуально.
Можно ли перенести несколько доменов одновременно?
Да, если каждый домен по отдельности отвечает требованиям своей зоны. Заблокированные, попавшие под ограничение, близкие к окончанию и не имеющие действующего кода будут отклонены, даже если остальная партия пройдёт.
Каждому ли домену нужен код авторизации?
Большинству зон нужен, но не всем. Международные зоны используют код переноса, который в разных источниках называют кодом авторизации, EPP-кодом, AuthInfo или TAC. Некоторые национальные зоны используют совсем другой механизм, например .uk со сменой метки IPS.
Сколько занимает массовый перенос?
Зависит от зоны, от реакции отдающего регистратора и от того, вовремя ли обрабатываются подтверждения. Международные зоны обычно завершаются за несколько дней после корректной заявки, национальные различаются заметно. Единый срок для смешанного портфеля никто гарантировать не может.
Перенос домена .ru проходит иначе?
Да. Зоны .ru и .рф работают по правилам Координационного центра доменов .RU/.РФ, и порядок смены регистратора там задан этими правилами, а не моделью кода авторизации из международных зон. Уточните действующую процедуру у текущего регистратора и ведите этот блок отдельной партией.
Можно ли перенести домен с истёкшим сроком?
Как правило нет, и ответ зависит от регистратора и зоны. Часть регистраторов обработает перенос, пока домен в льготном периоде; после перехода в период восстановления перенос фактически недоступен. Продление перед переносом — предсказуемый путь.
Влияет ли перенос на мой сайт?
Сам по себе нет. Регистрационная запись меняет регистратора, делегирование на серверы имён обычно остаётся. Риск в том, что DNS-зона размещалась у отдающего регистратора и может быть удалена после ухода домена. Выгрузите зонные файлы заранее.
Может ли почта перестать работать во время переноса?
Может, если DNS-записи потеряются или будут восстановлены неверно. MX, SPF, селекторы DKIM и DMARC должны быть воспроизведены в точности. Отсутствие записей аутентификации редко останавливает почту полностью, зато повышает вероятность попадания в спам, что заметить сложнее.
Почему перенос срывается?
Чаще всего из-за активной блокировки, недействительного или просроченного кода, контактного адреса, который никто не читает, регистрации или переноса в последние 60 дней, близости даты окончания, удержания на стороне реестра или регистратора и национальных зон с собственной процедурой.
Ускоряет ли групповая отправка отдельные переносы?
Нет. Группировка сокращает ваше время обработки, а не время реестра. Каждый домен по-прежнему рассматривается в своём темпе и по своим правилам.
Продлевать ли домены перед переносом?
Продлите всё, что близко к окончанию. Большинство международных зон добавляют год при завершении переноса, поэтому раннее продление редко пропадает и снимает риск того, что домен закончится во время заявки.
Нужно ли снимать DNSSEC перед переносом?
Не автоматически. Если провайдер DNS и ключи не меняются, существующие DS-записи остаются действительными, и вопрос лишь в том, сможет ли принимающий регистратор их вести. Снимать и настраивать заново нужно, только если меняется цепочка подписи или записи там вести невозможно.
Обязателен ли API для большого портфеля?
Нет. Разовую миграцию нескольких сотен доменов панель выдержит спокойно. API становится оправданным, когда миграции повторяются, когда отслеживание статусов между партиями должно быть программным или когда портфелем будут постоянно управлять после переезда.
