Skip to main content
Resources

О программе соблюдении договорных обязательств по рДВУ

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

Приведенный ниже обзор Программы соблюдения договорных обязательств по рДВУ [PDF, 876 KB] является только примером. Стороны, связанные договорными обязательствами, должны продолжить анализ и обеспечить соответствие со всеми требованиями, определяемыми их соглашениями с ICANN, и с применимыми политиками ICANN.

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

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

По условиям соглашения ICANN не обладает полномочиями предпринимать действия в отношении договорных обязательств против операторов нДВУ.

Сферы соблюдения договорных обязательств

  1. Функциональные и эксплуатационные спецификации

    Функциональные спецификации определяют порядок работы технических систем регистратуры, таких как DNS, EPP и RDDS. Эксплуатационные требования устанавливают стандарты в отношении доступности, перебоев в работе, продолжительности обработки данных и частоты обновления. Для определения соответствия в этих сферах, ICANN осуществляет внутренний технический контроль, где это возможно. Кроме того, в ежемесячных отчетах регистратуры, предоставляемых операторами регистратур, сравниваются требования соглашения об уровне обслуживания с реальными эксплуатационными показателями на отчетный месяц, полученными с помощью средств внутреннего технического контроля.

    Соответствующие положения включают в себя Спецификации 6 и 10 соглашения об администрировании новых рДВУ. Жалобы в отношении соблюдения требований соглашения об уровне обслуживания оператором регистратуры могут подаваться с использованием Формы обращения с жалобой на работу регистратора, которая находится здесь: https://www.icann.org/resources/pages/performance-2013-06-28-en.

  2. Службе каталогов регистрационных данных (Whois) и массовый доступ к службе Whois

    Регистратуры, заключившие соглашения об администрировании новых рДВУ, должны предоставлять общественный доступ к службе Whois через порт 43 и базирующуюся на веб-платформе службу каталогов, содержащую необходимые элементы данных в определенном формате. Они также обязаны еженедельно предоставлять ICANN массовые регистрационные данные (Whois). ICANN проверяет, обеспечивает ли регистратура соответствующий доступ к данным Whois, предоставляет ли она данные Whois в соответствии с требованиями, соблюдает ли она требования в отношении частоты обновления и положения о массовом доступе.

    Соответствующие положения включают в себя Спецификации 4 и 10 соглашения об администрировании новых рДВУ и консультативного комитета ICANN: Пояснения по Соглашению о регистратуре и Соглашение об аккредитации регистратора от 2013 г. (RAA), спецификация на Службу каталогов регистрационных данных (WHOIS).

  3. Депонирование данных

    Все регистратуры должны выбрать одобренного ICANN Агента по депонированию данных (DEA) для предоставления услуг по депонированию данных. Группа контроля соответствия проверяет правильность депонирования данных выполненного DEA, и предоставление регистратурой уведомлений о депонировании в ICANN.

    Соответствующие положения включают в себя Спецификацию 2 соглашения об администрировании новых рДВУ.

  4. Использование данных о регистраторе

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

    Соответствующие положения включают в себя Разделы 2.14 и 2.18 и Спецификацию 9 соглашения об администрировании новых рДВУ.

  5. Равноправный доступ к услугам регистрации и кодекс поведения

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

    Соответствующие положения включают в себя Раздел 2.9а и Спецификации 9 и 13 (где применимо) соглашения об администрировании новых рДВУ. Жалобы в отношении соблюдения кодекса поведения могут подаваться с использованием Формы обращения с претензией в отношении несоблюдения кодекса поведения, которая находится здесь: https://www.icann.org/resources/pages/code-of-conduct-2014-01-29-en.

  6. Ограничения регистрации

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

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

    Соответствующие положения включают в себя Раздел 2.19 и Спецификацию соглашения об администрировании новых рДВУ. Жалобы в отношении несоблюдения оператором регистратуры Спецификации 12 на ограничения регистрации могут подаваться с использованием Формы обращения с жалобой для разрешения споров в отношении ограничений на регистрацию, которая находится здесь: https://www.icann.org/resources/pages/rrdrp-2013-10-31-en.

  7. Службы ранней регистрации и рассмотрения претензий

    Регистратуры, заключившие соглашения об администрировании новых рДВУ, и связанные с ними договорными обязательствами регистраторы, должны работать с Депозитарием товарных знаков (TMCH) для предоставления услуг по ранней регистрации и рассмотрению претензий. Данные услуги представляют собой механизмы защиты прав владельцев товарных знаков, зарегистрировавших свои товарные знаки в ТМСН. Услуги ранней регистрации дают возможность владельцам товарных знаков регистрировать доменные имена, соответствующие их знакам, до того, как эти имена станут доступными для широкой публики. В течение периода рассмотрения претензии регистраторы должны выдавать уведомление о претензии в отношении товарного знака всем, пытающимся зарегистрировать доменное имя, совпадающее с товарным знаком, зарегистрированным в ТМСН. Затем, если уведомленная сторона регистрирует доменное имя, то ТМСН уведомит владельца товарного знака о регистрации.

    ICANN принимает жалобы в отношении нарушений предоставления услуг по рассмотрению претензий, а также услуг по ранней регистрации, после того, как будут исчерпаны возможности решения вопроса посредством опубликованной регистратурой политики разрешения споров в отношении ранней регистрации (SDRP).

    Соответствующие положения включают в себя Спецификацию 7 соглашения об администрировании новых рДВУ и требований механизма защиты прав Депозитария товарных знаков. После исчерпания возможностей SDRP, жалобы могут подаваться с использованием Формы отчета по процессам и процедурам ранней регистрации: https://www.icann.org/resources/pages/sdrp-2013-10-31-en, а жалобы в отношении услуг по рассмотрению претензий оператором регистратуры могут подаваться с использованием Формы рассмотрения претензий https://www.icann.org/resources/pages/claims-2014-01-29-en .

  8. Зарезервированные имена

    Все регистратуры обязаны резервировать имена, указанные в соглашении о реестре. Для определения соответствия ICANN осуществляет внутренний технический контроль и рассматривает претензии от внешних источников. Регистратуры, заключившие соглашения об администрировании новых рДВУ, могут активировать до ста (100) имен (плюс их ИДИ-варианты, когда это применимо), которые необходимы для работы или продвижения рДВУ. Не существует числовых ограничений по количеству имен, которые регистратура может резервировать в рДВУ, если соблюдаются все остальные требования соглашения о регистратуре.

    Соответствующие положения включают в себя Приложение 6 и Спецификацию 5 соглашения об администрировании новых рДВУ. Жалобы в отношении зарегистрированных оператором регистратуры имен или заблокированных доменных имен второго уровня (SLD) могут подаваться с использованием Формы претензии по зарезервированным и доменным именам второго уровня (SLD): https://www.icann.org/resources/pages/reserved-2013-06-28-en.

  9. Конфликт имен

    В зависимости от даты делегирования каждого рДВУ (до, в день или после 18 августа 2014 г. 00:00 UTC), регистратуры, заключившие соглашение об администрировании новых рДВУ, должны: (1) либо заблокировать список доменных имен второго уровня (SLD) для блокировки или выполнения управляемого прерывания (CI) или управляемого прерывания для доменных имен второго уровня с символами обобщения имени как минимум на 90 дней до активации таких имен, или (2) выполнить управляемое прерывание с символами обобщения имен как минимум на 90 дней до активации любого имени ДВУ. ICANN контролирует и отслеживает реализацию контролируемого прерывания по времени в основном посредством использования файлов зоны, передаваемых в ICANN после делегирования. Во время реализации контролируемого прерывания остальные обязательства регистратуры остаются в силе (например, DNSSEC, предоставление услуг RDDS на уровне whois.nic.tld).

    Соответствующие положения включают в себя Спецификацию 6 соглашения об администрировании новых рДВУ, Рамочный план действий в случаях совпадения имен и соответствующие документы.

  10. Доступ третьих сторон к файлам зон

    Все операторы реестра обязаны предоставлять третьим сторонам доступ к своим файлам зон. Соглашение реестра о файлах зон должно быть оформлено в том виде, в котором это указано в соглашении о реестре / спонсорстве, и где это применимо, должно предусматривать использование соглашения в Централизованной службе файлов зоны (CZDS). ICANN будет проверять, не изменил ли реестр это соглашение и не внес ли в него дополнительные условия, путем проверки соглашений о файлах зон реестра и рассмотрения претензий от третьих сторон, использующих CZDS для доступа к файлу зоны.

    Соответствующие положения включают в себя условия CZDS и Спецификацию 4 соглашения об администрировании новых рДВУ. Жалобы в отношении предоставления оператором регистратуры доступа к файлу зоны для третьих сторон могут подаваться с использованием Формы претензии в отношении доступа к файлу зоны: https://www.icann.org/resources/pages/zfa-2013-06-28-en.

  11. Контактные данные для связи по вопросам злоупотреблений

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

    Соответствующие положения включают в себя Спецификацию 6 соглашения об администрировании новых рДВУ. Жалобы в отношении контактных данных для обращения в случае злоупотреблений могут подаваться с использованием Формы обращения с жалобой в отношении контактных данных для обращения в случае злоупотреблений, которая находится здесь: https://www.icann.org/resources/pages/abuse-contact-2014-01-29-en.

  12. Обязательства по соблюдению интересов общественности

    Регистратуры, заключившие соглашения об администрировании новых рДВУ, должны принять на себя определенные обязательные и добровольные (если применимо) обязательства по соблюдению интересов общественности. К обязательным положениям относится включение определенных положений в Соглашение между регистратурами и регистраторами (RRA) и проведение периодических технических анализов. Данные обязательства реализуются посредством Процесса разрешения разногласий по обязательствам соблюдения интересов общественности (ПРРСИО, PICDRP) ICANN контролирует соответствие этим требованиям посредством рассмотрения претензий и анализа внешних ресурсов.

    Соответствующие положения включают в себя Спецификацию 11 соглашения об администрировании новых рДВУ и PICDRP. Жалобы в отношении PICDRP могут подаваться с использованием Формы обращения с претензией в отношении PICDRP, которая находится здесь: https://www.icann.org/resources/pages/picdrp-2013-10-31-en.

  13. Служба быстрой приостановки (URS)

    С помощью процедуры ЕСБП (URS) ICANN предлагает недорогой и более быстрый путь удовлетворения требований правообладателей, столкнувшихся с очевидными случаями нарушения их прав в результате регистраций доменных имен. Роль ICANN заключается в обеспечении соблюдения требований процедуры ЕСБП реестрами, оформленными в виде соглашения об администрировании новых рДВУ, во время и после рассмотрения претензии в отношении ЕСБП провайдером ЕСБП.

    Соответствующие положения включают в себя требования высокого технического уровня ЕСБП к реестрам и регистраторам, Процедуру и правила ЕСБП и Спецификацию 7 соглашения об администрировании новых рДВУ. Жалобы в отношении невыполнения оператором регистратуры решения ЕСБП могут подаваться с использованием Формы ЕСБП, которая находится здесь: https://www.icann.org/resources/pages/urs-2013-10-31-en.

  14. Запрет на использование подстановочных знаков

    Реестрам, оформленным в виде соглашения об администрировании новых рДВУ, запрещается использование ресурсных записей DNS с подстановочными знаками, любых методов синтеза ресурсных записей DNS или использование переадресации на всех уровнях DNS для доменных имен, которые либо не зарегистрированы, или по которым не предоставлены корректные записи NS. При получении запросов о таких именах доменов аутентичные серверы имен должны выводить сообщение: "Name Error" ("Ошибка имени" или NXDOMAIN), RCODE 3, как описано в документе RFC 1035 и связанных документах RFC. Для определения соответствия ICANN осуществляет внутренний технический контроль. Временное освобождение от этого запрета предоставляется на основании оценки факта совпадения имен.

    Соответствующие положения включают в себя Спецификацию 6 соглашения об администрировании новых рДВУ. Жалобы в отношении запрета оператора реестра на использование подстановочных знаков могут подаваться с использованием Формы обращения с жалобой в отношении запрета на использование подстановочных знаков (переадресация домена), которая находится здесь: https://www.icann.org/resources/pages/wildcard-prohibition-2014-01-29-en.

  15. Платежи ICANN

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

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

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