Кратко

  • По RFC 5731 clientTransferProhibited и serverTransferProhibited означают сильное, но узкое ограничение: запросы на перенос доменного объекта должны отклоняться.
  • Префикс указывает сторону, управляющую статусом, но не содержит основания политики, человеческого разрешения, срока пересмотра или доказательства безопасности пути разблокировки.
  • Объяснимое решение связывает датированную запись статуса с отдельной записью решения; защита учётной записи, обновления, удаления, продления и DNS подтверждается независимо.

Запрет отвечает только за один глагол

Блокировка переноса — не декоративная отметка. RFC 5731 требует, чтобы сервер отклонял запрос переноса при наличии одного из двух запрещающих статусов. Наблюдатель получает важный факт о том, что конкретная команда не должна пройти в данный момент.

Ошибка возникает, когда факт превращают в готовую историю. Интерфейс может написать «защищено владельцем», «обнаружено мошенничество», «registry lock» или просто «безопасно». Эти выводы не записаны в токене. Протокол определяет результат команды, но не рассказывает, почему решение было принято.

RFC 5731 разрешает сопровождать статус понятным человеку описанием причины. Такое описание необязательно. Совместимый объект может не содержать номера дела, указания владельца, даты окончания или отметки о свежей проверке. Это не ослабляет запрет. Это означает, что объяснение хранится в другой системе.

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

Префикс называет сторону управления

Статусы с client устанавливает и снимает спонсирующий клиент — обычно регистратор. Статусы с server контролирует EPP-сервер — обычно реестр. Клиент не вправе менять серверный статус; сервер может изменить или перекрыть клиентский статус в соответствии со своей локальной политикой.

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

ICANN объясняет владельцам практическую разницу: client-коды задаёт регистратор, server-коды — реестр. Для снятия первого обращаются к регистратору. Для снятия второго регистратору, возможно, придётся взаимодействовать с реестром, и процесс займёт больше времени. Это маршрут обращения, а не доказательство причины конкретного случая.

Причина живёт в политике

В своей области действия политика переноса ICANN описывает тот слой, который RFC 5731 намеренно не кодирует. Она разделяет полномочие зарегистрированного владельца, отправку команды принимающим регистратором, обязанности текущего регистратора и случаи, когда отказ разрешён и его основание должно быть сообщено.

Основания неоднородны. Доказательство мошенничества не равно обоснованному спору о личности владельца. Определённая задолженность не равна прямому возражению владельца. Судебное решение, процедура спора, сроки после новой регистрации или недавнего переноса и 60-дневная блокировка после смены владельца имеют разные источники полномочий и разные часы.

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

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

Три времени не помещаются в одну иконку

Часы сервера отмечают появление запрета в авторитетном состоянии EPP. Часы политики отмечают начало основания и момент проверки или окончания. Часы наблюдателя фиксируют только то, когда RDAP, Whois, портал регистратора или внешний монитор получил и показал снимок.

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

RFC 5731 даёт полезную проверку согласованности: pendingTransfer нельзя сочетать ни с одним запретом переноса. Первый статус означает, что действие принято в обработку, но не завершено; второй требует отклонить запрос. Если в данных видны оба, сначала проверяют разницу времени, возраст кэша, объединение разных источников и ошибку отображения. Противоречие требует реконструкции, но ещё не доказывает мошенничество или нарушение со стороны реестра.

Слово «заблокирован» не охватывает всё

В обычной речи блокировка кажется полной остановкой. В EPP существуют отдельные запреты для переноса, обновления, удаления и продления, а статусы hold влияют на публикацию DNS-делегации. Запрещённый перенос не доказывает невозможность изменить контакты, удалить домен или воспользоваться скомпрометированной учётной записью регистратора.

Захватив аккаунт, атакующий может попытаться снять client-статус. И наоборот, коммерческая услуга registry lock может добавлять проверку по отдельному каналу, два подтверждения, независимый секрет или обязательную задержку. Это реальные меры, когда их подтверждают договор и работа сервиса. Похожее название EPP-статуса их не гарантирует.

Рекомендации ICANN также называют transfer lock полезным дополнительным слоем, но не безотказной защитой. Безопасность данных аккаунта и многоэтапная аутентификация рассматриваются отдельно. Значит, аудит должен разнести доступ, изменения прав, authInfo, запреты обновления и удаления, DNS, продление и восстановление по отдельным доказательствам.

Имя Hollenbeck тоже имеет границу

Scott Hollenbeck указан автором RFC 5730 и RFC 5731. В публичном профиле IETF говорится, что он активно участвует с середины 1990-х, руководил несколькими рабочими группами и был Applications Area Director в 2004–2006 годах. Текущий снимок перечисляет 39 RFC.

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

Досье, которое можно проверить

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

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

Сильнейшее возражение справедливо: запрет действительно защищает. В совместимом состоянии он останавливает запрос. Блокировка по умолчанию и хорошо организованный registry lock повышают стоимость угона домена. Ошибка не в доверии протоколу, а в требовании, чтобы он подтвердил решение за пределами своего поля.

Сопоставление Hollenbeck даёт строгую короткую фразу: отклонить эту команду. Организация должна продолжить её: кто решил, на каком основании, на какой срок и через какой выход. Блокировка останавливает перенос; объясняет её только доказательство с установленным источником.

Источники