Skip to main content
Resources

Политика в области регистрационных данных

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

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

Политика в области регистрационных данных

  1. Введение
  2. Область применения
  3. Определения и толкование
  4. Дата вступления политики в силу
  5. Соглашение о защите данных
  6. Сбор регистрационных данных
  7. Передача регистратором регистрационных данных оператору регистратуры
  8. Передача регистрационных данных поставщикам услуг по временному депонированию данных
  9. Публикация регистрационных данных доменного имени
  10. Запросы на раскрытие информации
  11. Журналы событий
  12. Хранение регистрационных данных

Дополнение I

Дополнение II

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

  1. Обработка регистрационных данных
  2. Передача регистрационных данных
  3. Передача регистрационных данных провайдерам усулг по временному депонированию данных
  4. Публикация организации владельца домена
  5. Ответ на обоснованные просьбы о законном раскрытии информации
  6. Хранение регистрационных данных
  7. Аффилированные и аккредитованные сервисы сохранения конфиденциальности и регистрации через доверенных лиц
  8. Дата создания
  9. Дата обновления

Историческая справка

Политика в области регистрационных данных

  1. Введение

    Политика в отношении регистрационных данных («Политика») — это согласованная политика ICANN, которая описывает требования к обработке регистрационных данных для каждого регистратора, аккредитованного ICANN («Регистратор») и оператора регистратуры gTLD, заключившего соглашение с ICANN («Оператор регистратуры»).

  2. Область применения

    2.1. Эта политика применяется к каждому регистратору, аккредитованному ICANN, и оператору регистратуры, заключившему соглашение с ICANN.

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

  3. Определения и толкование

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

    3.2. «Согласие» Субъекта данных означает любое свободно данное, конкретное, информированное и недвусмысленное выражение желания Субъекта данных, в котором Субъект данных, путем заявления или четкого утвердительного действия, выражает согласие на обработку персональных данных, относящихся к Субъекту данных.

    3.3. «Персональные данные» означают любую информацию, относящуюся к идентифицированному или идентифицируемому физическому лицу («Субъект данных»).

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

    3.5. «Публикация», «публиковать» и «опубликованный» означает предоставление Регистрационных данных в общедоступных Службах каталогов Регистрационных данных.

    3.6. «Регистрационные данные» означают значения элементов данных, собранные у физического или юридического лица или сгенерированные Регистратором или Оператором регистратуры, в любом случае в связи с Зарегистрированным именем в соответствии с разделом 6 настоящей Политики.

    3.7. Под «обоснованными запросами на законное раскрытие информации» («Запросы на раскрытие информации») понимаются запросы, поданные Оператору регистратуры или Регистратору на раскрытие закрытых Регистрационных данных в соответствии с требованиями Раздела 10.

    3.8. Термины, выделенные заглавными буквами, но не определенные в настоящей Политике, ДОЛЖНЫ иметь значение, данное им в Соглашении об администрировании домена верхнего уровня или Соглашении об аккредитации регистраторов, в зависимости от обстоятельств.

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

  4. Дата вступления политики в силу

    Настоящая Политика вступает в силу 21 августа 2025 года. Временная политика в области регистрационных данных для gTLD будет действовать до 20 августа 2025 года. В период с 21 августа 2024 года по 20 августа 2025 года регистратура и регистратор могут продолжать осуществлять меры, соответствующие Временной спецификации для регистрационных данных в gTLD или настоящей политике в полном объеме, или элементам обоих документов.

  5. Соглашение о защите данных

    ICANN, операторы регистратур gTLD и аккредитованные регистраторы ОБЯЗАНЫ заключить друг с другом и с соответствующими сторонними поставщиками необходимые соглашения о защите данных, предусмотренные настоящей Политикой, если того требует применимое законодательство. Условия могут включать правовые основания для обработки Регистрационных данных.

    Если такие соглашения между Оператором регистратуры или Регистратором и ICANN необходимы для соблюдения применимого законодательства, ICANN ОБЯЗАНА по запросу и без неоправданной задержки заключить соглашение или соглашения о защите данных с Оператором регистратуры или Регистратором в соответствии с настоящей Политикой.

    Если Оператор регистратуры или Регистратор решит, что такие соглашения требуются в соответствии с применимым законодательством, он ОБЯЗАН сделать запрос без неоправданной задержки в соответствии с данной политикой.

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

  6. Сбор регистрационных данных

    6.1. Регистратор ДОЛЖЕН собирать или генерировать (отмеченные звездочкой) значения для следующих элементов данных:

    6.1.1. Доменное имя

    6.1.2. Сервер Whois регистратора*

    6.1.3. URL-адрес регистратора*

    6.1.4. Регистратор*

    6.1.5. ID IANA регистратора*

    6.1.6. Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени*

    6.1.7. Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени*

    6.1.8. Статус (статусы) домена*

    6.1.9. Имя владельца домена

    6.1.10. Улица владельца домена

    6.1.11. Город владельца домена

    6.1.12. Регион владельца домена

    6.1.13. Почтовый индекс владельца домена

    6.1.14. Страна владельца домена

    6.1.15. Телефон владельца домена

    6.1.16. Адрес электронной почты владельца домена

    6.1.17. Дата окончания срока регистрации доменного имени*

    Значения параметров «Регион» и «Почтовый индекс» необходимо указывать только в том случае, если они применимы для данной страны или территории, как определено в стандартах почтовой адресации UPU или других эквивалентных стандартах для данной страны или территории.

    Значение «Сервер Whois регистратора» необходимо генерировать только в том случае, если это требуется соглашением об аккредитации регистраторов или согласованной политикой ICANN.

    6.2. Регистратор МОЖЕТ предоставить владельцу зарегистрированного имени возможность указать значения для следующих элементов данных. Если Регистратор предлагает сбор значений и Владелец зарегистрированного имени решает предоставить занчение, Регистратор ОБЯЗАН его зафиксировать:

    6.2.1. Добавочный телефон владельца домена

    6.2.2. Факс владельца домена

    6.2.3. Добавочный номер факса владельца домена

    6.2.4. Наименование технической службы

    6.2.5. Телефон технической службы

    6.2.6. Адрес электронной почты технической службы

    6.3. Если владелец зарегистрированного имени указывает контактное лицо по техническим вопросам, регистратор ОБЯЗАН сообщить владельцу зарегистрированного имени во время регистрации, что вместо предоставления личной контактной информации владелец зарегистрированного имени может (a) назначить в качестве контактного лица по техническим вопросам то же лицо, что и владелец зарегистрированного имени (или его представителя); или (b) предоставить контактную информацию, не являющуюся личными данными контактного лица по техническим вопросам (например, адрес электронной почты tech-assistance@example.org вместо john.doe@example.org).

    6.4. Регистратор МОЖЕТ генерировать значение элемента данных «Реселлер».

    6.5. Регистратор ОБЯЗАН предоставить владельцу зарегистрированного имени возможность указать значения для следующих элементов данных. Если следующие значения элементов данных предоставлены владельцем зарегистрированного имени, регистратор ОБЯЗАН зафиксировать их:

    6.5.1. Организация владельца домена

    6.5.2. DNS-сервер

    6.5.3. IP-адрес DNS-сервера

    6.5.4. Элементы DNSSEC

    6.6. Если владелец зарегистрированного имени вводит значение для элемента данных «Организация владельца домена», Регистратор ОБЯЗАН сообщить владельцу зарегистрированного имени следующее:

    6.6.1. Организация владельца домена будет опубликована в RDDS, если владелец зарегистрированного имени согласится на публикацию значения; и

    6.6.2. Организация владельца домена будет считаться владельцем зарегистрированного имени.

    6.7. Регистратор МОЖЕТ собирать дополнительные элементы данных в соответствии с требованиями соглашения между регистратурами и регистраторами и/или регистрационной политики оператора регистратуры.

    6.8. Регистратор МОЖЕТ удалить данные контактного лица по административным вопросам, которые были собраны до даты вступления в силу настоящей Политики. Перед удалением данных контактного лица по административным вопросам регистратор ОБЯЗАН убедиться, что значения для требуемых элементов данных владельца зарегистрированного имени в разделах 6.1.9-6.1.16 были собраны.

  7. Передача регистратором регистрационных данных оператору регистратуры

    7.1. Регистратор ОБЯЗАН передать Оператору регистратуры следующие элементы данных:

    7.1.1. Доменное имя

    7.1.2. URL-адрес регистратора

    7.1.3. Регистратор

    7.1.4. ID IANA регистратора

    7.1.5. Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    7.1.6. Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    7.1.7. Статус (статусы) домена

    7.2. Регистратор ОБЯЗАН передать оператору регистратуры следующие элементы данных, если они были собраны или сгенерированы:

    7.2.1. Сервер Whois регистратора

    7.2.2. DNS-сервер

    7.2.3. IP-адрес DNS-сервера

    7.2.4. Элементы DNSSEC

    7.3. Регистратор ОБЯЗАН передавать Оператору регистратуры следующие элементы данных при наличии соответствующей правовой основы и соглашения об обработке данных.

    7.3.1. Имя владельца домена

    7.3.2. Улица владельца домена

    7.3.3. Город владельца домена

    7.3.4. Страна владельца домена

    7.3.5. Телефон владельца домена

    7.3.6. Адрес электронной почты владельца домена

    7.4. Регистратор ОБЯЗАН передавать Оператору регистратуры следующие элементы данных (если они собираются) при наличии соответствующей правовой основы и соглашения об обработке данных:

    7.4.1. Организация владельца домена

    7.4.2. Регион владельца домена

    7.4.3. Почтовый индекс владельца домена

    7.4.4. Добавочный телефон владельца домена

    7.4.5. Факс владельца домена

    7.4.6. Добавочный номер факса владельца домена

    7.4.7. Наименование технической службы

    7.4.8. Телефон технической службы

    7.4.9. Адрес электронной почты технической службы

    7.5. Регистратор МОЖЕТ передавать оператору регистратуры следующие элементы данных, если они поддерживаются оператором регистратуры:

    7.5.1. Дата окончания срока регистрации доменного имени

    7.5.2. Реселлер

  8. Передача регистрационных данных поставщикам услуг по временному депонированию данных

    8.1. Регистратор ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, следующих элементов данных провайдеру услуг временного депонирования данных, утвержденному ICANN:

    8.1.1. Доменное имя

    8.1.2. Дата окончания срока регистрации доменного имени

    8.1.3. ID IANA регистратора

    8.1.4. Имя владельца домена

    8.1.5. Улица владельца домена

    8.1.6. Город владельца домена

    8.1.7. Регион владельца домена

    8.1.8. Почтовый индекс владельца домена

    8.1.9. Страна владельца домена

    8.1.10. Телефон владельца домена

    8.1.11. Адрес электронной почты владельца домена

    Значения параметров «Регион» и «Почтовый индекс» не требуется передавать, если они недоступны для соответствующей страны или территории.

    8.2. Если Регистратор собирает или генерирует следующие элементы данных, Регистратор ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, провайдеру услуг временного депонирования данных, утвержденному ICANN:

    8.2.1. Организация владельца домена

    8.3. Если Регистратор собирает или генерирует какие-либо из перечисленных ниже элементов данных, Регистратор ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, описанных ниже элементов данных провайдеру услуг временного депонирования данных, утвержденному ICANN:

    8.3.1. Реселлер

    8.3.2. Добавочный телефон владельца домена

    8.3.3. Факс владельца домена

    8.3.4. Добавочный номер факса владельца домена

    8.3.5. Наименование технической службы

    8.3.6. Телефон технической службы

    8.3.7. Адрес электронной почты технической службы

    8.4. Оператор регистратуры ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, следующих элементов данных агенту по временному депонированию данных, утвержденному ICANN:

    8.4.1. Доменное имя

    8.4.2. Идентификатор домена в регистратуре

    8.4.3. URL-адрес регистратора

    8.4.4. Дата создания

    8.4.5. Дата истечения срока действия регистратуры

    8.4.6. Регистратор

    8.4.7. ID IANA регистратора

    8.4.8. Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    8.4.9. Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    8.4.10. Статус (статусы) домена

    8.5. Оператор регистратуры ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, следующих элементов данных провайдеру услуг временного депонирования данных, утвержденному ICANN, если они переданы Регистратором или сгенерированы Оператором регистратуры:

    8.5.1. Сервер Whois регистратора

    8.5.2. Дата обновления

    8.5.3. Дата окончания срока регистрации доменного имени

    8.5.4. Реселлер

    8.5.5. Идентификатор владельца домена регистратуры

    8.5.6. Имя владельца домена

    8.5.7. Организация владельца домена

    8.5.8. Улица владельца домена

    8.5.9. Город владельца домена

    8.5.10. Регион владельца домена

    8.5.11. Почтовый индекс владельца домена

    8.5.12. Страна владельца домена

    8.5.13. Телефон владельца домена

    8.5.14. Добавочный телефон владельца домена

    8.5.15. Факс владельца домена

    8.5.16. Добавочный номер факса владельца домена

    8.5.17. Адрес электронной почты владельца домена

    8.5.18. DNS-сервер

    8.5.19. Элементы DNSSEC

    8.5.20. IP-адрес DNS-сервера

    8.6. Оператор регистратуры ОБЯЗАН предоставить электронную копию в формате, указанном ICANN, следующих элементов данных агенту по временному депонированию данных, утвержденному ICANN, если они переданы Регистратором или сгенерированы Оператором регистратуры:

    8.6.1. Идентификатор технической службы регистратуры

    8.6.2. Наименование технической службы

    8.6.3. Телефон технической службы

    8.6.4. Адрес электронной почты технической службы

  9. Публикация регистрационных данных доменного имени

    9.1. Требования к публикации RDDS

    9.1.1. В ответах на запросы к RDDS регистратор и оператор регистратуры ОБЯЗАНЫ публиковать следующие элементы данных:

    9.1.1.1. Доменное имя

    9.1.1.2. URL-адрес регистратора

    9.1.1.3. Дата создания

    9.1.1.4. Дата истечения срока действия регистратуры (исключение: Регистратор МОЖЕТ публиковать)

    9.1.1.5. Дата окончания срока регистрации доменного имени (исключение: Оператор регистратуры МОЖЕТ публиковать)

    9.1.1.6. Регистратор

    9.1.1.7. ID IANA регистратора

    9.1.1.8. Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    9.1.1.9. Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени

    9.1.1.10. Статус (статусы) домена

    9.1.1.11. Последнее обновление RDDS

    9.1.2. В ответах на запросы к RDDS Регистратор и Оператор регистратуры ОБЯЗАНЫ публиковать следующие элементы данных, если они были собраны, переданы или сгенерированы:

    9.1.2.1. Сервер Whois регистратора

    9.1.2.2. Дата обновления

    9.1.2.3. DNS-сервер

    9.1.2.4. Элементы DNSSEC

    9.1.3. В ответах на запросы к RDDS и с учетом требований раздела 9.2, (a) Регистратор ОБЯЗАН публиковать следующие элементы данных, если они собраны или сгенерированы, и (b) Регистратура ОБЯЗАНА публиковать следующие элементы данных, если они переданы Регистратором или сгенерированы Оператором регистратуры:

    9.1.3.1. Идентификатор домена в регистратуре

    9.1.3.2. Идентификатор владельца домена регистратуры

    9.1.3.3. Организация владельца домена

    9.1.3.4. Почтовый индекс владельца домена

    9.1.3.5. Идентификатор технической службы регистратуры

    9.1.3.6. Наименование технической службы

    9.1.3.7. Телефон технической службы

    9.1.3.8. Адрес электронной почты технической службы

    9.1.4. В ответах на запросы к RDDS (a) Регистратор ОБЯЗАН опубликовать элемент данных «Регион владельца домена», если он зафиксирован, и (b) Оператор регистратуры ОБЯЗАН опубликовать элемент данных «Регион владельца домена», если он передан Регистратором.

    9.1.5. В ответах на запросы к RDDS (a) Регистратор ОБЯЗАН опубликовать элемент данных «Страна владельца домена» и (b) Оператор регистратуры ОБЯЗАН опубликовать элемент данных «Страна владельца домена», если он передан Регистратором.

    9.1.6. В ответах на запросы к RDDS и с учетом требований раздела 9.2, (a) Регистратор ОБЯЗАН публиковать следующие элементы данных, и (b) Регистратура ОБЯЗАНА публиковать следующие элементы данных, если они переданы Регистратором:

    9.1.6.1. Имя владельца домена

    9.1.6.2. Улица владельца домена

    9.1.6.3. Город владельца домена

    9.1.6.4. Телефон владельца домена

    9.1.6.5. Адрес электронной почты владельца домена

    9.1.7. В ответах на запросы к RDDS Регистратор и Оператор регистратуры МОГУТ публиковать элемент данных «Реселлер».

    9.1.8. В ответах на запросы к RDDS Регистратор МОЖЕТ публиковать элемент данных «IP-адрес DNS-сервера».

    9.1.9. В ответах на запросы к RDDS Оператор регистратуры:

    9.1.9.1. ОБЯЗАН публиковать элемент данных «IP-адрес DNS-сервера», если Соглашение об администрировании домена верхнего уровня предусматривает публикацию внутридоменных связующих записей (как определено в RFC8499).

    9.1.9.2. МОЖЕТ публиковать элемент данных «IP-адрес DNS-сервера», если это не требуется Соглашением об администрировании домена верхнего уровня.

    9.1.10. В ответах на запросы к RDDS и с учетом требований раздела 9.2 Регистратор и Оператор регистратуры МОГУТ публиковать следующие элементы данных:

    9.1.10.1. Добавочный телефон владельца домена

    9.1.10.2. Факс владельца домена

    9.1.10.3. Добавочный номер факса владельца домена

    9.2. Требования к вымарываниям при публикации регистрационных данных

    9.2.1. Оператор регистратуры и Регистратор: (a) ОБЯЗАНЫ применять требования раздела 9.2 в RDDS, если вымарывание Персональных данных, содержащихся в Регистрационных данных, требуется в целях соблюдения применимого законодательства; (b) МОГУТ применять требования раздела 9.2, ЕСЛИ (i) у них есть коммерчески обоснованная цель сделать это; ИЛИ (ii) если нет технической возможности ограничить применение требований данного раздела. При определении необходимости применения требований раздела 9.2 Оператор регистратуры и Регистратор МОГУТ (но не обязаны) учитывать, относятся ли регистрационные данные к юридическому лицу или содержат ли они персональные данные; а также географическое положение владельца зарегистрированного имени или соответствующего контактного лица.

    9.2.2. Для целей раздела 9.2 термин «Вымарывание» определяется как удовлетворяющий следующим условиям: Оператор регистратуры и Регистратор (a) НЕ ДОЛЖНЫ включать значение элемента данных в выходные данные RDDS и (b) ОБЯЗАНЫ указывать, что значение отредактировано.

    9.2.2.1. Если Оператор регистратуры и Регистратор применяет требования раздела 9.2.1, он ОБЯЗАН вымарать значения для следующих элементов данных с учетом исключений, описанных в следующих подразделах:

    9.2.2.1.1. Идентификатор домена в регистратуре

    9.2.2.1.2. Идентификатор владельца домена регистратуры

    9.2.2.1.3. Имя владельца домена

    9.2.2.1.4. Улица владельца домена

    9.2.2.1.5. Почтовый индекс владельца домена

    9.2.2.1.6. Телефон владельца домена

    9.2.2.1.7. Добавочный телефон владельца домена

    9.2.2.1.8. Факс владельца домена

    9.2.2.1.9. Добавочный номер факса владельца домена

    9.2.2.1.10. Идентификатор технической службы регистратуры

    9.2.2.1.11. Наименование технической службы

    9.2.2.1.12. Телефон технической службы

    9.2.2.2. Если Оператор регистратуры применяет требования раздела 9.2.1, Оператор регистратуры ОБЯЗАН вымарать значения для следующих элементов данных:

    9.2.2.2.1. Адрес электронной почты владельца домена

    9.2.2.2.2. Адрес электронной почты технической службы

    9.2.2.3. Если Оператор регистратуры применяет требования раздела 9.2.1, Оператор регистратуры МОЖЕТ вымарать значение «Организация владельца домена».

    9.2.2.4. Если Регистратор или Оператор регистратуры применяет требования раздела 9.2.1, он МОЖЕТ вымарать значение «Город владельца домена».

    9.2.3. Если Регистратор применяет требования раздела 9.2.1 для следующих элементов данных, Регистратор ОБЯЗАН опубликовать адрес электронной почты или ссылку на веб-форму для облегчения связи по электронной почте с соответствующим контактным лицом для значения «Электронная почта», которое НЕ ДОЛЖНО идентифицировать адрес электронной почты контактного лица или само контактное лицо.

    9.2.3.1. Адрес электронной почты владельца домена

    9.2.3.2. Адрес электронной почты технической службы

    9.2.4. Если Регистратор применяет требования раздела 9.2.1 к значениям элементов данных, перечисленных в разделах 9.2.2.1.1-9.2.2.1.9, 9.2.2.4 и 9.2.3.1, Регистратор ОБЯЗАН предоставить владельцу зарегистрированного имени возможность выразить свое согласие на публикацию значений элементов данных. Регистратор ОБЯЗАН опубликовать значение элемента данных, для которых владелец зарегистрированного имени предоставил свое согласие.

    9.2.5. Для зарегистрированных имен, использующих аффилированную или аккредитованную службу сохранения конфиденциальности или регистрации через доверенных лиц, Регистратор и Оператор регистратуры ОБЯЗАНЫ опубликовать полные регистрационные данные службы сохранения конфиденциальности или регистрации через доверенных лиц, которые МОГУТ также включать существующую псевдонимизированную электронную почту службы сохранения конфиденциальности или регистрации через доверенных лиц.

    9.2.6. Если владелец зарегистрированного имени согласен на публикацию значения элемента данных «Организация владельца домена», регистратор ОБЯЗАН опубликовать это значение. Если владелец зарегистрированного имени не согласен с его публикацией, Регистратор МОЖЕТ вымарать значение «Организация владельца домена».

  10. Запросы на раскрытие информации

    10.1. Регистратор и оператор регистратуры ОБЯЗАНЫ опубликовать на своей главной странице (общедоступной веб-странице, на которой предлагаются их услуги в области доменных имен) прямую ссылку на страницу с подробным описанием механизма и процесса подачи запросов на раскрытие информации. Механизм и процесс ДОЛЖНЫ определять (a) требуемый формат и содержание запросов, (b) способы предоставления ответа подателю запроса и (c) предполагаемые сроки предоставления ответов.

    10.2. Формат и содержание запросов, требуемых Регистратором и Оператором регистратуры, ДОЛЖНЫ включать, как минимум, следующее:

    10.2.1. Личность подателя запроса, включая следующее:

    10.2.1.1. Контактная информация лица, подающего запрос,

    10.2.1.2. Характер/тип коммерческой организации или физического лица, и

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

    10.2.2. Список значений элементов данных, запрошенных подателем запроса.

    10.2.3. Информация о законных правах подателя запроса, а также конкретное обоснование и причина запроса.

    10.2.4. Подтверждение того, что запрос подается добросовестно.

    10.2.5. Согласие подателя запроса на законную обработку любых значений элементов данных, полученных в ответ на запрос.

    10.3. Регистратор и Оператор регистратуры ОБЯЗАНЫ отвечать на запросы на раскрытие информации, которые соответствуют требуемым форматам.

    10.4. Регистратор и Оператор регистратуры ОБЯЗАНЫ рассматривать каждый правильно оформленный запрос на раскрытие информации по существу, учитывая конкретное обоснование и базу для каждого запроса.

    10.5. Регистратор и Оператор регистратуры ОБЯЗАНЫ подтвердить получение запроса на раскрытие информации, который соответствует их требуемым форматам, без неоправданной задержки, но не более чем через два (2) рабочих дня после получения, и ОБЯЗАНЫ ответить без неоправданной задержки, но не более чем через тридцать (30) календарных дней после подтверждения, кроме исключительных обстоятельств.

    10.6. Ответы на запросы о раскрытии информации ДОЛЖНЫ:

    10.6.1. Содержать запрашиваемые данные; или

    10.6.2. Содержать обоснование того, почему Оператор регистратуры или Регистратор не может предоставить запрошенные данные (полностью или частично), с указанием конкретной причины (причин) отказа, включая четкое объяснение того, как он пришел к своему решению, достаточное для объективного понимания подателем запроса причин такого решения. Это включает анализ и объяснение того, как основные права и свободы субъекта данных были сопоставлены с законными интересами запрашивающей стороны (если применимо).

    10.7. Оператор регистратуры или Регистратор МОЖЕТ предпринять корректирующие действия для исключения неправомерных запросов/заявителей. Корректирующие действия МОГУТ включать отклонение повторяющихся или неполных запросов, требование дополнительной информации по умолчанию для злоупотребляющих запросами, а также другие меры, которые он сочтет необходимыми. Принятые меры по исправлению ситуации ДОЛЖНЫ быть доведены до сведения Подателя запроса.

  11. Журналы событий

    11.1. Если Регистратор применяет требования, указанные в разделе 9.2.3, Регистратор:

    11.1.1. ОБЯЗАН вести журналы событий, подтверждающие факт пересылки сообщения от подателя запроса на адрес электронной почты владельца зарегистрированного имени. Файлы журнала НЕ ДОЛЖНЫ содержать информацию о происхождении, получателе, содержании сообщения или какие-либо персональные данные.

    11.1.2. МОЖЕТ вести журналы событий, подтверждающие факт пересылки сообщения от подателя запроса на адрес электронной почты технической службы. Файлы журнала НЕ ДОЛЖНЫ содержать информацию о происхождении, получателе, содержании сообщения или какие-либо персональные данные.

    11.1.3. ОБЯЗАН предоставлять журналы событий, связанные с передачей сообщений на электронную почту владельца зарегистрированного имени, по запросу корпорации ICANN в целях соблюдения требований. Ничто в этом положении не должно быть истолковано как препятствующее Регистратору принимать разумные и надлежащие меры для предотвращения злоупотребления процессом контактирования с Регистратором.

    11.2. Оператор регистратуры и Регистратор ОБЯЗАНЫ вести журналы запросов, подтверждений и ответов на запросы о раскрытии информации в соответствии со стандартной практикой ведения записей, чтобы их можно было получить при необходимости, в том числе, среди прочего, для целей аудита со стороны корпорации ICANN.

  12. Хранение регистрационных данных

    Регистратор ОБЯЗАН хранить элементы данных, необходимые для целей Политики разрешения споров при изменении регистраторов, не менее пятнадцати (15) месяцев после окончания спонсирования Регистратором регистрации или передачи регистрации между владельцами домена (смены владельца домена).

Дополнение I

Реализация WHOIS (доступная через порт 43) и веб-службы каталогов Whois ДОЛЖНА соответствовать требованиям:

  1. Для элементов данных, для которых не было собрано, сгенерировано или передано никаких данных о значении, (a) ключ (т. е. строка слева от двоеточия) ДОЛЖЕН быть показан без информации в разделе значения (т. е. справа от двоеточия) поля; или (b) ни ключ, ни значение НЕ ДОЛЖНЫ быть показаны.
  2. Для элементов данных, содержащих данные о значении и соответствующих требованиям раздела 9.2.2 настоящей Политики, раздел значения (т. е. справа от двоеточия) ДОЛЖНА быть заменена на строку «ВЫМАРАНО».

Примечание: данное Дополнение I применяется к каждому Регистратору и Оператору регистратуры, предоставляющему услуги WHOIS (доступные через порт 43) или веб-службы каталогов Whois.

Дополнение II

Для существующих регистраций доменных имен с датами создания до даты вступления в силу настоящей Политики:

  1. Регистратор ОБЯЗАН связаться с владельцами зарегистрированных имен, которые ввели значение для элемента данных «Организация владельца домена», и (a) запросить у владельца зарегистрированного имени проверку и подтверждение правильности значения; и (b) подтвердить, согласен ли владелец зарегистрированного имени на публикацию значения «Организация владельца домена».
  2. Если Владелец зарегистрированного имени подтверждает или исправляет значение «Организация владельца домена» и соглашается на его публикацию, Регистратор ОБЯЗАН (a) уведомить Владельца зарегистрированного имени о том, что значение «Организация владельца домена» будет рассматриваться как неперсональные данные и будет опубликовано до даты вступления в силу настоящей Политики, и (b) опубликовать значение «Организация владельца домена», как описано в разделе 9.1.3, до даты вступления в силу настоящей Политики.
  3. Если Владелец зарегистрированного имени отказывается от публикации значения «Организация владельца домена» или не отвечает на запрос, Регистратор, как описано в разделе 9.2.6, МОЖЕТ изменить значение «Организация владельца домена» (как определено в разделе 9.2.2) или МОЖЕТ удалить значение «Организация владельца домена», которое было зафиксировано до даты вступления в силу настоящей Политики. Перед удалением значения «Организация владельца домена» Регистратор ОБЯЗАН убедиться, что значение для обязательного элемента данных «Владелец зарегистрированного имени» в Разделе 6.1.9 было зафиксировано.

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

  1. Обработка регистрационных данных:

    1. Ничто в настоящей Политике не запрещает Оператору регистратуры или Регистратору обрабатывать данные для других целей, выходящих за рамки настоящей Политики. Например,
      1. Сбор информации о кредитной карте с целью обработки платежа за регистрацию доменного имени.
      2. Сбор или генерация дополнительных элементов данных для создания контакта, например: <contact:id>, <contact:authInfo>; или город контактного лица по техническим вопросам (<contact:city>) и его страна (<contact:cc>).
      3. Если Регистратор собирает дополнительные контактные данные, он может опубликовать соответствующие контактные данные в RDDS. Например, если Регистратор собирает данные контактного лица владельца зарегистрированного имени по техническим вопросам в соответствии с разделом 6.2 и вымарывает значения элементов данных, перечисленных в разделах 9.2.2.1.10 - 9.2.2.1.12, регистратор МОЖЕТ предоставить соответствующему контактному лицу возможность дать согласие на публикацию значений элементов данных. Регистратор МОЖЕТ опубликовать значение элемента данных, для которого соответствующий контакт предоставил свое Согласие.
  2. Передача регистрационных данных

    1. Ничто в настоящей Политике не препятствует Регистратору или Оператору регистратуры передавать дополнительные элементы данных провайдеру услуг временного депонирования данных (например, для предоставления Услуг регистратуры, как определено в Соглашении об администрировании домена верхнего уровня).
    2. Ничто в настоящей Политике не препятствует Оператору регистратуры требовать от Регистратора передачи дополнительных значений элементов данных при наличии законных оснований, если такие основания требуются в соответствии с применимым законодательством.
    3. Если для передачи данных от Регистратора к Оператору регистратуры в соответствии с разделом 7 требуется правовая основа, определение правовой основы будет осуществляться сторонами передачи. Наличие правовой основы не определяется корпорацией ICANN и не подлежит принудительному исполнению. В случае, если Оператор регистратуры и Регистратор докажут наличие правовой основы, и Оператор регистратуры и Регистратор заключили соглашение о защите данных, которое распространяется на передаваемые данные, корпорация ICANN сможет обеспечить соблюдение требований по передаче в соответствии с разделом 7.
    4. Оператор регистратуры и Регистратор не обязаны устанавливать правовые основания для обработки Персональных данных, включая передачу от Регистратора к Оператору регистратуры, если это не требуется в соответствии с действующим законодательством.
  3. Передача регистрационных данных провайдерам усулг по временному депонированию данных

    Для ясности, согласно соответствующему Соглашению об администрировании домена верхнего уровня, Оператор регистратуры должен депонировать все элементы данных, необходимые для предоставления всех утвержденных им Услуг регистратуры.

  4. Публикация организации владельца домена

    1. Имя Владельца домена будет считаться контактным лицом в организации Владельца домена.
    2. Регистратор может использовать свой собственный способ получения согласия владельца зарегистрированного имени на публикацию значения «Организация владельца домена» и информировать владельца зарегистрированного имени о требованиях, изложенных в разделах 6.6.1 и 6.6.2, например путем предоставления информации, отказа от ответственности или запроса на подтверждение значения «Организация владельца домена» и согласия на его публикацию, с помощью всплывающего окна с рекомендациями, требования отказаться от публикации, выделения параметра «Организация владельца домена» серым цветом, пока владельца домена явно не согласится на публикацию элемента данных (путем установки флажка), и т. д. Эти примеры не являются исчерпывающим списком.
  5. Ответ на обоснованные просьбы о законном раскрытии информации

    При оценке времени ответа Регистратора или Оператора регистратуры на запросы о раскрытии информации корпорация ICANN может учитывать: количество полученных запросов; количество доменных имен под управлением; среднее время ответа; количество отклоненных запросов.

  6. Хранение регистрационных данных

    1. Ничто в настоящей политике не запрещает Регистратору и Оператору регистратуры устанавливать сроки хранения данных, если этого требует закон, судебное разбирательство или другое соответствующее правовое основание, которое может включать запрос на отказ от обязательств по хранению данных в случае необходимости.
    2. Регистратору не нужно добиваться отказа от обязательств для установления более длительных сроков хранения. Процедура получения разрешения не хранить данные корпорации ICANN позволяет регистратору запрашивать более короткие сроки хранения данных.
    3. Для ясности, требование о хранении данных в Разделе 12 относится только к Регистрационным данным (как определено в настоящей Политике) и не препятствует Подателям запросов, включая отдел ICANN по контролю исполнения договорных обязательств, запрашивать раскрытие этих сохраненных элементов данных для целей, отличных от Политики разрешения споров при изменении регистраторов (TDRP).
  7. Аффилированные и аккредитованные сервисы сохранения конфиденциальности и регистрации через доверенных лиц

    Определение понятия «аффилированный» дано в разделе 1.3 Соглашения об аккредитации регистраторов и более подробно описано в разделе 1.7 Соглашения об аккредитации регистраторов. Аккредитованные поставщики услуг сохранения конфиденциальности и регистрации через доверенных лиц, если таковые появятся, будут подчиняться этому требованию, начиная с даты вступления в силу Политики аккредитации услуг сохранения конфиденциальности и регистрации через доверенных лиц.

  8. Дата создания

    «Дата создания» для целей данной политики означает момент времени, когда в базе данных регистратуры произошло создание доменного объекта.

  9. Дата обновления

    Для Регистратора «Дата обновления» для целей данной политики означает последнее обновление любого из элементов данных, перечисленных в разделе 7, которое произошло в базе данных регистратора или базе данных регистратуры.

Историческая справка

17 мая 2018 года Правление ICANN приняло Временную спецификацию для регистрационных данных в gTLD.. Временная спецификация изменила существующие требования в соглашениях об аккредитации регистраторов и соглашениях об администрировании домена верхнего уровня, чтобы соответствовать Общим положениям о защите данных (GDPR) Европейского Союза, обеспечить постоянную доступность услуги WHOIS в максимально возможной степени и другую обработку регистрационных данных gTLD в соответствии с требованиями и избежать фрагментации WHOIS. В соответствии с Уставом ICANN и спецификациями Согласованных политик и Временных политик в Соглашении об администрировании домена верхнего уровня (RA) и Соглашении между регистратурами и регистраторами (RAA), Временная спецификация может действовать только в течение одного года с даты вступления в силу 25 мая 2018 года.

19 июля 2018 года Совет организации по поддержке родовых имен (GNSO) инициировал ускоренный процесс разработки политики (EPDP), который должен быть разработан в два этапа, и назначил команду EPDP по временной спецификации для регистрационных данных в gTLD. В ходе фазы 1 Группе по EPDP было поручено определить, должна ли Временная спецификация для регистрационных данных в gTLD стать частью согласованной политики ICANN в своем нынешнем виде или с изменениями. Кроме того, устав предписывал, что результат должен соответствовать GDPR и принимать во внимание другие соответствующие законы о конфиденциальности и защите данных. Целью фазы 2 устава группы EPDP была оценка системы обеспечения стандартизованного доступа к закрытым регистрационным данным gTLD и их раскрытия, решение вопросов, отмеченных в Приложении к Временной спецификации, и решение других вопросов, отложенных после фазы 1.

21 ноября 2018 года группа по EPDP опубликовала свой первоначальный отчет по Фазе 1 для общественного обсуждения. Первоначальный отчет содержал предварительные рекомендации группы по EPDP и ряд вопросов для общественного обсуждения. Группа по EPDP также рассмотрела следующие вопросы и вынесла соответствующие рекомендации: (i) обоснованность, законность и правовая основа целей, изложенных во Временной спецификации, (ii) законность, необходимость и объем (x) сбора регистраторами регистрационных данных и (y) передача данных от регистраторов к регистратурам, как указано во Временной спецификации, и (iii) публикация регистраторами и регистратурами регистрационных данных, как указано во Временной спецификации.

20 февраля 2019 года группа по EPDP опубликовала свой итоговый отчет, который был принят 4 марта 2019 года Советом GNSO. 4 марта 2019 года корпорация ICANN начала период общественного обсуждения итогового отчета. Процедура общественного обсуждения была направлена на получение мнения сообщества до принятия Правлением окончательных рекомендаций по политике GNSO EPDP в отношении временной спецификации для регистрационных данных в gTLD. Резюме и аналитический отчет для общественного обсуждения были опубликованы 23 апреля 2019 года. 15 мая 2019 года Правление постановило принять рекомендации за некоторыми исключениями.

Для начала работы над планом реализации была сформирована группа по реализации согласованной политики. Также была сформирована Группа по проверке выполнения рекомендаций (IRT), состоящая из членов Рабочей группы PDP и заинтересованных членов сообщества, для работы с Группой по реализации согласованной политики в соответствии с Концепцией реализации согласованной политики (CPIF), разработанной корпорацией ICANN и принятой Советом GNSO.

Работая до принятия резолюции Правления, Группа по выполнению рекомендаций разработала концепцию трех этапов реализации политики.

  • Этап 1. Продолжить реализацию мер, соответствующих Временной спецификации для регистрационных данных в gTLD, срок действия которой истекает 25 мая 2019 года. Это временная политика в отношении регистрационных данных, пока постоянная политика будет подготовлена и опубликована на основе рекомендаций.
  • Этап 2. Эта стадия начнется после публикации корпорацией ICANN текста политики в области регистрационных данных как согласованной политики и официального уведомления сторон, связанных договорными обязательствами. На этой стадии договорные стороны могут начать применять временную политику, политику в области регистрационных данных или различные части обеих политик по мере подготовки к дате официального вступления в силу политики в области регистрационных данных.
  • Этап 3. Стороны, связанные договорными обязательствами, должны соблюдать политику в отношении регистрационных данных.

17 мая 2019 года корпорация ICANN опубликовала Временную политику в области регистрационных данных для gTLD в соответствии с резолюцией Правления от 15 мая 2019 года. Временная политика, вступившая в силу 20 мая 2019 года, требует, чтобы стороны, связанные договорными обязательствами, продолжали применять меры, соответствующие Временной спецификации для регистрационных данных в gTLD, срок действия которой истек 25 мая 2019 года.

Группа по EPDP завершила Фазу 2 своей работы и опубликовала итоговый отчет, состоящий из четырех рекомендаций, названных рекомендациями Фазы 2 Приоритета 2 EPDP. 21 июня 2021 года Правление приняло рекомендации 19-22, и выполнение этих рекомендаций было включено в сферу деятельности по применению политики в области регистрационных данных.

24 февраля 2022 года Правление приняло Дополнительную рекомендацию Совета GNSO к Рекомендации 12 EPDP, касающуюся удаления данных в поле «Организация», поскольку она снимает основную озабоченность Правление в связи с потерей важных данных.

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