Skip to main content
Resources

Дополнение к политике по вопросам службы каталогов регистрационных данных (RDDS)

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

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

Актуализировано 21 февраля 2024 года с учетом изменений, необходимых для реализации политики в области регистрационных данных. Данная политика ранее называлась Дополнением к политике относительно данных WHOIS. Стороны, связанные договорными обязательствами, могут применять данную актуализированную Политику, начиная с 21 августа 2024 года, и должны реализовать ее не позднее 21 августа 2025 года.

Употребляемые в настоящем документе ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «БУДЕТ», «НЕ БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ» и «МОЖЕТ» и «НЕ ОБЯЗАТЕЛЬНО» следует понимать так, как описано в документах BCP 14 [RFC2119] [RFC8174] только в тех случаях, когда эти термины набраны прописными буквами, как показано здесь.

В разделе 1 данной политики подробно описаны не зависимые от технологии требования, которые применяются ко всем службам каталогов регистрационных данных.

В разделе 2 данной политики подробно описаны требования к реализации, относящиеся только к службе WHOIS (доступной через порт 43) и веб-службам каталогов WHOIS.

Регистраторы, аккредитованные ICANN, и регистратуры доменов общего пользования верхнего уровня (gTLD) в силу соответствующих соглашений, заключенных между ними и ICANN, обязаны по запросу предоставлять доступ к определенным регистрационным данным. Настоящее Дополнение к политике по вопросам RDDS дополнительно требует от регистраторов и регистратур включать в выходные данные RDDS информацию, которая поможет пользователям RDDS более эффективно определять регистратора, спонсирующего регистрацию, и понять коды статуса, используемые регистратурами и регистраторами:

  1. Операторы регистратур и регистраторы ОБЯЗАНЫ выполнять следующие требования:

    1.1 включить в результаты поиска по RDDS следующее сообщение: «Дополнительная информация о кодах статуса доменов доступна по адресу: https://icann.org/epp»*

    * Обратите внимание, что длинная форма приведенной выше ссылки, которая была включена в раздел 1(c) ранее, т.е. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, также соответствует данной Политике.

    1.2 при выдаче результатов поиска по RDDS регистратуры ДОЛЖНЫ использовать выданный ICANN Глобальный уникальный идентификационный номер регистратора (GURID, известный как идентификатор в IANA).

  2. Операторы регистратур и регистраторы ОБЯЗАНЫ реализовать следующие требования к службе WHOIS (доступной через порт 43) и веб-службам каталогов WHOIS:

    2.1 статус(ы) ДОЛЖЕН (ДОЛЖНЫ) отображаться с соответствующими статусами доменов;

    2.2 рядом с каждым статусом домена ДОЛЖНЫ отображаться ссылка или URL, ведущие на веб-страницу ICANN с описанием или определением соответствующего статуса домена. Список URL доступен здесь: https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en;

    2.3 Регистраторы НЕ ДОЛЖНЫ удалять приведенные выше ссылки и сообщение при предоставлении данных Whois из собственной службы Whois или службы Whois другого регистратора или регистратуры.

Примечания: Дополнение к политике относительно данных WHOIS (AWIP), переименованное в Дополнение к политике по вопросам службы каталогов регистрационных данных (ARIP), принято ICANN в виде согласованной политики 6 мая 2012 года. Дата вступления данной политики в силу — 31 января 2016 года. Все аккредитованные ICANN регистраторы и регистратуры gTLD обязаны соблюдать ARIP применительно к регистрациям, спонсируемым ими во всех gTLD, в отношении которых они аккредитованы или которые они администрируют, начиная с даты вступления в силу.

Целью данной политики является разъяснение значения статусов доменов в данных RDDS и обеспечение последовательной идентификации регистратора по GURID в RDDS.

Для справки: 24 июня 2009 года Совет GNSO запустил процесс разработки политики (PDP) в связи с процедурой межрегистраторского переноса (IRTP) (http://gnso.icann.org/en/council/resolutions#200906 – резолюция 20090624-2), а 30 мая 2011 года рабочая группа по PDP (рабочая группа B IRTP) представила итоговый отчет с набором рекомендаций (http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 971 КБ]), включая рекомендацию № 8: стандартизировать и пояснять сообщения RDDS о статусе, касающиеся статуса «Registrar Lock». 22 июня 2011 года Совет GNSO постановил, что до рассмотрения вопроса об утверждении рекомендации относительно стандартизации и пояснения сообщений RDDS, касающихся статуса «Registrar Lock», Совет GNSO просит персонал ICANN представить предложение, призванное обеспечить разработку технически осуществимого подхода для выполнения этой рекомендации. В ответ на эту просьбу персонал ICANN при участии рабочей группы разработал предложение, которое было опубликовано для общественного обсуждения и впоследствии принято Советом GNSO 16 февраля 2012 года (http://gnso.icann.org/en/council/resolutions#20120216-1). После проведения еще одного общественного обсуждения рекомендации и предложения (http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm) Правление ICANN приняло их 6 мая 2012 года. (https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5)

22 сентября 2011 года дополнительной рабочей группе GNSO (рабочей группе C IRTP) было поручено рассмотреть три вопроса, связанных с IRTP, в том числе вопрос о том, можно ли упорядочить этот процесс путем введения требования об использовании регистратурами для регистраторов идентификаторов IANA вместо собственных идентификаторов (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter). Рабочая группа выпустила первоначальный отчет, который стал предметом общественного обсуждения, а затем итоговый отчет, который был принят Советом GNSO 17 октября 2012 года. После еще одного общественного обсуждения 20 декабря 2012 года Правление ICANN приняло рекомендации, содержащиеся в итоговом отчете (http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a).

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."