Часто задаваемые вопросы о Плане действий по устранению причин совпадений имен в новых доменах общего пользования

Миссия и основные ценности ICANN – поддержание и усовершенствование операционной стабильности, надежности, безопасности и глобальной интероперабельности системы уникальных идентификаторов интернета (имен, IP-номеров и параметров протокола). Для выполнения этих целей и указания Правления ICANN, а также рекомендаций Консультативного комитета по безопасности и стабильности, ICANN заказала исследование потенциальных последствий для безопасности в результате эксплуатации строк новых доменов общего пользования, на которые были поданы заявления. Исследование было призвано изучить вероятность возникновения совпадения имен между строками, на которые были поданы заявления, и доменными именами, использующимися во внутренних пространствах имен ("неделегированных доменах верхнего уровня"). Исследованием также должна была быть изучена вероятность совпадения имен при использовании внутренних имен, на которые были выданы цифровые сертификаты X.509.

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

5 августа 2013 года ICANN опубликовала и предоставила результаты исследования совпадения имен <http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf> [PDF, 3.34 МБ] (здесь и далее "Исследование") с распределением строк по категориям, определенным по направлению запросов. В выборку были включены данные журнала регистраций событий корневого сервера инициативы "День в жизни интернета" Центра операций, анализа и исследований DNS (DNS-OARC). В качестве исходных данных исследованием использовались: 1) выборки запросов к системе DNS, направленных корневым серверам (инициативы "День в жизни интернета"), что было дополнено 2) информацией центров по выдаче сертификатов в отношении выдачи внутренних сертификатов имен (например сертификатов TLS/SSL для неделегированных имен). Полное описание методологии Исследования можно найти в разделе 3.4 Исследования.

В Исследование также была включена информация о возможных вариантах снижения риска; при этом надо сказать, что никакие рекомендации по этим категориям не включались. ICANN опубликовала документ с предложением об устранении причин совпадения имен по результатам Исследования http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf> [PDF, 166 КБ] для получения комментариев общественности. Срок приема комментариев — с 5 августа по 17 сентября 2013 года.

7 октября 2013 года Комитет Правления ICANN по Программе New gTLD принял доработанную версию документа с предложениями <http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-07oct13-en.htm#1.a>, который содержит план устранения совпадений имен между новыми доменами общего пользования и теми же строками, уже использующимися во внутренних сетях.

Ниже приводятся часто задаваемые вопросы о плане и ответы ICANN.

1. По какому принципу ICANN составляла блок-лист доменных имен второго уровня (SLD) для использования в рамках альтернативного способа делегирования (Alternate Path to Delegation)?

   Список блокируемых SLD каждого TLD состоит из SLD, запросы к которым адресовались в отношении TLD в ходе сбора выборки по базе данных "День в жизни интернета" с 2006 по 2013 год и из массива данных, который использовался при развертывании DNSSEC в 2010 году.

2. По каким критериям новые домены общего пользования признавались неподходящими для применения альтернативного способа делегирования (Alternate Path to Delegation)?

   Неподходящими считались те новые домены общего пользования, в которых из года в год наблюдалось аномальное поведение с точки зрения дополнений к их списку запросов к SLD. Иными словами, ICANN не признает новый домен верхнего уровня подходящим для применения альтернативного способа делегирования (Alternate Path to Delegation) в случаях, когда список SLD претерпевает частые и значительные изменения.

   Источники данных, использующихся для составления вариаций в списках SLD, состоят из ежегодных "снимков" данных по запросам к DNS с 2006 по 2012 год. Набор данных 2013 года не был включен так как к тому времени строки уже были известны (а деятельность или исследования с использованием известных строк могут привести к субъективному анализу.) По этим строкам годовой прирост количества SLD, которым адресуются запросы – аномальный в сравнении с количеством предлагаемых доменов общего пользования в: (a) минимум одном из годовых сравнений, и (b) в 2012 году (что означает, что происходит отток).

   Например, если домен верхнего уровня имел аномальные показатели только при сравнении 2006-2007 годов, то он все равно считается подходящим. При этом если домен верхнего уровня имеет аномальные показатели при сравнении 2009-2010 годов и 2011-2012 годов, то он считается неподходящим для применения альтернативного способа делегирования (Alternate Path to Delegation).

3. Будут ли в блок-лист доменных имен второго уровня (SLD) вноситься поправки по результатам использования других массивов данных при работе над составлением Рамочного плана действий по устранению причин совпадений имен?

   Вносить поправки в блок-лист SLD для новых доменов общего пользования по результатам составления Рамочного плана не планируется. При этом, если в ходе разработки Рамочного плана откроются новые факты, они будут приняты на рассмотрение.

4. Доступен ли исходный код, который использовался для составления блок-листа?

   Процесс создания блок-листа подробно описывается в каждом отчете по альтернативному способу делегирования (Alternate Path to Delegation report) каждого нового домена общего пользования, с которым было подписано соглашение и который считается подходящим для применения альтернативного способа делегирования. В качестве примера можно просмотреть http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm

   Код, примененный для создания листов, основан на коде, опубликованном по адресу https://github.com/JASdevteam/dns-oarc

5. Как долго следует блокировать SLD в блок-листе?

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

6. В отношении каждого конкретного домена верхнего уровня, если в данных DITL появляется SLD "nic" (что указывает на возможное совпадение имен), почему "nic" допускается в домене общего пользования, и почему этот риск считается более приемлемым, чем риск любого другого совпадения имен?

   Единственное имя, использование которого обязательно в соответствии с контрактными положениями — это "whois.nic.<tld>", так как оно обеспечивает работу службы WHOIS регистратуры, т.е. "whois.nic.<tld>". ICANN взвесила степень риска, возникающего при использовании этого имени в сравнении с удобством размещения службы WHOIS в известном месте, и решила не включать "nic" в перечень SLD, блокируемых любым новым доменом общего пользования. При этом механизм реагирования на совпадение имен <http://www.icann.org/ru/help/name-collision> существует для предоставления возможности пострадавшим сторонам информировать о значительном уроне, причиняемом подобными доменными именами. Также следует отметить, что это имя предоставляется только самому оператору регистратуры, что значит, что регистратура имеет полный контроль над SLD.

7. Планирует ли ICANN пополнить перечень блокируемых SLD данными по году, в котором об этих именах направлялись запросы?

   ICANN не планирует пополнять перечень блокируемых SLD данными по году, в котором об этих именах направлялись запросы. При этом если сообщество выразит соответствующие пожелания, то ICANN изучит возможность добавления этих данных, когда на это появятся ресурсы.

8. Как следует поступать с именами в блок-листе SLD после получения разрешения на их использование в рамках приоритетной регистрации и сервиса уведомления о регистрации совпадающих доменных имен третьими лицами Депозитария товарных знаков (периода Sunrise and Claims)?

   Имена в блок-листе SLD домена верхнего уровня должны включаться в сервис Sunrise and Claims в соответствии со стандартной политикой регистратуры, но могут активироваться только после реализации мер устранения причин. Если оператор регистратуры распределяет имена из блок-листа SLD в течение периода Sunrise and Claims, то он должен проинформировать владельца домена о том, что имя нельзя активировать, и что оно возможно никогда не будет активировано, при чем последнее будет определяться результатами оценки риска совпадения имен.

   Ответ выше — пояснение формулировки в разделе 3.2 Плана действий по устранению причин совпадений имен. Блок-лист составляется для предотвращения определенных последствий до делегирования нового домена общего пользования (т.е. ответа NXDOMAIN в DNS); этот результат достигается если имена в списке не активируются, вне зависимости от их распределения.

9. Что считается вредом, достаточным для дезактивации имени домена верхнего уровня, вызывающего совпадения имен?

   Совпадения некоторых имен второго уровня могут не выявиться в наборе данных, который используется для блок-листа SLD, а возникнуть только после начала эксплуатации домена общего пользования. Для снижения этого риска, ICANN реализовала процесс, который поможет пострадавшей стороне сообщить об этом и попросить о временной блокировке недавно активированного доменного имени, причиняющего вред из-за совпадения имени.

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

10. Планируется ли создание портала по совпадению имен?

    ICANN планирует создание портала для предоставления информации по этому вопросу.

11. Подпадают ли различные типы испытательного делегирования (trial delegation) под действие Рамочного плана действий по устранению причин совпадений имен?

    Да, испытательное делегирование на верхнем уровне (для TLD, признанных неподходящими для применения альтернативного способа делегирования) и на втором уровне для SLD под всеми новыми доменами общего пользования, будет рассматриваться в ходе составления Рамочного плана. В случае принятия Рамочного плана ожидается, что в нем будут определены типы испытательного делегирования, применимые к каждому конкретному типу совпадения.

    Кроме того на встрече в Буэнос-Айресе Правление ICANN приняло резолюцию с поручением сотрудникам оценить рекомендации SAC 062 Консультативного комитета по безопасности и стабильности (SSAC) с конкретной просьбой к ICANN об изучении вопроса испытательного делегирования.

12. Каким образом разрабатывается Рамочный план действий по устранению причин совпадений имен и принимается решение о его принятии?

    Ожидается, что основной подрядчик будет работать над составлением проектной версии Рамочного плана совместно с сообществом <http://www.icann.org/en/news/announcements/announcement-2-11nov13-en.htm>. После этого Проект будет опубликован для получения предложений сообщества. После окончания периода получения комментариев общественности, будет составлена сводка комментариев, а затем на их основании в проектную версию Рамочного плана будут внесены поправки. И наконец Комитет программы New gTLD Правления ICANN рассмотрит окончательную версию Рамочного плана и примет решение о ее принятии.

13. Каким образом можно участвовать в разработке Рамочного плана действий по устранению причин совпадений имен?

    Все желающие приглашаются к участию в разработке Рамочного плана. Рамочный план будет обсуждаться в рамках открытого листа рассылки по адресу <https://lists.dns-oarc.net/mailman/listinfo/collisions>.

14. Будет ли работа по устранению совпадений имен распространена на национальные домены верхнего уровня (ссTLD)?

    Изначально вопрос совпадения имен был направлен в адрес ICANN в отношении Программы New gTLD. В свете того, что ожидается появление большого количества новых доменов общего пользования, приоритет отдается новым доменам общего пользования. Мы понимаем, что проблема касается не только gTLD, и поэтому ICANN попросила Комитет Правления по оценке риска решить, как следует действовать в отношении этого вопроса.