Немногим менее 10 лет назад Интернет-корпорация по присвоению имен и номеров (ICANN) помогла запустить систему управления корневой зоной (RZMS), набор взаимосвязанных элементов, позволивших модернизировать управление корневой зоны системы доменных имен (DNS). В частности, были усовершенствованы такие элементы как автоматизация многих фаз обработки запросов, что сократило время обработки запросов и улучшило их точность. Еще одно усовершенствование состояло в запуске портала самообслуживания, который позволяет менеджерам доменов верхнего уровня (TLD) выполнять простые задачи самостоятельно.
Истоки системы RZMS уходят корнями в начало 2000-х. Хотя система хорошо справляется со своими задачами, со временем наши потребности изменились и некоторые конструкторские элементы, лежащие в основе оригинальной системы, ограничивают возможности дальнейшего развития платформы. С появлением Программы New gTLD (доменов общего пользования) количество TLD в корневой зоне значительно возросло, что также изменило схему работы некоторых из наших пользователей. Некоторые организации теперь управляют сотнями TLD, и им необходимы новые инструменты для оптимизации работы над стоящими перед ними задачами. Мы также видим, что поступают новые типы запросов, не существовавших ранее, такие как частые обновления ключей подписания для TLD.
Специалисты отдела технического обеспечения и информационных технологий корпорации ICANN, разрабатывающие RZMS, приняли решение перестроить всю платформу с нуля и создать современную модульную систему, которую будет легче адаптировать к новым потребностям. Небольшая сквозная команда специалистов уже несколько лет занимается строительством этой системы, так что теперь мы близки к ее запуску.
В системе будет реализована вся уже существующая функциональность, но с применением современной архитектуры. Кроме того, мы внесли некоторые ключевые изменения в работу системы в этой первой версии, благодаря которым нашим пользователям будет легче работать. Ниже приведены самые важные из них:
- Новая контактная модель, позволяющая определить лиц, имеющих право взаимодействовать с Администрацией адресного пространства Интернет (IANA) отдельно от административных и технических контактных лиц, информация о которых публикуется для всего сообщества. Разделение этих функций позволило нам обеспечить гибкость для менеджеров TLD с точки зрения конфигурации их ролей и ответственности в зависимости от потребностей их организации. Менеджеры TLD также могут настроить количество разрешений, необходимых для каждого типа запроса о внесении изменения, и представителей, имеющих право утверждать разные типы запросов.
- В новой модели также обеспечены важные элементы безопасности, так как в ней для каждого создается собственный аккаунт. Для утверждения запросов пользователи будут обязаны заходить в свой личный кабинет. Раньше мы иногда разрешали выдавать разрешения просто перейдя по ссылке в письме.
- Аттестационное тестирование инфраструктуры TLD, процедура «технических проверок», вынесено в отдельную независимую систему. Отделение технических проверок от RZMS позволит нам расширять их (например, добавлять новые тесты для выявления проблемных конфигураций TLD), а также вводить элементы оптимизации качества работы, чтобы ускорить процедуру проведения тестов.
- Предварительная версия интерфейса программирования приложений, которая позволит менеджерам TLD создавать и использовать инструменты программного взаимодействия с нашей системой. Первые опции связаны с массовыми обновлениями, чтобы организации, управляющие множеством TLD, могли проводить операции сразу с множеством TLD эффективным образом.
Одно из решений, которые мы приняли для нашей новой контактной модели — создавать аккаунты для индивидуальных лиц. Это значит, что у каждого пользователя системой будет свой уникальный логин и пароль, а не один пароль для множества людей. Каждый менеджер также сможет создать столько аккаунтов, сколько необходимо для его представителей; открытые данные (например, записи WHOIS), как и в прошлом, будут привязаны к конкретной роли, а не к конкретному человеку.
Будущая функциональность
Хотя мы считаем, что эти опции позволяют усовершенствовать элементы, о которых просят наши пользователи, мы знаем, что предстоит еще много работы. Нам пришлось сделать выбор относительно того, на каких новых функциях следует сосредоточиться, чтобы завершить подготовку этой версии платформы и запустить ее, а какие ввести на более поздних этапах нашей дорожной карты разработок.
Один такой элемент особенно интересен — мультифакторная идентификация. Мы понимаем, что наши пользователи все чаще просят ввести эту опцию, но мы должны тщательно подготовиться к этому, чтобы ее ввод позволил укрепить безопасность корневой зоны. Мультифакторная аутентификация имеет множество разных элементов, и среди них — необходимость сделать так, чтобы эта технология работала во всех странах, включая пользователей, от которых мы можем не получать сообщения годами.
При принятии решения отложить ввод этой опции и исследовать его более тщательно мы опирались на результаты исследования процесса обновления корневой зоны. Его авторы (третья сторона) не рекомендуют добавлять мультифакторную аутентификацию в традиционном понимании в корневую зону и отмечают, что в некоторых уникальных формах защиты нашего процесса уже предоставляется уровень защиты, обеспечиваемый мультифакторной аутентификацией. Мы считаем, что мультифакторная аутентификация может пригодиться в будущем и надеемся, что дальнейшее обсуждение этого вопроса позволит сориентировать эту работу надлежащим образом.
Это исследование выявило ряд других направлений усовершенствования процесса обновления корневой зоны, и мы планируем изучить итоговый отчет более тщательно, чтобы использовать его результаты в нашей будущей работе. Например, авторы исследования получили много запросов об улучшении процедуры выполнения технических проверок, чтобы выявленные проблемы, которые можно назвать незначительными, не чересчур задерживали работу. Мы изучаем способы градации серьезности проблем и предоставления менеджерам TLD возможности снимать с рассмотрения потенциальные проблемы самостоятельно в случаях, если проблема с большой вероятностью будет иметь очень маленькие последствия, что должно помочь улучшить эту ситуацию.
Дальнейшие действия
В качестве подготовки к запуску этой новой системы IANA планирует обратиться непосредственно ко многим из наших пользователей, чтобы обсудить как она повлияет на их работу. Один из крупнейших элементов подготовки — определить способ перехода со старой контактной модели на новую, при этом не причинив никому неудобств.
Для TLD с большим количеством разных аккаунтов мы будем искать способы объединить их под единым логином и паролем для каждого. Это значит, что в ситуациях, когда у нас за одним человеком записано сразу несколько адресов электронной почты, надо определить которые адреса объединить.
Еще один усовершенствованный элемент новой контактной модели — оптимизация формата полей почтового адреса в нашей базе данных. Мы планируем обратиться к TLD с просьбой уточнить свои адреса.
Кроме этого обсуждения ввода новой версии с нашими пользователями, мы надеемся получить ваши отзывы о работе нашей системы, чтобы учитывать их в регулярных будущих релизах.
