Кратко

  • draft-skoglund-epp-registry-lock-00 предлагает отложенный процесс EPP: один или несколько контактов Registry Lock должны до истечения срока разрешить изменение защищённого домена.
  • Политика может задавать число необходимых согласий, а итоговое poll-сообщение — перечислять идентификаторы одобривших контактов. Однако проект не стандартизирует проверку личности, привязку контрольного запроса и независимость людей, каналов и способов восстановления.
  • Операторам нужен отдельный журнал церемонии одобрения, связывающий состояние до и после запроса, исходную политику и набор контактов, домены контроля, запросы, ответы, исключения, время и окончательный результат. Это предложение по управлению, а не требование IETF.

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

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

Версия 00 проекта, draft-skoglund-epp-registry-lock-00, опубликована 30 июня 2026 года. В отрисованном заголовке указано Standards Track, тогда как Datatracker называет документ индивидуальным Internet-Draft, не указывает поток, предполагаемый статус RFC и формальную позицию в процессе стандартизации IETF. Это обсуждаемое предложение, а не RFC и не сложившийся консенсус REGEXT.

Блокировка создаёт второй контур решения

Проект описывает Registry Lock как защиту на уровне реестра, а не только регистратора. Подобные услуги уже существуют, но работают по разным, часто ручным процедурам. Расширение должно позволить обслуживающему EPP-клиенту более автоматически устанавливать блокировку домена и управлять ею.

После блокировки домен обязан иметь статус serverDeleteProhibited. Пока команда преобразования ждёт разрешения, требуется serverPendingUpdate. Установка блокировки или обновление заблокированного домена возвращает код EPP 1001: команда принята, но ожидает дальнейшего действия. Своевременное разрешение приводит к poll-сообщению об успехе, а окончание срока без разрешения — к сообщению об отказе.

Тем самым меняется временной смысл команды. Отправка запроса больше не означает завершения перехода состояния. Она открывает эпизод авторизации. Позднее клиенту предстоит сопоставить событие очереди с прежней командой, а операторам — не принять «принято и ожидает» за «выполнено».

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

Множество записей не означает разделения власти

Политика может содержать необязательный срок и положительное ненулевое число одобрений; в редакции 00 поле написано как quorom. Сервер вправе ограничить допустимые значения. К домену можно привязать несколько lock-контактов, а число определяет, сколько из них должны согласиться.

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

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

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

Название канала не определяет уровень доверия

У каждого контакта Registry Lock есть идентификатор и может быть указан способ одобрения. Проект перечисляет известные строки: электронная почта, текстовое сообщение, письмо, телефон и токен; сервер может разрешить и другие.

Это названия средств доставки, а не уровней надёжности. «Электронная почта» не объясняет, использовались ли подписанная ссылка, простой ответ, вход на портал или разговор со службой поддержки. «Текстовое сообщение» не показывает, когда проверяли номер, защищён ли он от перевыпуска и связан ли с назначенным человеком. «Токен» может оказаться аппаратным аутентификатором или пересылаемым кодом. Звонок сам по себе не устанавливает личность собеседника, а бумажному письму всё равно нужны зафиксированные адресат и задание.

Расширение не стандартизирует содержание контрольного запроса, его привязку к изменению, защиту от повторного использования, регистрацию канала, установление личности или восстановление. Для раннего EPP-мэппинга такая свобода может быть оправдана: реестры уже используют разные сервисные модели, а единая всемирная церемония способна помешать внедрению.

Однако пробел ограничивает доказательную силу результата. ID в approvedBy означает, что реестр засчитал одобрение по собственной процедуре. Он не уравнивает разные процедуры и не позволяет регистратору сделать вывод об устойчивости к общей компрометации.

Заморозка контакта закрывает только один путь

Проект требует отклонять обновление объекта контакта, пока тот связан с защищённым доменом как lock-контакт. Удаление такого объекта тоже запрещается. Это закрывает очевидную атаку: сначала подменить почту или телефон, затем сразу подтвердить изменение через новый адрес.

В то же время обновление самой Registry Lock может добавлять и удалять контакты и менять параметры политики. Предполагается, что обновление заблокированного домена попадёт в отложенный процесс. Но возникает рекурсивный вопрос управления: какие нынешние полномочия вправе одобрить изменение будущего набора полномочий?

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

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

Исключения очерчивают настоящий периметр

Registry Lock не предписывает останавливать всякое действие. Проект разрешает продление домена. Реестр также может пропустить автоматическое обслуживание DNSSEC без обычной авторизации, например при сканировании CDSS или CSYNC. Снятие блокировки остаётся ручной операционной процедурой за пределами спецификации.

У таких границ есть основания. Запрет продления способен превратить защиту в риск истечения регистрации. Автоматическое обслуживание DNSSEC поддерживает непрерывность и снижает вероятность ошибки при смене ключей. Исключение снятия блокировки из ранней автоматизации может сохранить более строгую аварийную церемонию.

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

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

Действующие услуги показывают скрытое разнообразие

Реестр расширений EPP у IANA уже содержит Swedish Internet Foundation Registry Lock Extension как активную спецификацию не-RFC для .se и .nu. Запись подтверждает существование операторского расширения, но ничего не говорит о стандартизации нового индивидуального проекта.

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

Для .de DENIC описывает другую церемонию. Владелец назначает lock-контакт. Когда через провайдера поступает запрос, DENIC отправляет токен на сохранённый мобильный номер и письмо на зарегистрированный адрес. Без подтверждения в течение семи календарных дней запрос отклоняется. DENIC также отдельно проверяет запросы на создание, изменение и снятие блокировки и на изменение защищённых доменных данных.

Ни одно описание нельзя считать заявлением о реализации редакции 00. Их польза — в сравнении. За одним названием Registry Lock скрываются разные подходы к регистрации контакта, проверке, срокам, разблокировке и повторной блокировке. Общий синтаксис EPP не устранит этих различий. Он сделает их явное описание ещё важнее.

Сохранить журнал церемонии одобрения

Для каждой отложенной операции Registry Lock я предлагаю вести журнал церемонии одобрения. Это управленческая рекомендация Daniel Kade, а не схема, предписанная проектом.

Журнал начинается с запрошенного изменения: домен, обслуживающий клиент, аутентифицированная EPP-сессия, clTRID, svTRID, время, операция и каноническое представление состояния до и после. Он сохраняет исходную lock-политику, срок, число согласий, набор контактов и версию правил. Последующее обновление не может переписать эту точку отсчёта.

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

Контрольный запрос связывает nonce или digest с точным изменением, адресом доставки, моментами выдачи и окончания срока, временем ответа, итогом проверки и состоянием защиты от повтора. Отсутствие ответа, явный отказ и провал проверки различаются. Финальное решение называет проверенную норму независимости, засчитанные и исключённые согласия, исключение или ручное вмешательство и того, кто разрешил отступление.

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

Это не публичное досье на защищённые домены. Это долговечная запись с управляемым доступом, позволяющая владельцу, регистратору и реестру доказать больше, чем сумму контактных ID. Числовой кворум отвечает, сколько одобрений насчитал сервер. Журнал церемонии отвечает, представляли ли они независимые полномочия, обещанные механизмом защиты.

Источники