Кратко

  • В будущей полностью уполномоченной Governance Phase функция Security Incident Reporting сможет приостановить работу RSO в крайнем случае, когда несоблюдение требований создает значительную угрозу RSS. Полномочие возникает лишь после одиннадцати этапов, публичной оценки, консультации и формального голосования; изученные открытые документы не показывают, что оно действует сейчас.
  • Окончательное удаление относится к DNR: расследование, достаточные возможности исправить нарушение, рекомендация Council и организованное удаление из трех DNS-источников, описанных в RSSAC030. Модель не определяет, затрагивает ли приостановка SIR эти источники, сколько она длится, приостанавливает ли апелляция исполнение и кто разрешает возвращение.
  • До Milestone 12 Council следует утвердить версионируемую запись непрерывности от приостановки до восстановления. Открытая часть показывает полномочие, масштаб, срок, исправление, апелляцию и итог, а сведения, способные помочь атакующему, остаются в защищенном приложении.

Самая сильная мера описана только в одном направлении

RSS Governance Working Group создавал итоговую модель почти четыре года. Это не декларация из нескольких принципов, а конструкция из Council, Secretariat, групп заинтересованных сторон, пяти функций, трех фаз и тринадцати контрольных точек.

В Security Incident Reporting эта конструкция получает исполнительное содержание. SIR должна определить, какие происшествия подлежат сообщению, стандартизировать отчеты, анализировать причины, развивать меры защиты, контролировать соблюдение и информировать заинтересованные стороны. В Governance Phase она сможет начинать расследование, запрашивать данные и содействие, требовать улучшений безопасности, применять корректирующие меры и разрешать экстренные действия. В крайнем случае, если несоблюдение создает значительную угрозу Root Server System, SIR сможет приостановить работу оператора.

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

Недостаток находится после решения. Модель не объясняет объект приостановки. Речь может идти о статусе внутри новой структуры, об отдельной обязанности, о части инфраструктуры, о наборе экземпляров или о самом сервисе, связанном с конкретным корневым идентификатором. Возможны и последствия для источников, по которым обычная DNS-система находит корневые серверы.

В 86-страничном документе также нет отдельного состояния восстановления. Есть расследование, исправление, апелляция и другой путь к окончательному удалению. Нет обязательного перехода, который связывает устранение технической угрозы с решением вернуть прежний статус.

Это не оценка действующих операторов и не утверждение о сегодняшних полномочиях ICANN, RSSAC или IANA. Это незавершенный интерфейс предлагаемой системы.

Будущее полномочие нельзя писать в настоящем времени

Трехфазный план имеет юридическое и операционное значение.

В Initiation Phase должны появиться Council и Secretariat с намеренно ограниченным мандатом. Establishment Phase формирует SAP, FRM, PME, SIR и DNR, пишет их уставы, устанавливает правила безопасности и оценки, обеспечивает финансирование, процедуры назначения, удаления, надлежащего разбирательства и апелляции.

Переход в Governance Phase требует работающих функций и утвержденных основных политик. Выполнение Milestones 1–11 должно быть отражено в полном публичном отчете. До голосования проводится консультация, с участвующими сообществами обсуждается консенсус, а Council формально подтверждает готовность. Только Milestone 12 включает полные полномочия.

Открытая хронология пока показывает передачу предложения. GWG согласовал итоговый текст 18 февраля 2026 года и направил его ICANN community, Board, IETF/IAB, RSSAC и RSO 20 февраля. Председатель Board поблагодарила группу и упомянула дальнейший путь. Письмо не сообщает об утверждении или вводе в действие. Операционный план ICANN ожидал будущего принятия и связывал последующую реализацию с отдельным решением и определением приоритетов.

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

SIR ограничивает угрозу, DNR решает вопрос статуса

Разделение SIR и Designation and Removal — полезная защита от чрезмерно быстрого окончательного решения.

SIR начинает с события безопасности. Существенное влияние на доступность, целостность или конфиденциальность может потребовать реакции, пока факты еще собираются. Ее время измеряется минутами и часами.

DNR начинает с показателей оператора, несоблюдения и долгосрочной пригодности. Функция расследует, назначает исправление в установленные сроки и рекомендует удаление лишь после того, как оператор получил достаточные возможности устранить проблему. Окончательное одобрение дает Council. Затем DNR координирует организованное прекращение и удаление из источников DNS, взаимодействуя с IANA.

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

Между функциями нужен акт передачи. Дело SIR может завершиться исправлением, успешной апелляцией, сужением меры или открытием процесса DNR. Итоговая модель не называет документ передачи, владельца промежуточного состояния и решение, закрывающее приостановку.

«Исправление завершено» — состояние доказательства. «Статус восстановлен» — состояние полномочия. Если одно автоматически подразумевает другое, проверка исчезает. Если они вообще не связаны, исправленная система может остаться приостановленной по инерции.

RSSAC030 разделяет три уровня последствий

RSSAC030 перечисляет три основных источника, которые ведет IANA Functions Operator: файл root hints, корневую зону и зону root-servers.net. Они связывают имена корневого сервиса с IPv4- и IPv6-адресами под контролем RSO. Наличие сведений об организации в этих источниках идентифицирует ее как оператора и делает сервис доступным через общую систему обнаружения.

Functional Model прямо ссылается на RSSAC030 в разделе DNR. При окончательном удалении DNR координирует прекращение работы и исключение RSO из источников. В описании приостановки SIR такой связи нет.

Из этого следуют три независимых уровня.

Первый — статус управления: уполномоченная функция объявляет RSO приостановленным. Второй — операционное состояние: во время устранения угрозы ограничиваются определенные системы, экземпляры или обязанности. Третий — состояние источников: IANA меняет файл или зоны.

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

Иначе временная мера может дать фактический результат удаления раньше процедуры DNR и решения Council. Источники не доказывают, что так произойдет; задача правил — исключить такую возможность по неясности.

Апелляция не определяет текущую работу

Модель позволяет оспаривать решения SIR в Council. Для DNR существует прямой путь апелляции, а рекомендации об удалении требуют окончательного одобрения. Предусмотрены взаимная проверка, внешние обзоры и отчетность.

Эти механизмы контролируют решение, но не задают промежуточное техническое состояние.

Останавливает ли подача апелляции исполнение? Может ли Council применить временную меру? Разрешено ли продолжать незатронутую часть сервиса? Если апелляция удовлетворена, все прежние права возвращаются автоматически или после угрозы нужен тест готовности? Кто подтверждает, что корректирующее действие действительно устранило значительный риск?

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

Без этого Council может рассматривать апелляцию, пока SIR, RSO, IANA и RZM исходят из разных представлений о фактически действующей мере.

Публичный статус не требует публичной уязвимости

RSSAC062 дает полезное правило раскрытия. Документ относится к событиям с существенным воздействием на RSS и говорит, что отчетность не должна мешать реагированию: устранение происшествия имеет приоритет.

Подробности могут маркироваться по Traffic Light Protocol. Информацию, которая поможет будущей атаке, следует исключить. Каналы передачи должны быть аутентифицированными и конфиденциальными. Одновременно рекомендуется своевременная публичная версия TLP:Clear.

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

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

Сильная защита модели требует завершенного теста

Разумно утверждать, что Functional Model не обязан быть руководством для каждого происшествия. Establishment Phase и должна превратить высокоуровневые функции в уставы и практику с участием специалистов по эксплуатации, конфиденциальности, автономии RSO и координации с IANA.

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

Резервирование и разнообразие RSS также могут сделать временную изоляцию одного опасного элемента пропорциональной защитой коллективного сервиса. Полный запрет на такой инструмент не обязательно безопаснее.

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

Running-Code Primacy Heng Lu предлагает подход к масштабу: институциональное утверждение должно соответствовать минимальному проверяемому эффекту, необходимому работающим системам. Слово «приостановлен» не является надежным состоянием, если независимые участники реализуют его по-разному.

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

Версионируемая запись от приостановки до возврата

До Milestone 12 Council следует потребовать общую запись для каждого решения SIR. Она открывается с минимальными публичными данными одновременно с мерой и дополняется после стабилизации. Заполнение не должно задерживать реагирование.

Публичная часть включает:

  • стабильные идентификаторы дела и RSO;
  • принимающую функцию, основание, версию правила и ответственную роль;
  • несекретную категорию триггера и признак чрезвычайной процедуры;
  • точное воздействие на статус, услугу, инфраструктуру и корневые источники;
  • время начала, начальный максимальный срок и обязательный пересмотр;
  • меры сохранения коллективной непрерывности RSS;
  • корректирующие действия и публичный статус выполнения;
  • хранение и классификацию защищенных доказательств;
  • апелляцию, просьбу о приостановлении исполнения и решение по ней;
  • орган, критерии и технический тест возврата;
  • независимую или взаимную проверку;
  • каждое продление с новым решением и причиной;
  • итог: восстановлен, сужен, заменен или передан в DNR;
  • отдельное действие IANA, RZM или изменение источников и состояние его отмены.

Термины нельзя использовать как синонимы. Апелляция подана не означает исполнение остановлено. Исправление закончено не означает возврат разрешен. Передано в DNR не означает удаление одобрено. Удаление одобрено не означает источники изменены.

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

Запись не дает RSO права вето, не раскрывает атаку и не передает реагирование публике. Она лишь придает временной власти владельца, масштаб, срок и конечное состояние.

Пределы доказательств

Изученные источники не доказывают формального принятия модели Board, наступления Governance Phase или приостановки какого-либо RSO по ее правилам. Они не дают оснований считать действующего оператора небезопасным или нарушающим требования.

Отсутствие термина о восстановлении не означает, что будущие уставы не могут создать процедуру. Оно означает, что создание процедуры должно предшествовать полномочию. Поскольку технический объект «приостановки работы» не определен, статья не утверждает обязательного изменения root hints, корневой зоны или root-servers.net.

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

Источники

  1. ICANN — The Root Server System Governance Structure, 18 февраля 2026 года
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — передача итогового отчета GWG
  4. Tripti Sinha — ответ председателя ICANN Board
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN — проект операционного и финансового плана FY2027–2031
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile