Skip to main content
Resources

Политика перехода к использованию расширенного варианта записи данных WHOIS для доменов .COM, .NET и .JOBS

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

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

Новости

7 ноября 2019 года Правление ICANN приняло резолюцию отложить контроль за соблюдением договорных положений. Отдел ICANN по контролю исполнения договорных обязательств отложит контроль за соблюдением политики перехода к использованию расширенного варианта записи данных WHOIS до тех пор, пока не произойдет все нижеперечисленное:

  • группа по анализу реализации политики в области регистрационных данных в gTLD (IRT) завершит свой анализ и установит ориентировочные сроки выполнения рекомендаций рабочей группы по ускоренному процессу формирования политики (EPDP), принятых Правлением ICANN 15 мая 2019 года;
  • корпорация ICANN и IRT предоставят Совету GNSO необходимую информацию о влиянии рекомендаций группы по EPDP на существующие процедуры и политику (в том числе на политику перехода к использованию расширенного варианта записи данных WHOIS), и
  • Совет GNSO определит, следует ли принять меры по обновлению соответствующих процедур и политики (которые могут включать дополнительную работу по формированию политики, указания или другие действия, которые необходимо определить), влияющие на политику перехода к использованию расширенного варианта записи данных WHOIS.

Употребляемые в настоящем документе ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «БУДЕТ», «НЕ БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ» и «МОЖНО» следует понимать так, как описано в документе RFC 2119, который представлен по адресу http://www.ietf.org/rfc/rfc2119.txt.

Рамки:

Настоящая политика ДОЛЖНА применяться к операторам регистратур gTLD .COM, .NET и .JOBS, а также ко всем регистраторам, спонсирующим регистрацию доменных имен в зонах gTLD .COM, .NET или .JOBS.

Определения:

    • Сокращенный вариант записи данных (зарегистрированного имени): доменное имя, для которого оператор регистратуры поддерживает и предоставляет только техническую информацию (например, серверы имен, статусы, дату регистрации доменного имени) и сведения о спонсирующем регистраторе этого доменного имени. Контактные данные владельца доменного имени поддерживаются спонсирующим регистратором.
    • Расширенный вариант записи данных (зарегистрированного имени): доменное имя, для которого спонсирующий регистратор предоставляет оператору регистратуры копию контактных данных владельца. Оператор регистратуры поддерживает техническую информацию (например, серверы имен, статусы, дату регистрации доменного имени) и сведения о спонсирующем регистраторе этого доменного имени. Контактные данные владельца доменного имени поддерживаются спонсирующим регистратором.
    • Существующее доменное имя: доменное имя, которое было создано или которому был присвоен статус pendingCreate до 1 мая 2018 года.
    • Показатели выполнения перехода: показатели, которые создаются оператором регистратуры и регулярно передаются регистраторам и ICANN и которые позволяют измерять ход выполнения перехода от использования сокращенного варианта записи данных на расширенный вариант записи данных регистратуры, в том числе по меньшей мере общее количество доменов в управлении регистратора, количество и доля доменов с прилагаемыми контактными данными.

Политика и сроки вступления ее в силу:

3.1 Все новые регистрируемые доменные имена ДОЛЖНЫ подаваться с расширенным вариантом записи данных начиная самое позднее с 1 мая 2018 года.

3.2 Все соответствующие регистрационные данные для существующих доменов верхнего уровня ДОЖНЫ быть переведены с сокращенного на расширенный вариант записи данных к 1 февраля 2019 года.

Следующие требования распространяются только на операторов регистратур:

4.1 Оператор регистратуры ДОЛЖЕН развернуть механизм EPP и альтернативный механизм массового переноса к 1 августа 2017 года, чтобы регистраторы могли перенести регистрационные данные для существующих доменов верхнего уровня (то есть выполнить переход с сокращенного на расширенный вариант записи).

4.2 К 1 мая 2017 года оператор регистратуры ДОЛЖЕН предоставить соответствующим регистраторам и ICANN документацию, отражающую системные изменения, которые необходимы для выполнения требований, описанных в разделе 4.1.

4.3 К 1 мая 2017 года оператор регистратуры ДОЛЖЕН развернуть механизм EPP и альтернативный механизм массового переноса в соответствующей среде эксплуатационных испытаний (OT&E), чтобы регистраторы могли тестировать миграцию регистрационных данных для существующих доменных имен (т. е. переход с сокращенного на расширенный вариант записи).

4.4 К 1 августа 2017 года оператор регистратуры ДОЛЖЕН обеспечить поддержку для всех команд по работе с контактными данными, указанных в документе RFC5733, как описано в этом положении. Оператор регистратуры будет ТРЕБОВАТЬ заполнять поля контактных данных протокола EPP <contact:id>, <contact:postalInfo type> и <contact:authInfo>. Оператор регистратуры ДОЛЖЕН принимать, но НЕ ДОЛЖЕН требовать до 1 февраля 2019 года использования всех прочих элементов регистрационных данных, которые позволяют обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных.

4.5 Начиная с 1 мая 2018 года оператор регистратуры ДОЛЖЕН требования использования расширенного варианта записи данных регистратуры для команды <create> объекта домена протокола EPP, как описано в данном положении. Оператор регистратуры ДОЛЖЕН требовать использования всех элементов регистрационных данных, которые позволяют обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных.

4.6 С 1 августа 2017 года по 1 февраля 2019 года оператор регистратуры ОБЯЗАН предоставлять показатели выполнения перехода каждому регистратору не реже чем раз в месяц, к 23:59 UTC первого дня следующего месяца.

4.7 С 1 августа 2017 года по 1 февраля 2019 года оператор регистратуры ОБЯЗАН предоставлять ICANN все показатели выполнения перехода по всем регистраторам не реже чем раз в месяц, к 23:59 UTC первого дня следующего месяца.

4.8 Оператор регистратуры МОЖЕТ выполнить требования политике обеспечения единообразия в названиях полей и при отображении информации в Службе каталогов регистрационных данных (политика CL&D) в соответствии с разделом 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему к 1 августа 2017 года.

4.9 Оператор регистратуры ДОЛЖЕН обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных к 1 мая 2018 года для новых регистраций и к 1 февраля 2019 года для существующих доменных имен.

4.10 С 1 августа 2017 года по 1 февраля 2019 года для существующих доменных имен для следующих полей вывода данных службы каталогов регистрационных данных (RDDS), по которым отсутствуют данные в общей системе регистрации (SRS) оператор регистратуры МОЖЕТ обрабатывать следующие поля RDDS как необязательные, как описано в уточнении 1 документа «Рекомендация: пояснения к соглашению об администрировании домена верхнего уровня и соглашению об аккредитации регистратора от 2013 года (RAA), спецификация на службу каталогов регистрационных данных (WHOIS)»:

    • Идентификатор владельца домена/контактного лица по административным вопросам/технической службы регистратуры
    • Имя владельца домена/контактного лица по административным вопросам/технической службы
    • Улица владельца домена/контактного лица по административным вопросам/технической службы
    • Город владельца домена/контактного лица по административным вопросам/технической службы
    • Страна владельца домена/контактного лица по административным вопросам/технической службы
    • Номер телефона владельца домена/контактного лица по административным вопросам/технической службы
    • Адрес электронной почты владельца домена/контактного лица по административным вопросам/технической службы

4.11 Контактное лицо по вопросам выставления счетов является необязательным, если в соглашении об администрировании домена верхнего уровня не предусмотрено иное требование. Политика регистратуры может определять, является ли это поле обязательным, неоязательным или неподдерживаемым. Если это поле поддерживается, контактные данные лица для связи по вопросам выставления счетов должны отображаться. как указано в документе: «Рекомендация: пояснения к соглашению об администрировании домена верхнего уровня и соглашению об аккредитации регистратора от 2013 года (RAA), спецификация на службу каталогов регистрационных данных (WHOIS)» (раздел 22).

Следующие требования распространяются только на регистраторов:

5.1 С 1 августа 2017 года по 1 февраля 2019 года регистраторы ДОЛЖНЫ мигрировать на все обязательные для существующих доменных имен поля соответствующего оператора регистратуры, которые имеются в базе данных регистратора и позволяют оператору регистратуры обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных.

5.2 Регистраторы МОГУТ предоставлять операторам регистратур расширенный вариант записи данных, которые позволяют обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных, при регистрации новых доменных имен начиная с 1 августа 2017 года.

5.3 Регистраторы ДОЛЖНЫ предоставлять операторам регистратур расширенный вариант записи данных, которые позволяют обеспечить выполнение требований в отношении WHOIS (через порт 43) и веб-служб каталогов, описанных в разделе 1 спецификации 4 базового соглашения об администрировании домена верхнего уровня от 9 января 2014 года (базового соглашения об администрировании домена верхнего уровня) или последующих поправок к нему, а также политики обеспечения единообразия в названиях полей и при отображении информации в службе каталогов регистрационных данных, при регистрации новых доменных имен начиная с 1 мая 2018 года.

Замечание по реализации

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

История вопроса

Правление ICANN приняло рекомендации по согласованной политике рабочей группы GNSO по расширенному варианту записи данных WHOIS в отношении использования расширенного варианта записи данных WHOIS всеми регистратурами gTLD 7 февраля 2014 года, после того, как эти рекомендации были утверждены Советом GNSO. Рекомендация 1 гласит: «Предоставление услуг расширенного варианта записи данных WHOIS, обеспечение единообразия в названиях полей и при отображении информации в соответствии со Спецификацией 3 [Соглашения об аккредитации регистраторов] редакции 2013 года, должно стать требованием ко всем регистратурам gTLD, как существующих, так и будущих». (См. резолюции Правления ICANN 2014.02.07.08 – 2014.02.07.09 по адресу http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c).

ICANN работала над выполнением этих рекомендаций в отношении политики с группой членов сообщества (т. е. группой подготовки рекомендаций по реализации). В рамках выполнения рекомендаций и до их принятия ICANN запросила мнение сообщества о предлагаемых рекомендациях в отношении политики, а полученные предложения были включены в настоящую политику. (См. https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en).

Кроме того, в итоговый отчет [PDF, 1,23 МБ] рабочей группы процесса разработки политики использования WHOIS с расширенным вариантом записи данных был включен раздел 7.2 «Соображения в отношении реализации», в котором была представлена информация о графике и требованиях к реализации перехода от использования минимального набора данных Whois к расширенному набору данных. В нем в частности отмечено следующее: «РГ подчеркивает, что реализация одной из частей рекомендации (например, переход существующих регистратур gTLD с минимальным набором данных на модель с расширенным набором) не обязательно приведет к отсрочке реализация другой ее части (например, единообразные идентификация и отображение таких данных)».

Вследствие этого организация ICANN совместно с группой подготовки рекомендаций по реализации работала над параллельными планами реализации перехода зарегистрированных имен с сокращенным вариантом записи данных Whois на расширенный вариант записи с единообразными названиями полей и отображением данных Whois. Дополнительные сведения см. по адресу: https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en.

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