Процесс передачи домена с технической точки зрения: Полная инструкция

Я описываю Процесс передачи домена технически, шаг за шагом, от разблокировки до окончательного подтверждения в реестре. Именно так вы планируете код авторизации, процессы EPP и Обновление DNS Чистота, чтобы веб-сайт и электронная почта оставались доступными.

Центральные пункты

• Разблокировать и проверьте данные владельца
• Код авторизации Запрос в срок
• EPP-Начать передачу с новым регистратором
• Обновление DNS Подготовьтесь заранее
• Правила ДВУ и соблюдать сроки

Подготовка: разблокировка домена и проверка данных

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

Стратегия DNS перед началом работы

Перед продуктивными переездами я планирую Обновление DNS активным, чтобы избежать сбоев. Я настроил идентичную зону DNS с новым провайдером и проверил записи A, AAAA, MX и CNAME. Если вы используете внешние серверы имен, вы можете сохранить их на время изменений и тем самым значительно снизить риск. Я проверяю значения времени жизни (TTL) и целенаправленно снижаю их, чтобы изменения быстрее доходили до всего мира. Это руководство помогает мне избежать ошибок более подробно: Избегайте ошибок при передаче, которую я прохожу один раз перед стартом.

Безопасный запрос кода аутентификации (EPP)

Без Код авторизации Ни одна передача не выполняется. Я запрашиваю код у предыдущего регистратора в своем аккаунте или спрашиваю его у службы поддержки. Многие коды действуют около 30 дней, поэтому я использую их оперативно. Для .de я могу инициировать альтернативный код (AuthInfo2) через ответственного оператора в случае возникновения проблем. Я храню код в зашифрованном виде и никогда не передаю его по незащищенным каналам связи. E-mail.

Начните передачу у нового регистратора

Я инициирую фактическое изменение с новым провайдером, ввожу домен и набираю Код авторизации правильно. В фоновом режиме системы обмениваются данными через EPP, основанный на XML протокол для реестров. Новый регистратор отправляет запрос, реестр проверяет его и сообщает старому провайдеру. В случае с gTLDs часто существует короткий период возражений, после чего реестр передает домен. Если вы хотите ознакомиться с полным описанием процесса в сжатом виде, посмотрите это руководство: Смените регистратора: Инструкции, который я люблю использовать в качестве краткого справочника.

Технический процесс в реестре

Чтобы помочь вам понять этот путь, я кратко изложу технические этапы в понятных терминах и изложу Координационные центры на EPP и подтверждения. Сначала новый регистратор отправляет запрос на передачу с доменом и кодом доступа в реестр. Затем выполняется проверка статуса: Владение, блокировка, сроки и любые возражения. Старый регистратор может согласиться или промолчать; отсутствие ответа после установленного срока обычно означает одобрение. После одобрения реестр присваивает домен новому регистратору и обновляет контакты, серверы имен и Статус.

Целенаправленно используйте коды состояния EPP

Я прочитала следующее для вешалок Коды состояния EPP Последовательно, потому что они четко указывают, где существует проблема и какие действия необходимо предпринять:

• хорошоВсе готово, блокировки не активны. Передача может начаться.
• clientTransferProhibitedБлокировка регистратора активна. Я отменяю блокировку учетной записи.
• serverTransferProhibitedБлок реестра или политики (например, процедура/UDRP). Я уточню причину в службе поддержки.
• pendingTransferПеревод находится в процессе. Я буду ждать окончания срока или проверять электронные письма с подтверждением.
• redemptionPeriod / pendingDeleteДомен в цикле удаления. Передачи заблокированы; сначала возможно восстановление, затем передача.
• clientUpdateProhibitedОбновления заблокированы. Перед внесением изменений я снимаю дополнительные блокировки (блокировка реестра).

Я знаю, что gTLDs, в дополнение к Код авторизации все больше от термина TAC (Transfer Authorisation Code) - принцип остается прежним: ограниченный по времени, чувствительный токен, который легитимизирует передачу.

Замки, правила 60 дней и допустимые отказы

Я планирую временной буфер для политики, которую часто упускают из виду. После регистрации или успешной передачи многие регистраторы устанавливают 60-дневная блокировка, в течение которого дальнейшие передачи обычно отклоняются. Смена регистранта также может вызвать период блокировки для рДВУ, если заранее не был установлен отказ от блокировки. Допустимые причины NACK от старого регистратора включают: активные блокировки, отсутствие оплаты, конфликты идентификационных данных или судебные разбирательства. Если ни одна из этих причин не применима, перенос не должен задерживаться без причины. Поэтому я заранее проверяю: Оплачено? Не заблокирован? Контакты верны? Тогда я избегаю ненужных циклов.

Обновление DNS без сбоев

Я поддерживаю доступность сайта, зеркалируя зону DNS контролируемым образом перед его запуском и TTL ниже. Во время глобального распространения могут возникать кратковременные различия в разрешении. Я тестирую цель из нескольких сетей и проверяю записи A и MX с помощью таких инструментов, как dig или nslookup. При необходимости я временно настраиваю обе инфраструктуры параллельно, пока все кэши не будут преобразованы. Если вы также хотите узнать подробности о временных окнах, воспользуйтесь моей заметкой ниже о Продолжительность.

Чистый перенос DNSSEC

С DNSSEC Я учитываю запись DS в реестре. Если сервер имен и, соответственно, ключ меняются, у меня есть две безопасные стратегии:

• Конверсия с пробелом: Я удаляю DS из реестра незадолго до переключения, жду глобального обновления (помогает низкий TTL), переключаюсь на новые серверы имен и затем устанавливаю новый DS. Это позволяет избежать SERVFAIL из-за неправильных подписей.
• Бесшовное переворачивание: Я храню новый DNSKEY параллельно (KSK rollover), подписываю его, а затем обновляю DS. Только после этого я удаляю старый ключ. Это снижает риски валидации при использовании строго валидирующих резолверов.

Поддержка реестра и поставщика услуг CDS/CDNSKEY, обновление DS может быть частично автоматизировано. Без автоматизации я управляю последовательностью вручную и регистрирую время, чтобы в случае неполадок можно было быстро проверить.

Серверы имен детей и записи о клеях

Если домен использует собственные серверы имен (например. ns1.mydomain.tld), существует Предметы-хозяева/клеевые пластинки в реестре. Здесь я планирую отдельно:

• Перед переносом я добавляю дополнительные IP-адреса из новой инфраструктуры в объекты хоста (двойной стек, двойной провайдер), чтобы разрешение надежно работало на этапе перехода.
• После переноса я снова удаляю старые IP, как только все кэши безопасно указывают на новый путь.
• Я проверяю, поддерживает ли новый регистратор непосредственно администрирование хост-объектов; если нет, я тесно координирую изменения с обеими службами поддержки.

Это предотвращает неожиданное исчезновение доменов на моих дочерних серверах имен в результате переноса.

Особенности ДВУ и сроки

Сроки и согласования меняются в зависимости от завершения, поэтому я внимательно смотрю на TLD. Для таких рДВУ, как .com или .net, обычно используется период возражений в течение нескольких дней, прежде чем изменения вступят в силу. Домены .de меняются практически в режиме реального времени, как только становится доступен действительный код. Расширения с кодом страны (ccTLD) ведут себя по-разному и следуют своим собственным правилам. Приведенный ниже обзор классифицирует наиболее важные моменты и поможет в Планирование.

TLD	Процесс передачи	Специальные характеристики	Код/подтверждение	Поведение сервера имен
.com / .net / .org	Запрос через EPP, короткая фаза возражений	Старая страница остается доступной при правильном DNS-Подготовка	Код авторизации обязателен, владелец получает почту	Настройте новую зону заранее или сохраните внешние серверы имен
.de	Передача данных в режиме реального времени после ввода кода	Возможен дополнительный альтернативный код (AuthInfo2)	Обязательный код авторизации, подтверждение часто происходит непосредственно в процессе	Старая зона может быть отменена, поэтому подготовьте зону с новым провайдером
ccTLDs (различные)	Очень разные, зависящие от реестра	Частично дополнительные доказательства или сроки	Иногда код, иногда другие релизы	Заранее проверьте, остаются ли внешние серверы имен

Расчеты, сроки и фазы истечения

Я теряю Логика расширения не исчезает из поля зрения: Для многих рДВУ успешный перенос продлевает срок действия на один год (до максимального предела). Некоторые ccTLD, включая .de, не имеют такого автоматического продления при переносе. Если срок действия домена истекает, я могу избежать неприятных сюрпризов:

• Я не начинаю трансфер в последнюю минуту. Если домен попадает в Грейс- или Этап выкупа, Переводы часто блокируются или возможны только после восстановления.
• Автоматическое продление регистрации у старого регистратора может привести к появлению промежуточных счетов; после успешного переноса они часто отменяются для gTLD. Я четко фиксирую даты.
• После изменений я активировал следующие параметры у нового регистратора Автообновление снова, чтобы не было пробелов.

Планирование и расписание TTL

Для критически важных проектов я выделяю небольшой План выполнения точно:

• От Т-7 до Т-3 дней: Зеркальная зона, настройка мониторинга (HTTP, MX, DNS). Сократите TTL соответствующих записей до 300-600 секунд.
• Т-2 дня: Проверьте Auth-код, снимите блокировку, проверьте контакты.
• День Т-1: Выполните последнюю синхронизацию зон, реализуйте план DNSSEC (удаление DS или перенос).
• T (в непиковое время): Инициируйте передачу, отслеживайте журналы и статус на обоих порталах.
• От T до T+1: После успешного поглощения повторите тесты, завершите работу над DS/записями, демонтируйте старую инфраструктуру в упорядоченном порядке.
• T+2: Постепенно увеличивайте TTL, дорабатывайте документацию.

Избегайте распространенных камней преткновения

Я избегаю устаревших данных WHOIS, потому что перенаправленные письма неоправданно дорого обходятся. Время. Активная блокировка передачи блокирует каждый запуск, поэтому я сначала проверяю ее. Слишком высокие значения TTL приводят к долгому распространению, поэтому я уменьшаю их заранее. Разные уровни зон у старого и нового провайдера приводят к непостоянному разрешению. Поэтому я тщательно проверяю записи перед запуском и документирую каждую из них. Поправка.

Планируйте переезд почты и хостинга отдельно

Перенос затрагивает только реестр, а не файлы или почтовые ящики, и я всегда помню об этом. очистить. Я переношу веб-контент с помощью SFTP или восстановления резервных копий и тестирую его перед запуском. Я переношу почтовые ящики с помощью синхронизации IMAP или экспорта/импорта, чтобы ни одно сообщение не пропало. Я переношу SPF, DKIM и DMARC в новую зону. Только когда все готово, я снова увеличиваю TTL и создаю резервную копию Стабильность.

Доставка почты и параллельная работа

В частности, я думаю о E-mail-Потоки. Во время переключения входящие письма могут иногда попадать на старый MX, а иногда на новый MX, в зависимости от резолвера. Вот как я реагирую на это:

• При больших объемах я планирую короткую фазу заморозки для изменения структуры почтовых ящиков, чтобы не потерять смены.
• При необходимости я использую Двойная доставка (временно две цели MX) или центральное реле, обслуживающее оба конца - хорошо дозированное и контролируемое.
• После передачи я снова проверяю SPF, DKIM и DMARC и проверяю оценку получателей с помощью отчетов DMARC.

Проверка безопасности после изменения

После успешной миграции я активирую Запрет на трансфер снова. Я настраиваю двухфакторную аутентификацию в учетной записи клиента и защищаю историю кодов аутентификации. Я снова проверяю данные WHOIS, чтобы обеспечить видимость и защиту данных. Я немедленно исправляю ошибки в DNSSEC, SPF или DKIM, поскольку в этом случае сильно страдают электронные письма. Наконец, я документирую все шаги и сохраняю Резервные копии готово.

Переработка: Мониторинг, автообновление, аудит

Я проверяю Автообновление-настройки и, если есть возможность, установить уведомления до истечения срока действия. Я провожу активный мониторинг веб-сайта, конечных точек API, MX, проверок SPF/DKIM и DNSSEC в течение 24-48 часов, чтобы выявить крайние случаи в кэшах. Для аудита я архивирую скриншоты, файлы экспорта, статусы зон и события EPP (например. pendingTransfer → хорошо), чтобы последующие запросы были четко задокументированы.

Конфиденциальность, RDAP и каналы связи

С активной Конфиденциальность/прокси Я слежу за тем, чтобы письма с подтверждением доходили до меня (пересылка работает, тикет-система не отфильтровывает). Некоторые регистраторы теперь используют каналы связи на основе RDAP вместо WHOIS. Я поддерживаю постоянство зарегистрированных электронных адресов и избегаю спонтанных изменений контактов незадолго до передачи, чтобы не сработал блок подтверждения.

Интернационализированные домены (IDN)

На сайте IDNs Я проверяю орфографию и Punycode постоянно во всех системах. Я проверяю сертификаты (записи SAN), перенаправления и приложения, которые могут принимать только метки ASCII. Перенос ничего не меняет, но ошибки обычно появляются во время параллельной реорганизации DNS.

Перемещение и организация штабелей

Если я передаю несколько доменов, я объединяю их в Перенос штабелей с идентичными процедурами: стандартизированная стратегия TTL, центральная таблица для кодов авторизации и сроков, четкие пути эскалации. Я выделяю приоритетные критические зоны (например, провайдер SSO, MX) и обеспечиваю усиленный мониторинг. Это позволяет мне поддерживать обзор и сократить количество изменений контекста в команде.

Устранение неполадок: когда передача зависнет

Если процесс заходит в тупик, я разрабатываю четкий Список от. Я проверяю блокировку, валидность кода, почту владельца и записи на сервере имен. Затем я запрашиваю журналы состояния у нового регистратора и прошу старого провайдера отправить обратную связь в реестр. В случае с .de я запрашиваю новый код и запускаю процесс заново. В случае сомнений я приостанавливаю продуктивные переключения до тех пор, пока DNS не станет согласованным и Бесперебойная работа бежит.

Краткое резюме

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