Skip to main content
Resources

Часто задаваемые вопросы: Рамочный план действий в случаях доменных коллизий для регистратур (раунд 2012 года)

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

Доменная коллизия | Руководство по определению и минимизации последствий доменных коллизий для ИТ-специалистов | Часто задаваемые вопросы: доменные коллизии для ИТ-специалистов | Минимизации последствий доменных коллизий для новых ccTLD | Часто задаваемые вопросы:Рамочный план действий в случаях доменных коллизий для регистратур | Сообщение о доменной коллизии

Обычная

  1. Что такое доменная коллизия? Доменная коллизия возникает, когда имя ресурса, которое должно быть разрешено в одной системе имен, непреднамеренно разрешается в другой системе имен, что может привести к неожиданному поведению, например, к прерыванию связи или перенаправлению от нужного получателя. В качестве аналогии представьте себе, что зовете «Мэри» в офисе, где работает только одна «Мэри», а затем, что зовете «Мэри» в торговом центре и ожидаете, что откликнется «Мэри из офиса».
  2. Что такое Рамочный план действий в случаях доменных коллизий? Рамочный план действий в случаях доменных коллизий [PDF, 634 КБ] — это набор требований, разработанных для контроля за случаями доменных коллизий между новыми доменами общего пользования верхнего уровня (gTLD) и имеющимися такими же строками, которые находятся в частном использовании. Он был разработан по отзывам из многочисленных источников, включая сообщество ICANN, отчет компании JAS Global Advisors LLC и Консультативный комитет по безопасности и стабильности (SSAC).

  3. Каковы важнейшие характеристики этой инициативы? В важнейшие характеристики входит:

    • Операторы регистратур новых gTLD внедрят управляемое прерывание на продолжительный период не менее 90 дней.
    • ICANN будет следить за внедрением управляемого прерывания каждой регистратурой для обеспечения соблюдения контрактных требований.
    • Возможно применение протоколов устранения доменных коллизий в чрезвычайных ситуациях, когда существует вероятность того, что доменная коллизия несет прямую угрозу человеческой жизни.
    • ICANN имеет возможность реагирования на потенциально опасные ситуации.
  4. Каковы следующие этапы работы операторов регистратур? Для каждого оператора регистратуры ICANN выпустит оценку факта доменной коллизии, предназначенную для информирования регистратуры о требуемых мерах согласно последней версии Рамочного плана действий в случаях доменных коллизий. В оценку будут включены сведения о внедрении управляемого прерывания.

Управляемое прерывание, 127.0.53.53 и символы обобщения имени

  1. Что такое управляемое прерывание? Управляемое прерывание — это способ оповещения системных администраторов, которые настроили свои сети неправильно (преднамеренно или нет), о случае доменной коллизии и помощи в решении возможных проблем.
  2. Как работает управляемое прерывание? Управляемое прерывание — это способ приема неправильных запросов DNS. При обнаружении неправильного запроса регистратура выполняет управляющую операцию, чтобы предотвратить ущерб и предупредить пользователя о необходимости исправить ошибку. Эта управляющая операция заключается в том, что в ответ на такой запрос DNS выдается специальный IP-адрес 127.0.53.53. Слово «прерывание» используется потому, что обращение к имени, которое ранее, несмотря на неправильный запрос, выглядело работающим, теперь не работает.
  3. Как будет внедрено управляемое прерывание? Перед постоянным делегированием новые запрашиваемые строки проходят период временного делегирования, в ходе которого внедряется управляемое прерывание путем внедрения в DNS специального набора ресурсных записей. Эти ресурсные записи выбраны для того, чтобы сообщить системным администраторам, что им необходимо проверить и исправить их системы во избежание вероятных проблем в будущем. Список записей доступен в документе Рамочный план действий в случаях доменных коллизий [PDF, 634 КБ].
  4. Когда начинается 90-дневный период управляемого прерывания? Операторы регистратур могут начать период управляемого прерывания уже 18 августа 2014 года при условии, что они получили свою оценку факта доменной коллизии (ICANN начнет выпускать оценки 4 августа 2014 года).

  5. Где можно отслеживать статус 90-дневного периода управляемого прерывания для данного gTLD? Последние отчеты об управляемом прерывании можно скачать, перейдя по ссылкам ниже:

    • Отчет о gTLD с управляемым прерыванием — в процессе (файл CSV)
    • Отчет о gTLD с управляемым прерыванием — завершен (файл CSV)
  6. Может ли регистратура начать период управляемого прерывания раньше? Внедрение периода управляемого прерывания до 18 августа 2014 года не будет засчитано в ходе 90-дневного управляемого прерывания, обязательного для каждого TLD.
  7. Что означает адрес 127.0.53.53? 127.0.53.53 — это специальный адрес протокола IPv4, который отображается в системных журналах, чтобы предупреждать системных администраторов о возможных проблемах доменных коллизий, давая тем самым возможность оперативно проводить диагностику и устранять источники таких проблем. Номер 53 выбран для указания на проблему, связанную с DNS, для удобства запоминания, поскольку для службы DNS используется сетевой порт 53. О случаях, в которых есть основания предполагать, что доменные коллизии могут стать причиной явного и значительного ущерба, следует сообщать по адресу https://forms.icann.org/en/help/name-collision/report-problems. Дополнительные сведения о доменных коллизиях смотрите по адресу https://www.icann.org/namecollision.
  8. Как насчет управляемого прерывания для адресов IPv6? ICANN будет сотрудничать с Инженерной проектной группой Интернета (IETF) и другими соответствующими техническими сообществами, чтобы создать для интернет-протокола 6-й версии механизм, обеспечивающий сходную функциональность с тем, что используется для интернет-протокола 4-й версии (адрес обратной связи 127.0.53.53).
  9. Почему есть возможность использования символов обобщения имени? Разве они не запрещены? В течение периода временного делегирования для новых запрашиваемых строк запрет на символы обобщения имени не действует. Причиной отмены запрета и использования символов обобщения имени является необходимость опробовать все ситуации очевидных доменных коллизий. Символ обобщения имени в «верхней» части зоны будет соответствовать всем запросам, которые будут отображаться при запуске зоны в работу. Такой подход позволяет использовать все меры для защиты интернет-пользователей, которые в настоящее время направляют в глобальную сеть запросы, обращенные к локальной сети.

Контроль исполнения договорных обязательств

  1. Каким образом ICANN гарантирует выполнение регистратурами контрактных требований? ICANN будет следить за выполнением требований, в первую очередь, за счет использования файлов корневой зоны, которые передаются в ICANN регистратурами новых gTLD при их делегировании (согласно Спецификации 4 Соглашения об администрировании нового gTLD). Соблюдение этого требования, также как и других положений Соглашения об администрировании домена верхнего уровня, обеспечивает отдел по контролю исполнения договорных обязательств ICANN.

Ликвидация опасных ситуаций

  1. Какой вид доменной коллизии требует ликвидации опасной ситуации? Применение протоколов ликвидации опасных ситуаций возможно в тех случаях, когда существует вероятность того, что доменная коллизия имеет сильные негативные последствия для множества заинтересованных сторон интернет-сообщества.
  2. Кто решает, что считается опасной ситуацией? ICANN оценивает потенциальный ущерб в соответствии с Рамочным планом управления рисками в случае доменных коллизий и принимает решение.
  3. Кто будет контролировать и отслеживать запросы на срочную ликвидацию опасной ситуации? ICANN будет выступать в качестве единого контактного лица для запросов и отчетов по опасным ситуациям, координировать коммуникацию и гарантировать принятие целесообразных мер в кратчайшие сроки.
  4. Как подать запрос на ликвидацию опасной ситуации? Запросы на ликвидацию опасной ситуации следует размещать по адресу https://forms.icann.org/en/help/name-collision/report-problems.

Блокировка и альтернативный способ делегирования доменов второго уровня

  1. Как следует поступать с именами в блок-листе для домена второго уровня после получения разрешения на их использование в рамках приоритетной регистрации и сервиса уведомления о регистрации совпадающих доменных имен третьими лицами Депозитария товарных знаков (периода Sunrise and Claims)? Операторы регистратур должны гарантировать, что имена, которые должны быть выведены из их блок-листа для домена второго уровня после 90-дневного периода управляемого прерывания, подпадают под действие соответствующих механизмов защиты прав согласно требованиям Спецификации 7 их Соглашения об администрировании домена верхнего уровня. Дополнительные разъяснения по этому вопросу дает оценка факта доменной коллизии.

    Также, в соответствии с решением Комитета Правления ICANN по Программе New gTLD (NGPC) от 30 июля 2014 года для имен, внесенных в список заблокированных имен отчета регистратуры об альтернативном способе делегирования доменных имен и записанных в Депозитарии товарных знаков, делегирование которых регистратура задержала во время периода ранней регистрации или периода требований, регистратура должна и далее воздерживаться от делегирования имен, в то время как ICANN проконсультируется с сообществом по поводу озвученных проблем в области соответствующих механизмов защиты прав для данной категории имен.

  2. Является ли альтернативный способ делегирования доменных имен все еще актуальным теперь, когда реализован Рамочный план действий в случаях доменных коллизий? Нет. Регистратуры должны активировать имена согласно требованиям Рамочного плана действий в случаях доменных коллизий. TLD, делегированные до 18 августа 2014 года, для которых не активированы доменные имена второго уровня (за исключением nic), будут иметь возможность использовать управляемое прерывание с символами обобщения имени.
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."