Кратко

  • С 10 августа по 21 сентября 2026 года ICANN принимает замечания к первому отчёту Technical Study Group об интеграции gTLD глобальной DNS с альтернативными системами имён.
  • Основное правило — «строка + контролёр»: имя и управляющий им субъект должны совпадать во всех системах, через общую регистрационную систему либо логически единый источник истины в распределённой архитектуре.
  • Отчёт не одобряет интеграцию. Каждому оператору по-прежнему потребуется отдельное разрешение через RSEP или процедуру раунда 2026 года, а проект договорных условий пройдёт новое обсуждение.
  • Существенный политический эффект оставлен за рамками технической работы: ранее существовавшие альтернативные имена могут потребовать резервирования соответствующих строк в DNS до любой активации там.

Проверка порога, а не запуск услуги

Объявление ICANN от 11 августа легко пересказать как решение соединить DNS с блокчейн-именами. Реальный предмет уже. С 2022 года действующие реестры и потенциальные участники нового раунда gTLD спрашивают, смогут ли они использовать одну строку в глобальной DNS и в другой системе имён. Группа создана, чтобы один раз разобрать общие технические вопросы, а не повторять дорогостоящую оценку для каждой заявки.

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

Общего разрешения пока нет. Документ на 39 страниц от 10 августа помечен как проект и называется первым отчётом. Он отвечает на предварительный вопрос Registry Services Evaluation Policy: способна ли эта ограниченная модель работать без неприемлемого риска для безопасности и стабильности, и какие технические условия обязательны?

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

Инвариант — контроль, а не блокчейн

Модель названа «string+controller integration». Одна строка должна во всех системах оставаться под управлением одной стороны; там, где имя не используется, оно резервируется исключительно для неё. Если любое условие нельзя гарантировать постоянно, пространство имён не подходит для этой модели.

Правило действует и ниже TLD. Выделение, передача, приостановка или отключение не должны создавать несовместимых контролёров для имени, которое пользователь воспринимает как одно. Для интернационализированных имён варианты и Label Generation Rules обрабатываются до интеграции: разные формы нормализации подорвут само утверждение о тождестве строки.

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

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

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

Первый конфликт прав уже виден

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

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

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

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

Принцип тонкой координации Lu Heng проясняет линию. Уникальность, доказательство контроля, проверяемое состояние и непрерывность могут находиться на общем слое. Коммерческий приоритет старых требований, допустимое использование и стоимость имени не становятся техническими полномочиями из-за интеграции. Узкий отказ создавать двойной контроль объясним. Для более широких последствий нужны названный принимающий решение, участие затронутых принципалов, причины и пересмотр.

Разрешение останется индивидуальным и договорным

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

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

Выход столь же важен, как вход. Отчёт рекомендует обязательный план отключения интеграции и отмечает, что эта услуга, по-видимому, не относится к критическим функциям Emergency Back-End Registry Operator. Если реестр перейдёт под EBERO, DNS может продолжить работу, а альтернативная часть — остановиться.

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

Четыре действия нельзя смешивать

Нынешнее обсуждение может проверить доказательства контроля, синхронизацию, распределённую финализацию, IDN, RDAP, передачи, приостановки, EBERO и отключение. Полезное замечание покажет конкретный путь отказа, а не только отношение к блокчейн-именам.

Договорный этап должен разделить четыре действия. TSG заключает, что архитектура может быть безопасной. ICANN разрешает или отклоняет отдельную услугу. Договор создаёт полномочия мониторинга и принуждения. Политическое правило решает судьбу вытесненных имён и владельцев требований. У каждого действия свой субъект, основание и порядок пересмотра.

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

Источники