--- id: "name-collision" kind: "glossary-term" title: "коллизия имен" language: "ru" category: "Альтернативные системы имен" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/ru/glossariy/kolliziya-imen/" translations: en: "https://tldlog.com/glossary/name-collision/" es: "https://tldlog.com/es/glosario/colision-nombres/" de: "https://tldlog.com/de/glossar/namenskollision/" fr: "https://tldlog.com/fr/glossaire/collision-noms/" it: "https://tldlog.com/it/glossario/collisione-nomi/" pt-BR: "https://tldlog.com/pt/glossario/colisao-nomes/" zh-Hans: "https://tldlog.com/zh/cihui/mingcheng-chongtu/" --- # коллизия имен Проблема, которая возникает, когда имя из частной сети существует и в публичной DNS, из-за чего компьютеры направляются не туда. В раунде 2012 года использовалось контролируемое прерывание, тестовый период, предупреждавший затронутые сети. Для раунда 2026 года Name Collision Risk Management Framework ICANN (система управления риском коллизий имен) предусматривает первичную оценку, временное делегирование и исправления для имен с высоким риском. Коллизия имен возникает, когда имя, предназначенное для одной системы имен, чаще всего для частной сети компании, получает ответ из другой, обычно из публичной DNS. Трафик в этом случае может не дойти до цели или уйти туда, куда никто не планировал. Риск появляется при каждом добавлении в интернет нового имени, поэтому ICANN проверяет на него каждый TLD, на который подана заявка. ## Что такое коллизия имен Руководство для заявителей ICANN 2026 года (AGB) определяет ее как ситуацию, когда имя, которое должно разрешаться в одной системе имен, по ошибке разрешается в другой, что может нарушить или перенаправить связь. Классический случай: пользователь хочет обратиться к ресурсу в частной сети и, сам того не зная, попадает на такое же имя в публичной DNS. Риск касается не только имен верхнего уровня: по словам ICANN, его может создать любой новый gTLD, ccTLD или имя второго уровня. Проект SSAC по анализу коллизий имен (NCAP) указывает, что проблема известна десятилетиями, возможно, уже с конца 1980-х годов. ## Почему это происходит: частные имена и новые TLD Многие организации дали своим внутренним сетям окончание, которого не было в публичной DNS. Запросы к таким именам утекают в публичный корень. Как только та же строка делегируется как новый gTLD, утекающие запросы начинают получать настоящие ответы. Проблему усиливают списки поиска: устройство по очереди добавляет к короткому имени суффиксы из списка, пока один из них не сработает. NCAP насчитывает, возможно, дюжину или больше первопричин. В раунде 2012 года из примерно 1 400 строк, на которые были поданы заявки, три были признаны высокорисковыми: .corp, .home и .mail. В 2014 году ICANN отложила их на неопределенный срок, а 7 сентября 2024 года Правление ICANN отказалось назначить их повторную оценку. ## Зарезервированные имена и имена специального назначения Две отдельные системы не допускают имена в корень. - **IETF** резервирует доменные имена специального назначения по RFC 6761 в реестре, который ведет IANA. Среди записей верхнего уровня: .test, .example, .invalid, .localhost, .local, .onion для сети Tor и .alt для систем имен вне DNS. В реестр внесены и некоторые имена в .arpa, например home.arpa для домашних сетей. Сам домен .arpa является инфраструктурным TLD, которым управляет IANA, а не именем специального назначения в целом. - **ICANN** ведет в AGB список заблокированных имен (Blocked Names). В него входят все имена специального назначения, а также такие строки, как .internal, которую Правление 29 июля 2024 года по рекомендации SSAC навсегда зарезервировало для частного использования. Заявки на заблокированные строки нельзя подать ни в одном раунде. RFC 8244 (октябрь 2017 года) отмечает, что никакой формальный процесс не согласует работу этих двух систем и что ни один из двух органов не может помешать третьей стороне просто начать использовать имя. ## Как ICANN управляет риском коллизий ### Коллизии имен в раунде 2012 года По рамочному документу, утвержденному 30 июля 2014 года, каждая новая регистратура не менее 90 дней непрерывно проводила контролируемое прерывание (controlled interruption). Ее зона отвечала на запросы адресом 127.0.53.53, который не открывает соединения, и текстовой записью «Your DNS configuration needs immediate attention» (конфигурация DNS требует немедленного внимания). Позднее NCAP выявил немного сообщений, и лишь одно из них потребовало действий регистратуры. ### Коллизии имен в раунде 2026 года 7 сентября 2024 года Правление утвердило рамочный документ Name Collision Risk Management, который заменяет документ 2014 года. 1. **Первичная оценка (Initial Assessment).** После String Confirmation Day оценка под надзором Группы технической проверки ICANN (TRT) проверяет каждую строку, в том числе по журналам корневых серверов и резолверов. Ее отчет выносится на публичное обсуждение. 2. **Временное делегирование (Temporary Delegation).** Строки, не признанные высокорисковыми, делегируются на DNS-серверы ICANN для измерения реального трафика на срок не менее 90 и не более 365 дней (по состоянию на октябрь 2026 года). Корневая зона растет не более чем примерно на пять процентов в месяц, сначала это около 75 делегирований в месяц (по состоянию на октябрь 2026 года). Заключение договора откладывается до окончания этого этапа. 3. **Высокорисковые строки.** По состоянию на октябрь 2026 года они вносятся в список Collision String List. В течение 90 дней после такого признания (или после разрешения конкуренции, если на строку претендуют несколько заявителей) заявитель может отозвать заявку с полным возвратом сбора за оценку или подать План смягчения рисков (Mitigation Plan; по запросу срок до 180 дней), меры которого занимают не более двух лет. Сбор за его рассмотрение оценивается в 100 000–150 000 USD. Если план не принят, заявка прекращается; это решение можно оспорить в течение 21 дня. Возврат не распространяется на .corp, .home и .mail. В марте 2026 года после публичного обсуждения ICANN решила не использовать в раунде 2026 года контролируемое прерывание по IPv6, версии 6 интернет-протокола. ICANN считает маловероятным, что коллизии затронут значительное число сетей или пользователей, но риск сохраняется. ## Что следует делать сетевым администраторам Руководство ICANN для ИТ-специалистов рекомендует: - Считать адрес 127.0.53.53 в журнале предупреждением о коллизии. - Везде использовать полные доменные имена (FQDN) и отказаться от списков поиска. - Перенести частные имена в зарегистрированный домен и вести мониторинг, пока старые имена не перестанут использоваться. - При отсутствии зарегистрированного домена использовать только зарезервированные варианты: .internal, home.arpa для домашних сетей или .test для тестирования. - Сообщать ICANN о коллизии, если есть обоснованные основания полагать, что она причиняет очевидный серьезный вред. Пример: в списке поиска ноутбуков компании указан corp.example.com, поэтому ввод слова «intranet» приводит на intranet.corp.example.com, имя, которое контролирует компания. Если бы компания придумала собственное окончание, эти запросы утекали бы в корень, и после того как эта строка стала бы gTLD в режиме контролируемого прерывания, пользователи получали бы вместо нужного адреса 127.0.53.53. ## Источники - [New gTLD Program: 2026 Round Applicant Guidebook, Module 7](https://newgtldprogram-2026-agb.icann.org/en/11-module-7-string-and-application-evaluation-procedures.html) - [Name Collision - ICANN](https://www.icann.org/name-collision) - [Guide to Name Collision Identification and Mitigation for IT Professionals](https://www.icann.org/name-collision/guide-for-it-professionals) - [Special-Use Domain Names (IANA registry)](https://www.iana.org/assignments/special-use-domain-names) ## связанные термины - [Программа новых gTLD](https://tldlog.com/ru/glossariy/programma-novykh-gtld/) - [альтернативный корень](https://tldlog.com/ru/glossariy/alternativnyy-koren/) - [блокчейн-домен](https://tldlog.com/ru/glossariy/blokcheyn-domen/)