Кратко

  • Группа при ICANN описывает ситуацию, когда DNS-имя перестаёт разрешаться, но такое же имя в альтернативной системе остаётся активным. Это зависит от правил той системы и решения регистранта сохранить имя.
  • Принцип «та же строка, тот же контролирующий субъект» должен выдерживать продление, передачу, приостановку и удаление. Для этого нужны полномочия на каждый переход, подтверждения от всех систем и порядок действий при незавершённой операции.

Окончание регистрации не завершает историю имени

Представим, что регистрант не продлевает регистрацию example.tld в DNS, но хочет оставить то же имя в альтернативной системе. Этот сценарий приведён в первоначальном отчёте Technical Study Group (TSG). Это не сообщение о реальном инциденте и не универсальное правило для всех систем имён. DNS-имя исключается из глобального разрешения. Альтернативное имя может остаться активным, если правила той системы это допускают и регистрант хочет его сохранить.

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

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

Техническое исследование не является разрешением

ICANN поручила TSG оценить, можно ли безопасно связать общий домен верхнего уровня (gTLD) в глобальном DNS с тем же именем в альтернативной системе и какие требования нужны для защиты безопасности и устойчивости DNS. Первоначальный отчёт от 10 августа 2026 года помечен как проект. Он не разрешает конкретную услугу и не предписывает единую архитектуру. В нём рассматриваются общая система регистрации (SRS) и распределённая модель с Unified Source of Truth (USoT).

На странице общественного обсуждения ICANN указано, что каждый оператор реестра должен отдельно пройти процесс Registry Services Evaluation Policy (RSEP). Отчёт TSG будет использоваться для будущих оценок и договорных положений; проект договорного языка вынесут на отдельное обсуждение. Приём комментариев завершился 21 сентября, а на странице указано 16 ноября 2026 года как срок подготовки отчёта.

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

Обе архитектуры требуют доказательств

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

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

В отчёте внутреннюю смену регистранта рассматривают как проверку видимости. Регистратор может поменять клиента только в собственных процессах, не уведомив реестр. Тогда сохранение единого контролирующего субъекта зависит от соблюдения договора, если нет постоянной связи идентификаторов или иного доказательства. Когда DNS-имя и альтернативное имя являются разными объектами с разными контролирующими субъектами, отчёт называет один общий приказ на передачу обоих объектов возможным решением.

Нужно различать и состояния блокировки. TSG указывает, что приостановка должна одновременно охватывать все связанные системы имён. При внешнем отключении из-за злоупотребления или судебного распоряжения имя тоже следует отключить во всех системах. Но clientHold, установленный регистратором для прекращения разрешения DNS, не должен автоматически выключать альтернативное имя. Если услуга отображает всё это как одну отметку «приостановлено», пользователь не понимает, какая норма действует.

Комментарии требуют понятного состояния

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

Министерство электроники и информационных технологий Индии просит до одобрения по RSEP сделать требования измеримыми и проверяемыми. В его предложениях перечислены состояния операций, пределы для незавершённых транзакций, защита при сбоях, испытанный план отключения, меры против преждевременного повторного выделения и независимые проверки безопасности. Это предложения министерства, а не уже принятые ICANN правила.

Вклад Intellectual Property Constituency подчёркивает, что вопросы защиты прав остаются предметом более широкой дискуссии. Согласованные записи не определяют, кому полагается имя, как устранять столкновение имён и куда обращаться пострадавшему пользователю.

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

Сохранять доказательство перехода

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

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

Политика RSEP и её примечания по реализации уже требуют описать услугу и её влияние на внешних пользователей. Следующий этап должен превратить общую техническую основу в условия, которые можно проверить до запуска и пересмотреть после изменения услуги. «Та же строка, тот же контролирующий субъект» — это состояние на снимке. Управление объясняет, как оно сохраняется при разных темпах работы систем и при сбоях.

Источники