Skip to main content
Resources

Часто задаваемые вопросы: доменные коллизии для ИТ-специалистов

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

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

Риски, последствия и кто может с ними столкнуться

  1. Может ли от доменной коллизии пострадать сеть моей организации/компании? Исследования показали малую вероятность того, что доменные коллизии затронут существенное количество корпоративных сетей или интернет-пользователей. В хорошо организованной среде невелика вероятность даже возникновения доменной коллизии, а вероятность того, что она приведет к материальному ущербу, еще меньше, так как подобные неполадки, скорее всего, будут довольно быстро обнаружены. Однако без надлежащего управления сетью риск все же существует.
  2. Представляют ли доменные коллизии существенную опасность? Проведенное компанией JAS Global Advisors исследование коллизий в системах имен глобальной системы доменных имен Интернета (DNS) показало, что добавление новых доменов верхнего уровня (TLD) не оказывает фундаментального или существенного влияния на риски, связанные с доменными коллизиями. Технические особенности, риски и причины неизбежных коллизий в новых доменах верхнего уровня будут аналогичны таковым у коллизий, которые уже регулярно возникают в остальных частях глобальной системы DNS.

Снижение рисков и устранение проблем

  1. Как системные администраторы могут предотвращать доменные коллизии? В соответствии с рекомендациями, изложенными в документе ICANN Руководство по обнаружению и устранению последствий доменных коллизий для ИТ-специалистов (версия 1.1) [PDF, 476 КБ], всем организациям, которые еще не используют полностью определенные имена доменов (FQDN) из глобальной системы DNS, следует рассмотреть следующую стратегию:
    • Вести мониторинг служб имен, составить список частных доменов верхнего уровня или коротких неопределенных имен, которые используются во внутренней сети организации, и сравнивать этот список со списком строк доменов верхнего уровня, на которые подаются заявки.
    • Разработать план устранения причин утечки имен – например, может понадобиться изменить корень внутреннего пространства имен, чтобы использовать имя, которое было зарегистрировано в глобальной системе DNS, или изменить конфигурацию таким образом, чтобы для затронутых систем использовались полностью определенные имена доменов, или FQDN.
    • Подготовить пользователей к предстоящему изменению того, как можно будет использовать имена, – для этого может понадобиться заранее проинформировать или обучить их.
    • Реализовать план устранения причин потенциальных коллизий.
    • Продолжить мониторинг использования старых внутренних имен, а также новых FQDN-доменов на серверах имен и по всему периметру сети организации, и использовать эти данные для ликвидации причин, которые могут выясниться после начала работы по устранению утечки имен.
  2. Как системным администраторам следует устранять обнаруженные доменные коллизии? При возникновении системных ошибок, вызванных доменными коллизиями, системным администраторам рекомендуется выполнить следующее:
    1. Сообщите о проблеме в ICANN »
      Необходимо сообщать о случаях, в которых есть основания предполагать, что доменные коллизии могут стать причиной явного и значительного ущерба.
    2. Ознакомьтесь с документом Руководство по обнаружению и устранению последствий доменных коллизий для ИТ-специалистов (версия 1.1) [PDF, 476 КБ] и примите меры, описанные в этом руководстве.
    3. Подробнее о доменных коллизиях смотрите по адресу https://www.icann.org/namecollision.
    4. Распространите информацию о вероятности доменной коллизии и способах ее устранения среди своих коллег.

Роль ICANN

  1. Почему ICANN занимается предотвращением доменных коллизий? Возникающие доменные коллизии снова привлекли к себе внимание по той причине, что многие строки новых доменов верхнего уровня, на которые были поданы заявки в рамках программы New gTLD ICANN, совпадают с именами, которые используются в других системах имен, например в частных сетях. Основное внимание в своей работе ICANN уделяет обеспечению безопасности, стабильности и отказоустойчивости Интернета. Большое значение приобрели как определение риска и степени опасности потенциальных доменных коллизий, так и поиск способов снижения такого риска.

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

  2. Что сделала ICANN для решения проблемы доменных коллизий? Для решения проблемы доменных коллизий ICANN приняла ряд мер: поручила подготовить отчет независимых экспертов о мерах по недопущению доменных коллизий, выпустила для ИТ-специалистов по всему миру рекомендации по заблаговременному обнаружению и устранению утечек имен из пространств имен частных сетей в глобальную систему DNS и провела информационную кампанию, призванную привлечь внимание к проблеме возможных доменных коллизий.

    Чтобы оценить и снизить риск доменных коллизий между глобальной системой DNS и другими системами имен, ICANN по решению Правления ICANN от 7 сентября 2024 года1 реализовала рамочную концепцию управления рисками в области доменных коллизий, опираясь на рекомендации, изложенные в отчете по итогам второго исследования2 в рамках Проекта по анализу доменных коллизий.

    Чтобы узнать больше о работе, которую ICANN проделала для решения проблемы доменных коллизий, ознакомьтесь со следующими материалами:

Управляемое прерывание и адрес 127.0.53.53

  1. Что такое управляемое прерывание? Управляемое прерывание – это способ оповещения системных администраторов, осознанно или нечаянно допустивших ошибки в конфигурации своих сетей, о возникновении доменных коллизий, а также способ оказания им помощи в устранении потенциальных последствий.

    Управляемое прерывание используется для обнаружения и перехвата неправильных запросов к системе DNS. При обнаружении неправильного запроса регистратура выполняет управляющую операцию, чтобы предотвратить ущерб и предупредить пользователя о необходимости исправить ошибку. Эта управляющая операция заключается в том, что в ответ на такой запрос DNS выдается специальный IP-адрес 127.0.53.53. Слово «прерывание» используется потому, что обращение к имени, которое ранее, несмотря на неправильный запрос, выглядело работающим, теперь не работает.

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

    • * 3600 IN MX 10 your-dns-needs-immediate-attention.<TLD>.
    • * 3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.<TLD>.
    • * 3600 IN TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
  2. Что означает адрес 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.
  3. Что делать, если в моем системном журнале обнаружен адрес 127.0.53.53 или другой диагностический флаг? При возникновении системных ошибок, вызванных доменными коллизиями, системным администраторам рекомендуется выполнить следующее:
    1. Сообщите о проблеме в ICANN »
      Необходимо сообщать о случаях, в которых есть основания предполагать, что доменные коллизии могут стать причиной явного и значительного ущерба.
    2. Ознакомьтесь с документом Руководство по обнаружению и устранению последствий доменных коллизий для ИТ-специалистов (версия 1.1) [PDF, 476 КБ] и примите меры, описанные в этом руководстве.
    3. Подробнее о доменных коллизиях смотрите по адресу https://www.icann.org/namecollision.
    4. Распространите информацию о вероятности доменной коллизии и способах ее устранения среди своих коллег.

1 См. документ https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-

2 См. документ https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf.

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