DNS-сервер не отвечает: что проверить

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

Сообщения «DNS-сервер не отвечает», «Не удаётся найти DNS-адрес» и ERR_NAME_NOT_RESOLVED описывают симптом, а не готовый диагноз. Между браузером и DNS-записью домена находятся локальный кэш, настройки устройства, домашний роутер, VPN, рекурсивный резолвер и authoritative-серверы. Любой из этих участков способен вернуть ошибку или не ответить.

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

Сначала определите область сбоя

Откройте тот же домен в другом браузере на том же устройстве, затем на другом устройстве в той же сети и, наконец, через другую сеть — например, мобильную. Проверяйте именно одно и то же полное имя: www.example.com и example.com могут иметь разные записи и разное поведение.

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

Не используйте доступность адреса 1.1.1.1 через ping как окончательный тест интернета. ICMP может быть отфильтрован, а успешный ping подтверждает только достижимость конкретного адреса. Он ничего не говорит о DNS по UDP, ответах домена или работе HTTPS с нужным именем.

До изменения настроек зафиксируйте три вещи:

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

Как читать результат DNS-запроса

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

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

Тайм-аут тоже не называет виновника. Причиной бывает недоступный сервер, маршрут, VPN, фильтрация или блокировка DNS-трафика по UDP либо TCP на порту 53. Проверка одного TCP-соединения не подтверждает, что обычные UDP-запросы проходят исправно.

Диагностика DNS в Windows

Откройте PowerShell без повышения прав и сначала запросите имя через текущую конфигурацию. Затем повторите запрос через явно выбранный независимый резолвер. Подставьте проблемный домен вместо example.com.

Если первый запрос завершается тайм-аутом, а второй возвращает запись, проблема находится на пути к настроенному резолверу или в нём самом. Проверьте адреса DNS в ipconfig /all, настройки VPN и то, откуда интерфейс получил конфигурацию. Не назначайте публичный DNS навсегда до понимания, не нужен ли сети внутренний резолвер.

Команда Clear-DnsClientCache в PowerShell выполняет ту же задачу, что и ipconfig /flushdns. Очистка полезна после исправления записи или при подозрении на устаревший отрицательный ответ. Если сервер продолжает присылать NXDOMAIN или SERVFAIL, повторный flush ничего не исправит.

Ошибка только в одном браузере требует отдельной проверки его защищённого DNS. Браузер может отправлять запросы не тому серверу, который показан в Windows. Временно отключите эту функцию для теста или выберите режим, использующий системного провайдера, а после сравните результат.

Диагностика DNS в Linux

На системах с systemd-resolved команда resolvectl status показывает глобальные и привязанные к интерфейсам DNS-настройки. Это важно при VPN и нескольких сетевых интерфейсах: запросы для отдельных доменов могут уходить по разным маршрутам.

resolvectl есть не везде. Некоторые дистрибутивы используют другой локальный резолвер или обычный файл resolv.conf без кэширующего сервиса. Если команда не найдена, сначала выясните, кто управляет DNS на системе, а не перезапускайте случайно выбранную службу из чужой инструкции.

Сравните getent и dig. Первый ближе к пути обычного приложения и учитывает системную конфигурацию поиска имён. Второй напрямую формирует DNS-запрос. Разные результаты часто указывают на локальные правила, файл hosts, VPN или особую маршрутизацию запросов.

resolvectl flush-caches очищает только кэши, которыми управляет systemd-resolved. Он не очищает домашний роутер, корпоративный резолвер, DNS провайдера и кэш authoritative-сервера. Не берите успешное выполнение команды за доказательство, что «DNS сброшен везде».

Диагностика DNS в macOS

macOS может держать несколько DNS-конфигураций для разных интерфейсов и доменов. Поэтому строка с одним сервером не всегда описывает реальный маршрут запроса. Начните с scutil –dns: команда показывает активные резолверы и области, к которым они относятся.

У dig на macOS есть важное ограничение: он не повторяет всю нативную маршрутизацию DNS, которой пользуются приложения. Поэтому успешный прямой запрос рядом с неудачным dscacheutil — полезная улика, но не противоречие. Проверяйте системные области в scutil –dns, VPN и настройки конкретного сетевого сервиса.

DNS-серверы меняются в System Settings → Network → нужный сервис → Details → DNS. Сохраните исходные адреса перед тестом. Ручной публичный сервер может обойти неисправный резолвер, но также сломать разрешение внутренних имён или политику корпоративной сети.

Когда помогает смена DNS-сервера

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

Она не исправляет отсутствующую запись, ошибочное делегирование, истёкший домен, недоступные authoritative-серверы или сломанную DNSSEC-цепочку. Несколько публичных резолверов могут одинаково вернуть SERVFAIL именно потому, что корректно отказываются принимать непроверяемые подписанные данные.

Не оставляйте случайный DNS в корпоративной сети без согласования. Внутренние зоны, split DNS, фильтрация и VPN могут зависеть от выданного организацией сервера. Ограничение здесь простое: используйте замену для сравнения, а постоянную конфигурацию выбирайте только после понимания последствий.

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

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

Команда dig example.com NS показывает серверы имён из ответа резолвера. Затем запросите A-запись напрямую у каждого найденного сервера: dig @ns1.example.net example.com A. Если серверы дают разные ответы, не отвечают или возвращают ошибку, проблему должен исправлять оператор DNS-зоны.

dig +trace example.com проходит цепочку делегирования от корня и помогает увидеть, на каком переходе теряется ответ. Но команда требует прямого доступа к DNS и может не работать в сети с фильтрацией. Это инструмент проверки, а не универсальный знак того, что домен настроен неверно.

Для SERVFAIL проверьте соответствие NS у родительской и дочерней зоны, доступность всех authoritative-серверов по UDP и TCP, а также DNSSEC. Если у регистратора опубликована DS-запись, а подписи зоны неверны или устарели, валидирующий резолвер обязан отклонить ответ. Отключать проверку у посетителей вместо исправления зоны — не решение.

Владелец домена также должен проверить срок регистрации и недавно внесённые изменения. При смене NS часть резолверов некоторое время использует старое делегирование. Здесь помогает не очередной flush на ноутбуке, а корректная конфигурация обеих сторон на период перехода.

Короткий план действий

Если после этих шагов область остаётся неясной, передайте администратору время, имя, тип записи, используемый резолвер, полный вывод запроса и сведения о сети. Фраза «DNS не работает» почти ничего не оставляет для анализа; две сопоставимые проверки обычно полезнее десятка перезагрузок.