Skip to main content
Resources

Уведомление относительно Спецификации 11 (3) b Соглашения об администрировании нового gTLD

Страница также доступна на следующих языках:

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

Дата публикации: 8 июня 2017 года

Вступление

ICANN публикует настоящее Уведомление в ответ на вопросы, поступившие от некоторых операторов регистратур о способах соблюдения следующих требований Раздела 3 (b) Спецификации 11 Соглашения об администрировании нового домена верхнего уровня (gTLD) («Спецификация 11 (3) (b)»):

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

В настоящем Уведомлении описан один возможный подхода, которым операторы регистратуры могут воспользоваться для проведения вышеописанных технических анализов угрозы безопасности и для подготовки статистических отчетов в соответствии со Спецификацией 11 (3)(b).  Отметим, что использование описанного в настоящем Уведомлении подхода операторами регистратур не приравнивается к соблюдению требования. Операторы регистратуры во всех случаях обязаны демонстрировать соблюдение требований в индивидуальном порядке на основании результатов расследования, фактов и аудитов. Операторы регистратуры имеют право применять собственные процедуры для соблюдения требований Спецификации 11 (3) (b).

Определение понятия «угроза безопасности»

Для целей настоящего Уведомления, «угрозы безопасности» («Угрозы безопасности»), о которых упоминается в Спецификации 11 (3)(b), включают, среди прочего:

  • фарминг1,
  • фишинг,
  • вредоносное ПО,
  • ботнеты, а также
  • другие типы угроз безопасности.

Что должен включать «технический анализ» для исполнения требований настоящего Уведомления:

«Технический анализ» может включать  следующие меры, предпринятые для выявления угроз безопасности в TLD:

  • анализ потоков данных; и/или
  • проведение автоматических анализов, обеспечивающих данные как минимум эквивалентные данным, предоставляемым провайдерами услуг проверки репутации доменов.

Проведение технического анализа

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

В целях настоящего Уведомления, провайдерами услуг обеспечения репутации доменов считаются организации, владеющие или управляющие базами данных с информацией о доменных именах и о их связи с угрозами безопасности, и предоставляющие услуги известные под названием «услуги проверки репутации».

  • Использование услуг проверки репутации

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

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

  • Выбор провайдера услуг проверки репутации

    При выборе провайдера услуг проверки репутации (или при предоставлении этих услуг) операторам регистратур следует принимать во внимание следующие критерии:

    • Занимается ли провайдер услуг проверки репутации теми угрозами безопасности, относительно которых оператор регистратуры хотел бы получить данные о репутации?
    • Сообщает ли провайдер услуг проверки репутации оператору регистратуры о включении того или иного доменного имени в базу данных провайдера услуг проверки репутации доменов?
    • Существует ли механизм автоматизации запросов, такой как API?
    • Существует ли общедоступное описание методологии и критериев, использующихся провайдером услуг проверки репутации доменов при подготовке данных о репутации доменов, включая: принципы включения имен в базу (базы) данных, срок хранения этих имен в базе (базах) данных и принципы удаления имен из базы (баз) данных.

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

Частота проведения технического анализа и подготовки статистических отчетов по выявленным угрозам безопасности

Проведение технического анализа в соответствии со Спецификацией 11 (3) (b) предоставляет оператору регистратуры возможность определить, которое доменное имя (имена) в их TLD связано с угрозами безопасности.  Эта информация используется для подготовки описанных в Уведомлении статистических отчетов.

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

Статистические отчеты по выявленным угрозам безопасности и предпринятым мерам

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

Статистические отчеты обычно включают следующую информацию:

  • Количество проанализированных доменных имен;
  • Список доменных имен и потенциальных угроз;
  • Тип выявленной угрозы, например, вредоносное ПО и ботнеты;
  • Тип действия, предпринятого при возникновении угрозы, например, приостановка домена;
  • Статус работ (открытый/на рассмотрении/закрытый) по угрозе и статистика по предпринятым действиям;
  • Дополнительная информация об угрозах, такая как IP-адрес, географическое расположение, информация о регистрации; а также
  • Тенденции и оповещения.

1 Фарминг представляет угрозу для услуг разрешения доменных имен, а не регистрационных услуг, в связи с чем он не входит в сферу деятельности провайдеров услуг проверки репутации доменов и не подпадает под инструкции, включенные в настоящее Уведомление.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."