ERR_NAME_NOT_RESOLVED: что означает эта ошибка и как её устранить

ERR_NAME_NOT_RESOLVED - это одна из самых раздражающих ошибок браузера, потому что она выглядит как будто сайт умер, хотя на самом деле сервер может быть живее всех живых. Вы запускаете проект, переносите домен на новый VPS, выкатываете Ingress в Kubernetes, подключаете CDN или просто хотите зайти на админку, как внезапно вместо страницы получаете ответ, что это доменное имя не определено.

Эта ошибка почти всегда про DNS, а DNS - штука коварная, так как по своей архитектуре она имеет распределенную природу, она кэшируемая, а также система доменных имён зависит от кучи промежуточных узлов. Поэтому у одного пользователя сайт может открываться, у другого - нет, а у третьего вообще браузер отдаёт ошибку ERR_NAME_NOT_RESOLVED.

В данной статье мы попроуем разобраться, что именно приводит к появлению данной ошибки, как быстро понять, где именно проблема, у вас или в зоне домена, как диагностировать NXDOMAIN/SERVFAIL и что делать в разных сценариях - от банальной очистки кэша до проверки делегирования вашего домена.

 

 

 

 

Суть ошибки ERR_NAME_NOT_RESOLVED

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

DNS (Domain Name System) - это сервис, который переводит понятные человеку доменные имена в IP-адреса, понятные сети. Браузер не умеет переходить на домен сам по себе, он всегда подключается к конкретному IP-адресу. Поэтому, когда вы вводите в адресной строке браузера example.com, сначала происходит DNS-запрос - то есть поиск ответа на вопрос, какому IP-адресу соответствует это доменное имя. Обычно этот ответ берётся из кэша (браузера/операционной системы/провайдера) или запрашивается у рекурсивного DNS-сервера, который при необходимости переправляет запрос до авторитетных DNS-серверов домена и получает A/AAAA/CNAME-записи. Упрощенно, цепочку резолва можно представить такими шагами:

1. Вы вводите в браузере example.com;
2. Браузер проверяет свой кэш - нет ли уже сохранённого IP;
3. Если записи нет, запрос передаётся операционной системе и её локальному резолверу;
4. При отсутствии ответа локально запрос уходит на рекурсивный DNS-сервер (провайдера, корпоративный или публичный - 8.8.8.8 / 1.1.1.1);
5. Рекурсивный сервер при необходимости проходит иерархию DNS: корневые серверы → сервер зоны (.com) → авторитетные NS домена;
6. Авторитетный сервер возвращает A/AAAA или CNAME-запись с IP-адресом.
7. Браузер получает IP и только после этого устанавливает HTTP/HTTPS-соединение с сервером, именно по IP адресу.

И вот если на любом из этих этапов IP получить не удалось, то браузер показывает ERR_NAME_NOT_RESOLVED, т.е. ваш браузер просто не знает, к какому серверу обращаться.

 

В практическом смысле проблема почти всегда сводится к одному из трёх вариантов:

• Локальная проблема (кэш, DNS провайдера, VPN, файл hosts);
• Проблема DNS-зоны (нет A/CNAME, неправильные NS, домен не делегирован);
• Проблема инфраструктуры DNS (авторитетные NS не отвечают, зона не грузится, SERVFAIL и т.п.).

 

Теперь, когда мы разобрались в самой сути проблемы - давайте подробнее рассмотрим основные причины. 

 

 

 

 

 

Основные причины ERR_NAME_NOT_RESOLVED

Ниже мы разделим причины на две группы и поясним, почему это разделение будет нам полезным.

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

 

Проблемы на стороне пользователя (локальные)

Наиболее яркими признаками, свидетельствующими в пользу того, что проблема возникла на стороне пользователя могут являться:

• Сайт не открывается только у одного человека на его компьтере, а на других - открывается;
• Сайт прекрасно открывается телефоне, но не работает на ноутбуке;
• Сайт не работает только через VPN, а в нормальном режиме работает;
• Проблема появилась внезапно, хотя изменения в домен не вносились.

 

Типичными причами в таких сулчаях могут быть такие:

• DNS-кэш, когда браузер, ОС или домашний роутер запомнили старые ответы, но домен с тех пор был изменен;
• DNS провайдера упал или по какой-то причине режет некоторые домены (возможно блокирвка);
• Включенный VPN подменяет резолвер на свой и тем самым ломает цепочку резолва;
• Для пользователей Linux - когда в файле /etc/hosts присутствуют какие-то устаревшие либо блокирующие записи;
• Корпоративная сеть использует внутренние DNS и не резолвит внешнее (или наоборот).

 

 

Проблемы на стороне домена/хостинга (DNS-зона, делегирование)

Эта группа почти всегда проявляется следующим образом:

• Домен не резолвится у всех или у большинства пользователей;
• Команда dig возвращает NXDOMAIN, SERVFAIL или пустой ANSWER;
• Изменения в доменной зоне производились недавно.

 

Типичными причинами в этом случае могут быть такие:

• Домен не делегирован на правильные NS;
• Для домена вовсе нет A/CNAME записи;
• TTL держит старые ответы и мешает быстрому переключению;
• Истёк срок действия домена или он или попал в блокировку у регистратора;
• Авторитетные NS не отвечают или зона на них не загружена;
• Ошибки синтаксиса или зоны на вашем BIND/PowerDNS.

 

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

 

Таблица быстрой диагностики

Симптом	Что это чаще всего означает	Что сделать первым
Не открывается только у вас	Локальный DNS, кэш, VPN, hosts	Открыть с мобильного интернета, сменить DNS на 1.1.1.1/8.8.8.8
Не открывается у всех	Проблема в DNS-зоне/делегировании	dig example.com и dig NS example.com
Открывается по IP, но не по домену	Нет A-записи или неправильная	Проверить A/CNAME в панели DNS
Работает example.com, но не www	Нет записи для www	Добавить A/CNAME для www
После изменения записей домен то работает, то нет	Идёт пропагация/кэширование	Проверить TTL и терпеливо дождаться
Внутри офиса не работает, дома работает	Корпоративный DNS / фильтрация	Проверить резолверы, split DNS, conditional forwarding

Эта таблица поможет вам быстро определиться в какую сторону копать, что в итоге сэкономит кучу времени.

 

 

 

 

Диагностика ERR_NAME_NOT_RESOLVED

Теперь пора переходить к практике. Ипо сути, для локализации проблемы, вам нужно ответить всего на три вопроса:

• Домен вообще существует в DNS?
• На какие NS он делегирован?
• Возвращается ли A/CNAME?

 

Давайте разберем пару команд и выясним, на что именно смотреть в ответе.

 

Команда dig - проверяем, отдается ли IP, существует ли A/AAAA запись

Синтаксис данной команды предельно простой:

dig example.com

 

На что обращать внимание:

• status: NOERROR - означает, что домен существует, ответ корректный, но A-запись может быть пустой, если не прописаной;
• status: NXDOMAIN - домен вовсе не существует в DNS, он либо не делегирован, либо существует ошибка имени или зоны;
• status: SERVFAIL - сервер не смог обработать запрос. Часто это означает, что проблемы на авторитетных NS, DNSSEC, недоступность.
• Раздел ANSWER SECTION: есть ли A/AAAA-записи.

Если раздел ANSWER пустой - это и есть причина, означающая, что IP не найден.

 

 

2) Команда dig NS - проверяем делегирование

По синтаксису снова никаких сюрпризов:

dig NS example.com

 

В ответе должны быть NS-серверы. Если NS нет или они явно не те, которые вы ожидаете, проблема может быть в делегировании у регистратора этого домена.

Дальше логика простая:

• домен делегирован на NS;
• эти NS должны отвечать;
• на них должна быть зона;
• в зоне должны быть записи.

 

 

Проверяем авторитетный ответ напрямую

Если вы знаете, что NS домена - ns1.example.net, можно спросить его напрямую:

dig @ns1.example.net example.com A 

 

Если публичный dig example.com даёт странные результаты, а прямой запрос к NS показывает другую информацию - это с большой вероятностью значит, что где-то по пути информация либо закешировалась либо по пути есть лишний резолвер.

 

 

Команда dig +trace - где именно сломалось

Набираем в командной строке:

dig +trace example.com

 

Эта команда показывает цепочку от корня до авторитетных NS. Это лучший способ увидеть, где именно возникает проблема, например, делегация не сходится, NS не отвечает или зона не отдаёт запись.

 

 

 

 

DNS-пропагация и TTL: почему у кого-то работает, у кого-то нет

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

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

Существует ещё такой параметр, как TTL (Time To Live) - это время жизни DNS-записи в кэше. По сути, это инструкция резолверу о том, сколько секунд можно хранить тот или иной запрос не перепроверяя.

Если у записи установлен TTL 3600, это означает, что резолвер имеет право хранить полученный IP-адрес в течение одного часа и не запрашивать его заново у авторитетного сервера. Пока TTL не истёк, резолвер будет продолжать отдавать старый ответ, даже в случае, если вы уже поменяли запись.

Так почему-же возникает эффект нестабильной работы? Всё просто. 

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

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

 

Практическое правило для продакшн-проектов

Если вы планируете перенос вашего сайта или смену IP, то не стоит менять запись в последний момент. Гораздо правильнее и безопаснее будет заранее, за 24-48 часов, снизить TTL (например, до 300 секунд). Тогда кэш будет обновляться быстрее, и переключение произойдёт мягче и предсказуемее.

После завершения миграции TTL можно вернуть к более высокому значению, чтобы снизить нагрузку на DNS-серверы.

 

 

 

 

Устранение ошибки ERR_NAME_NOT_RESOLVED

Теперь переходим к конкретике - что делать, если ошибка уже возникла. Напомним, что в этом случае важно действовать не хаотично, а исходя из того, что мы уже изучили: сначала понять, где проблема, а затем устранять её на соответствующем уровне.

Как мы уже определились, все ситуации условно делятся на две группы: проблема локальная (у конкретного пользователя) и проблема на стороне домена или DNS-зоны. Подход в этих случаях будет разным.

 

Если проблема локальная

Локальная проблема означает, что домен в целом существует и у большинства пользователей открывается, но на конкретном компьютере или в конкретной сети возникают проблемы. Это самый частый сценарий после недавних изменений DNS. Что делать в таком случае?

 

Очистка DNS-кэша

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

ipconfig /flushdns 

 

На Linux (systemd-resolved):

sudo resolvectl flush-caches sudo systemctl restart systemd-resolved 

 

Если используется nscd:

sudo systemctl restart nscd 

 

После очистки кэша система перестанет использовать устаревший IP и запросит свежие данные у DNS-сервера.

 

 

Проверка файла hosts

Файл hosts имеет приоритет над DNS, поэтому если в нём есть запись для вашего домена, то система вообще не будет обращаться к внешним DNS-серверам.

На Linux/macOS файл находится по пути:

/etc/hosts 

 

На Windows:

C:\Windows\System32\drivers\etc\hosts 

 

Ищите строки с вашим доменом и проверяйте что там написано. Особенно обратите внимание, если рядом с вашим доменом стоит либо старый IP-адрес, либо локальный 127.0.0.1, либо даже 0.0.0.0. Исправьте эту запись на действительный IP-адрес и перезапустите систему.

 

 

Временная смена DNS-сервера

Иногда проблема не в домене, а в DNS-сервере провайдера. Он может кэшировать устаревшие данные или временно работать нестабильно.

Для проверки можно временно указать другие, публичные DNS-серверы в настроках сети вашего компьютера. Наиболее популярными публичными DNS являются серверы Cloudflare - 1.1.1.1 и 1.0.0.1, а также серверы Google - 8.8.8.8 и 8.8.4.4.

Это ни в коем случае не означает, что публичные DNS чем-то лучше. В некоторых случаях, при падении такого публичного сервера - проблемы наблюдаются в большей части интернета, так как очень многие их используют. Нет, это просто способ проверки, так как если с новым DNS всё работает, значит, проблема была на именно на стороне вашего провайдера.

 

 

Отключение VPN или прокси

VPN часто подменяет DNS-запросы и использует собственные резолверы. Это может приводить к таким проблемам как:

• невозможности разрешить домен;
• использованию устаревшего кэша;
• проблемам с DNSSEC;
• фильтрации определённых зон.

Отключите ваш VPN и если без него сайт открывается, тогда проблема именно в настройках VPN.

 

 

 

Если проблема на стороне домена

Этот сценарий критичнее для владельцев сайтов. Ведь если ваш домен не резолвится глобально, то пользователи просто не могут попасть на проект. Здесь уже нужно проверять инфраструктуру DNS.

 

Проверка статуса домена

Первое, что стоит сделать - это убедиться, что домен активен и срок его регистрации не истёк. Если срок регистрации закончился, то домен может перейти в стадии удержания или блокировки, и резолвинг будет работать нестабильно или вовсе прекратится.

В панели регистратора обычно сразу видно активен ли домен, не заблокирован ли он, а также не отключена ли делегация.

 

 

Проверка делегирования (NS-записей)

Если домен делегирован на неправильные NS-серверы, то любые изменения в правильной панели DNS не будут иметь значения, ведь Интернет будет обращаться туда, куда указал регистратор. Поэтому следующим шагом нужно проверить:

• какие NS указаны у регистратора;
• совпадают ли они с теми, на которых вы действительно управляете зоной.

 

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

 

 

Проверка доступности авторитетных NS

Даже если NS указаны правильно, они должны реально отвечать на запросы. Тогда следует выполнить проверку напрямую:

dig @ns1.example.net example.com A 

 

Если сервер не отвечает или возвращает ошибку, значит проблема в работе DNS-сервера или в конфигурации зоны.

 

 

Проверка наличия и корректности A/CNAME-записей

Самая банальная, но и самая распространённая причина - это когда запись просто отсутствует или указана неверно.

В панели управления вашим доменом проверьте:

• есть ли A-запись для корневого домена (@);
• есть ли запись для www, если используется;
• не указывает ли запись на старый IP;
• не создана ли AAAA-запись (IPv6), если сервер не обслуживает IPv6;
• нет ли конфликтов между CNAME и другими записями.

 

 

И ещё раз напоминаем, что при локализации и устранении проблемы ERR_NAME_NOT_RESOLVED нужно действовать последовательно:

• сначала локальный уровень;
• затем делегирование;
• затем авторитетные NS;
• затем конкретные записи.

Когда вы двигаетесь по этой цепочке, то вероятность быстрого отыскания и исправления причин ошибки увеличивается.

 

 

 

 

Профилактика ошибки ERR_NAME_NOT_RESOLVED

О DNS обычно вспоминают только тогда, когда что-то уже сломалось. Но на практике именно DNS является вашной, даже входной точкой в ваш проект. Можно иметь идеально настроенный сервер, отказоустойчивый кластер и продуманный CI/CD, но если домен перестал резолвиться, то пользователи просто не попадут на сайт.

А чтобы избежать таких ситуаций, достаточно внедрить всего несколько базовых практик.

 

Минимум два авторитетных DNS-сервера

Для публичного домена нормой считается наличие как минимум двух NS-серверов, желательно в разных сетях или локациях. Это не избыточность ради галочки, а защита от ситуации, когда один сервер становится недоступен.

 

 

Мониторинг именно DNS, а не только сайта

Частой ошибкой является мониторинг только HTTP/HTTPS. Но если DNS перестал работать, до веб-сервера дело просто не дойдёт. Поэтому имеет смысл контролировать также:

• резолвится ли A-запись домена;
• резолвится ли www;
• отвечают ли авторитетные NS.

 

Это можно настроить в Zabbix, Prometheus (через blackbox_exporter) или в любом внешнем сервисе мониторинга. Главное - это проверять резолвинг именно снаружи, из интернета, а не из своей-же инфраструктуры.

 

 

Контроль сроков действия домена и авто-продление

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

Минимальный набор мер для исключения этих вариантов - это:

• включить авто-продление;
• указать актуальный email для уведомлений;
• иметь резервный способ оплаты.

 

Это банально, но именно такие мелочи часто становятся причиной реальных простоев.

 

 

Планирование миграций заранее

Если вы планируете смену IP или перенос проекта, не меняйте запись в последний момент. Лучше за 1-2 дня до миграции снизьте TTL (например, до 300 секунд) и тогда кэши будут обновляться быстрее, а переключение пройдёт гораздо спокойнее.

После стабилизации можно вернуть TTL к более высокому значению.

 

 

Проверка зоны перед публикацией

Если вы управляете зоной самостоятельно (например, через BIND), полезно проверять её перед перезапуском DNS-сервера:

named-checkzone example.com /etc/bind/zones/db.example.com 

 

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

 

В итоге профилактика DNS - это не про построение сложной архитектуры, а про аккуратность и контроль. Когда зона корректна, серверы резервированы, домен продлён, а резолвинг мониторится, то ERR_NAME_NOT_RESOLVED становится редким исключением, а не регулярной головной болью.

 

 

 

 

FAQ

 

Почему сайт открывается по IP, но не по домену?

Потому что DNS не возвращает IP. Сервер жив, но домен не указывает на него (нет A-записи или она неправильная).

 

Может ли SSL/сертификат вызвать ERR_NAME_NOT_RESOLVED?

Нет. SSL начинается после получения IP и установки соединения. При ERR_NAME_NOT_RESOLVED до SSL не доходит.

 

Сколько длится DNS-пропагация?

Зависит от TTL и кэшей. Обычно от минут до суток. 48 часов - это верхняя планка для плохо управляемых кэшей, но на практике чаще всего это происходит гораздо быстрее.

 

Может ли Cloudflare/CDN быть причиной?

Да. Особенно при неправильных NS у регистратора, выключенной зоне, конфликте DNSSEC, ошибках в записях внутри CDN.

 

Может ли firewall вызвать ERR_NAME_NOT_RESOLVED?

Нет. Firewall может дать timeout, connection refused и подобное. ERR_NAME_NOT_RESOLVED возникает раньше - когда IP ещё не получен.

 

 

 

 

 

Выводы

Ошибка ERR_NAME_NOT_RESOLVED - это не падение сервера и не проблема браузера. Это остановка на самом первом этапе - этапе DNS-разрешения. Браузер просто не получил IP-адрес и поэтому не может начать соединение.

В большинстве случаев причина оказывается довольно приземлённой, например отсутствует A-запись, неправильно настроено делегирование, домен истёк или кэш ещё держит старые данные после миграции. Реже бывают более глубинные проблемы, когда не отвечают авторитетные NS, возникает SERVFAIL, конфликтует DNSSEC, некорректно настроен split DNS в корпоративной сети или есть ошибки в CoreDNS внутри Kubernetes.

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