Кратко

  • Рост числа новых gTLD, портфели из сотен доменов и более частые обновления DNSSEC изменили нагрузку, которую должна была обслуживать RZMS.
  • Перестройка добавила пороги согласования по типу запроса, параллельную обработку, API и независимо развиваемые технические проверки; ответственность за правила и непрерывность учетных записей осталась у менеджеров TLD.

Анализ

Рост числа запросов изменил характер работы

Прежняя RZMS не была неработоспособной. Она уже автоматизировала этапы обработки, повышала точность и сокращала сроки, а также предоставляла менеджерам TLD портал самообслуживания для типовых задач. Давление возникло из-за другой нагрузки: программа новых gTLD увеличила число делегирований, некоторые организации стали управлять портфелями из сотен доменов, а обновления ключей подписи DNSSEC участились.

В мае 2022 года Davies сообщил, что инженерно-техническая команда ICANN решила перестроить платформу на модульной основе. Небольшая межфункциональная группа работала над проектом несколько лет. Его рассказ объясняет причины и эксплуатационные решения, но не утверждает, что он единолично разработал систему. Задача состояла в том, чтобы принимать новые модели запросов, не привязывая каждое изменение к одному жесткому процессу.

Масштаб работы потребовал другого устройства

Предыдущая версия RZMS уже автоматизировала часть обработки, повышала точность, сокращала время выполнения и давала менеджерам портал самообслуживания. Затем расширилась зона DNS: выросло число новых gTLD, некоторым организациям понадобились инструменты для управления сотнями доменов, а обновления ключей DNSSEC стали происходить чаще. По словам Davies, команда инженерии и информационных технологий ICANN решила перестроить систему на модульной основе; ее создавала небольшая межфункциональная группа. Этот рассказ о коллективной работе не дает оснований считать Davies единственным разработчиком.

В журнале версий IANA указано, что первоначальная новая модель поддерживала более двух утверждающих, разные пороги по типам запросов, API и несколько одновременных заявок. Техническая проверка инфраструктуры была вынесена в отдельную систему, чтобы ее можно было развивать независимо от управления запросами.

Важно и то, чего система не делает. IANA описывает свою роль как назначение менеджеров доменов, регистрацию технических данных делегирования и публикацию связанного реестра. Обзор IANA различает Root Zone Database, где указаны менеджеры, технические сведения и контакты, и отдельный DNS-файл корневой зоны. Одобрение в RZMS продвигает заявку в процессе, но не заменяет проверку и внедрение изменения и не превращает утверждающего в владельца домена.

Усиление входа и восстановление доступа

Многофакторная аутентификация (MFA) не стала обязательной частью запуска 2022 года. Davies ссылался на необходимость обеспечить работу в разных странах и на пользователей, которые могут не входить в систему несколько лет. Чем реже используется учетная запись, тем важнее проверить, сможет ли уполномоченный человек восстановить доступ, когда потеряет устройство или коды.

В исследовании процесса обновления корневой зоны 2022 года мнения участников разделились: 82% опрошенных считали существующие меры достаточными, 18% указали на возможные слабые места; некоторые предложили MFA. Эти результаты описывают респондентов той работы, а не всех менеджеров TLD и не нынешнюю оценку риска. Исследование также обсуждало действовавший тогда принцип, при котором запрос могли подать не только заранее назначенные контакты. Davies упоминал этот контекст, объясняя отсрочку общего требования MFA.

В январе 2025 года он объявил MFA и проверку личности опциональными функциями. Согласно текущей инструкции IANA, пересмотренной в июле 2026 года, подтверждение личности необходимо для включения MFA и использования API, но не обязательно для остальных операций RZMS. API разрешает только действия, доступные конкретной учетной записи; тестовая среда OTE не меняет производственную систему, говорится в руководстве API.

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

Масштабирование переносит ответственность на менеджеров

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

API расширяет процессы программными операциями, но не обходит права пользователя. Среда Operational Test and Evaluation IANA позволяет проверить интеграции до выхода в производство. Технические проверки также отделены от авторизации: соответствие техническим требованиям само по себе не одобряет запрос, а одобрение не заменяет проверку или внедрение.

RZMS — только часть управления корневой зоной. IANA назначает менеджеров TLD, фиксирует технические данные делегирования и публикует Root Zone Database, отдельную от файла DNS корневой зоны. В журнале изменений за июнь 2026 года указана версия 3.6.1. Долгосрочный результат перестройки — адаптируемый рабочий процесс, но не гарантия правильной настройки в каждой организации. Эффективность зависит от того, успевают ли локальные правила, восстановление учетных записей и технические испытания за реальной нагрузкой.

Источники