Skip to content
EN

ERR_ICANN_NAME_COLLISION

Коротко:

ERR_ICANN_NAME_COLLISION — ICANN-level warning. Ваша internal сеть использует domain (.corp, .home, .lan), который стал public TLD после ICANN gTLD expansion (2013+). Теперь external DNS резолвит ваш internal hostname → confusion. Chrome warnings. Fix: переименовать internal zones под .internal или .arpa (reserved), или явно blacklist.

Ниже: причины, исправление, FAQ.

Проверить SSL своего сайта →

Причины ошибки

  • Internal AD-домен типа .corp — стал public gTLD
  • Старая split-horizon DNS setup с .home, .lan
  • /etc/hosts entries с common names
  • Резолвер пробовал public DNS до internal
  • NetBIOS broadcast names

Пошаговое исправление

  1. Переименуйте internal zone на .internal, .home.arpa (RFC 8375)
  2. Strict DNS suffix order: internal first
  3. Или запрещите resolver для public TLDs на endpoints
  4. Для AD migration — это крупный проект (подготовиться)
  5. Временно: /etc/hosts manual entries для critical hosts

Проверить SSL-сертификат →

Смежные SSL-ошибки

ERR_ICANN_NAME_COLLISION — что это такое?

ERR_ICANN_NAME_COLLISION — это ошибка, возникающая при попытке доступа к домену, который конфликтует с внутренним TLD (top-level domain). Это происходит, когда доменное имя, которое вы пытаетесь использовать, совпадает с зарегистрированным TLD, что может привести к проблемам с разрешением DNS. Для устранения данной проблемы необходимо проверить конфигурацию DNS и убедиться, что используемые домены не конфликтуют с зарегистрированными TLD.

Причины возникновения конфликта ERR_ICANN_NAME_COLLISION

Конфликт ERR_ICANN_NAME_COLLISION чаще всего возникает из-за неправильной настройки DNS или попытки использовать локальные доменные имена в окружениях, где они не зарегистрированы. Например, если вы используете домен example.local в своей локальной сети, но в интернете существует зарегистрированный домен example.com, это может вызвать конфликт. Основные причины:

  • Использование зарезервированных TLD: Некоторые TLD, такие как .local, .test, .example, имеют особые назначения и не должны использоваться для публичных доменов.
  • Ошибки в конфигурации DNS: Неправильные записи DNS могут привести к тому, что запросы будут направляться на неверные адреса.
  • Кэширование DNS: Если кэш DNS содержит устаревшие записи, это может вызвать проблемы с разрешением имен.

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

Практическое решение проблемы ERR_ICANN_NAME_COLLISION

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

1. Проверьте конфигурацию DNS с помощью команды:

dig example.local

Это позволит вам увидеть, какие записи DNS существуют для указанного домена.

2. Если вы видите, что example.local конфликтует с зарегистрированным доменом, измените конфигурацию вашего локального DNS-сервера. Например, если вы используете dnsmasq, добавьте следующие строки в конфигурационный файл:

address=/example.local/192.168.1.1

Это укажет вашему DNS-серверу разрешать example.local на локальный IP-адрес.

3. Очистите кэш DNS на вашем устройстве, чтобы изменения вступили в силу. Для этого используйте команду:

sudo systemd-resolve --flush-caches

4. Проверьте, что ошибка больше не возникает, снова используя команду dig.

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

Введение в проблему ERR_ICANN_NAME_COLLISION

ERR_ICANN_NAME_COLLISION — это ошибка, возникающая, когда браузер не может разрешить доменное имя из-за конфликта с внутренним TLD (Top-Level Domain). Эта проблема чаще всего возникает в корпоративных или локальных сетях, где используются доменные имена, совпадающие с новыми или существующими TLD, зарегистрированными в ICANN.

Как избежать конфликта ERR_ICANN_NAME_COLLISION

Чтобы избежать конфликта ERR_ICANN_NAME_COLLISION, важно следовать нескольким рекомендациям, особенно если вы работаете в сфере веб-разработки или сетевой инфраструктуры. Ниже представлены практические шаги и пример настройки, которые помогут вам минимизировать риск возникновения данной ошибки.

Проверка доменных имен

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

whois example.local

Если доменное имя уже зарегистрировано, рассмотрите возможность выбора альтернативного имени или использования другого внутреннего TLD.

Настройка DNS

Для предотвращения конфликтов важно правильно настроить DNS-сервер. Используйте уникальные внутренние доменные зоны, которые не пересекаются с общедоступными TLD. Например, вместо использования .local, вы можете выбрать .internal или .private.

Пример конфигурации DNS

Вот пример конфигурации для BIND DNS-сервера, который создает внутреннюю зону:

zone "example.internal" IN {
    type master;
    file "/etc/bind/db.example.internal";
};

Использование VPN

Если ваши пользователи подключаются к локальной сети через VPN, убедитесь, что VPN-клиенты правильно настроены для работы с внутренними доменными именами. Это поможет избежать конфликта с внешними TLD.

Мониторинг и аудит

Регулярно проводите аудит используемых доменных имен и их конфигураций. Используйте инструменты мониторинга, такие как enterno.io, для отслеживания состояния ваших доменных имен и выявления потенциальных конфликтов.

Заключение

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

СертификатСрок, издатель, домены (SAN)
ЦепочкаПроверка промежуточных и корневых CA
TLS-протоколВерсия TLS и набор шифров
УязвимостиHeartbleed, POODLE, слабые шифры

Почему нам доверяют

TLS 1.3
поддержка
Полная
цепочка CA
<2с
результат
30/14/7
дней до истечения

Как это работает

1

Введите домен

2

Проверка цепочки TLS

3

Дата истечения и уязвимости

Что проверяет SSL-тест?

SSL/TLS — протокол шифрования, который защищает данные между браузером и сервером. Наш инструмент анализирует сертификат, цепочку доверия, версию TLS и известныеуязвимости.

Детали сертификата

Издатель, срок действия, алгоритм подписи, покрываемые домены (SAN) и тип валидации (DV/OV/EV).

Цепочка доверия

Проверка полной цепочки: от конечного сертификата через промежуточные до корневого CA.

Анализ TLS

Версия протокола (TLS 1.2/1.3), набор шифров, поддержка Perfect Forward Secrecy (PFS).

Оповещения об истечении

Создайте монитор — получайте уведомления в Telegram и email за 30/14/7 дней до истечения.

DV vs OV vs EV сертификаты

DV (Domain Validation)
  • Подтверждение только владения доменом
  • Выдаётся за минуты автоматически
  • Бесплатно через Let's Encrypt
  • Подходит для большинства сайтов
  • Самый распространённый тип
OV / EV
  • Проверка организации (OV) или расширенная проверка (EV)
  • Выдаётся за 1-5 рабочих дней
  • Стоимость от $50 до $500/год
  • Для финансов, e-commerce, госсайтов
  • Повышает доверие пользователей

Кому это нужно

DevOps

мониторинг SSL-сертификатов

Безопасность

аудит TLS-конфигурации

SEO

HTTPS как фактор ранжирования

E-commerce

доверие покупателей

Частые ошибки

Истёкший сертификатБраузеры блокируют сайт с истёкшим SSL. Настройте автопродление или мониторинг.
Неполная цепочка сертификатовБез промежуточного CA некоторые браузеры и боты не смогут верифицировать сертификат.
Mixed content на HTTPS-сайтеHTTP-ресурсы на HTTPS-странице — замок в браузере пропадает, снижается доверие.
Использование TLS 1.0/1.1Устаревшие версии TLS содержат известные уязвимости. Используйте TLS 1.2+ или 1.3.
Несовпадение домена в сертификатеСертификат должен покрывать все домены сайта, включая www и поддомены.

Лучшие практики

Настройте автопродлениеLet's Encrypt + certbot с cron — сертификат обновляется автоматически каждые 60-90 дней.
Включите HSTSЗаголовок Strict-Transport-Security заставляет браузер всегда использовать HTTPS.
Используйте TLS 1.3TLS 1.3 быстрее (1-RTT handshake) и безопаснее — убраны устаревшие шифры.
Мониторьте срок действияСоздайте монитор на Enterno.io — получайте уведомления задолго до истечения.
Проверяйте цепочку после обновленияПосле обновления сертификата убедитесь, что промежуточные сертификаты установлены.

Получите больше с бесплатным аккаунтом

Мониторинг SSL-сертификатов, история проверок и уведомления за 30 дней до истечения.

Зарегистрироваться (FREE)

Больше по теме

Источники

Часто задаваемые вопросы

Какие TLD сейчас "collide"?

.corp, .home, .mail, .office — NOT в публичном use но зарезервированы ICANN. Safer .internal (proposed reserved), .home.arpa, .localhost.

Это security risk?

Да: attacker может register .corp domain, резолвить internal names к malicious IPs, MITM.

Chrome специфично блокирует?

Chrome warn, не block. Но может рассматривать как suspicious для certain workflows.

Reserved TLDs 2026?

.internal (IETF draft), .test, .localhost, .invalid, .example — safe. Any другой — ideally в публичном реестре.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.