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

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

Здесь рассматриваем подготовку обычной смены регистратора для собственного домена и проверку результата. Положения для .RU и .РФ приведены отдельно по официальным правилам. Для других зон порядок уточняют у обслуживающих организаций. Это не инструкция обхода проверки администратора и не обещание успешного переноса имени с любым статусом.

Назовите, что именно хотите изменить

У домена есть регистратор, а сведения об администраторе относятся к тому, на кого имя зарегистрировано. Сайт при этом может находиться на отдельном хостинге, DNS — обслуживаться другим провайдером, почта — работать в отдельной системе. В маленьком проекте всё бывает в одном кабинете, но общий интерфейс не делает эти услуги одним действием.

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

Полезно задать подрядчику прямой вопрос: какие параметры изменятся, а какие требуется сохранить? Ответ должен относиться к конкретному имени. Общая фраза «переносим всё» не помогает проверить последствия. Если исходная задача не требует нового сервера, его замену нужно обосновать отдельно, а не включать как скрытую обязательную часть переноса.

Проверьте возможность переноса до начала процедуры

Для доменов второго уровня .RU и .РФ раздел 7 правил Координационного центра, редакция от 21.04.2026, описывает передачу поддержки сведений между регистраторами. По пунктам 7.6–7.7 она осуществляется по заявке администратора новому регистратору и считается выполненной после внесения сведений о новом регистраторе в Реестр. Одно отправленное обращение ещё не подтверждает завершение.

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

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

Составьте карту зависимостей домена

До изменения сохраните, кто обслуживает DNS, какие имена и поддомены используются и какие сервисы зависят от записей. Не ограничивайтесь главным адресом сайта. В проекте могут быть кабинеты сотрудников, формы, API и почтовые службы. Их наличие подтверждают владельцы систем и доступная конфигурация, а не предположения по красивому названию поддомена.

Отдельно выясните, предоставляется ли DNS как самостоятельная услуга или связан с прежним договором. Сохранённый список записей полезен, но не отвечает, продолжит ли их обслуживать прежняя организация после прекращения конкретной услуги. Такой вопрос нужно задать до отключения кабинета. Не считайте автоматическое копирование гарантированным, если оно не предусмотрено подтверждённым сценарием.

Ниже учебная карта, а не универсальный набор DNS-записей для вставки. Значения отсутствуют намеренно: реальные настройки берут из своего проекта. Смысл таблицы — определить ответственного и критерий проверки по каждой зависимости.

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

Разделите перенос и изменение DNS

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

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

Сведения до переноса сохраняют в доступном ответственным месте. В технический журнал не нужно копировать коды подтверждения, секреты интеграций или пароли. Для контроля результата достаточно фиксировать, какой параметр изменён, кто его подтвердил и где находится разрешённый источник исходной конфигурации. Состав доступа к этому источнику определяется отдельно.

Заявка и завершённый перенос отличаются

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

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

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

Проверьте сервисы после подтверждённого результата

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

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

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

Когда можно закрывать работу

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

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