DNS-сервер не отвечает: полное руководство по устранению неполадок

Ошибка "DNS server not responding" означает, что операционная система отправила запрос на разрешение имени DNS-резолверу и не получила ответа в течение установленного времени ожидания — в результате браузер так и не получил IP-адрес, необходимый для открытия TCP-соединения. Это приводит к сбою загрузки страницы даже при полностью работоспособном физическом сетевом соединении. Первопричина может находиться в любом звене цепочки разрешения имён: локальный stub-резолвер, рекурсивный резолвер вашего провайдера, вышестоящий авторитативный сервер или неправильно настроенное сетевое устройство между вами и любым из них.

Это руководство охватывает каждый уровень этой цепочки — от перезагрузки роутера за 30 секунд до замены драйвера на низком уровне — с точными командами для Windows, macOS и Linux, а также сравнением публичных резолверов и матрицей принятия решений для быстрой локализации неисправности.

Что происходит при разрешении DNS

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

1. ОС проверяет свой локальный кэш DNS (и файл hosts).
2. Если кэшированной записи нет, stub-резолвер перенаправляет запрос на рекурсивный резолвер, настроенный на сетевом интерфейсе (обычно это ваш роутер или сервер, назначенный провайдером).
3. Рекурсивный резолвер обходит иерархию DNS — корневые серверы, серверы имён TLD, авторитативные серверы имён — и возвращает итоговую запись A или AAAA.
4. ОС кэширует результат на время действия TTL записи и передаёт IP-адрес браузеру.

Ошибка «not responding» обычно возникает на шаге 2 или 3. Stub-резолвер отправил UDP-пакет на порт 53 и получил тишину в ответ. У этой тишины удивительно большое количество причин.

Причины ошибки «DNS server not responding»

Сбои на стороне DNS-резолвера

• Настроенный рекурсивный резолвер временно перегружен или недоступен.
• DNS-инфраструктура вашего провайдера подвергается DDoS-атаке или проходит техническое обслуживание.
• IP-адрес резолвера изменился, но ваше устройство по-прежнему использует старое значение.

Проблемы с локальной сетью и оборудованием

• Ошибки прошивки роутера, нарушающие работу DNS-ретрансляции (характерно для потребительских устройств после длительной работы без перезагрузки).
• Аренда DHCP, передавшая устаревший или недействительный адрес DNS-сервера.
• Неисправный кабель Ethernet или ослабленный сигнал Wi-Fi, вызывающий потерю пакетов именно на UDP-порту 53.

Неправильные настройки на уровне хоста

• Повреждённый или отравленный локальный кэш DNS, содержащий устаревшие отрицательные ответы.
• Вручную введённый адрес DNS, который неверен или больше недоступен.
• Запись в файле hosts, конфликтующая с ожидаемым ответом DNS.

Вмешательство защитного программного обеспечения

• Брандмауэры или средства защиты конечных точек, блокирующие исходящий трафик UDP/TCP на порту 53 или перехватывающие DNS-запросы для проверки с последующим их отбрасыванием.
• VPN-клиенты, перенаправляющие DNS-трафик через туннельный эндпоинт, который в данный момент недоступен.
• Программное обеспечение родительского контроля, работающее как локальный DNS-прокси и завершающее работу без уведомления.

Проблемы с драйверами и на уровне ОС

• Устаревший или повреждённый драйвер NIC, некорректно обрабатывающий UDP-датаграммы.
• Служба DNS Client Windows (Dnscache) в зависшем состоянии.
• Процесс mDNSResponder в macOS, потребивший чрезмерный объём памяти и переставший отвечать.

Пошаговые решения: упорядочены по трудоёмкости и вероятности

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

Шаг 1: Сначала определите масштаб проблемы

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

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Если ping 8.8.8.8 выполняется успешно, а nslookup example.com — нет, проблема однозначно в разрешении DNS. Если ping 8.8.8.8 тоже не работает, проблема глубже — скорее всего, в маршрутизации или физическом подключении — а DNS является симптомом, а не причиной.

Шаг 2: Перезагрузите роутер и модем

Отключение питания очищает внутренний кэш DNS-ретрансляции роутера, сбрасывает аренды DHCP и восстанавливает WAN-соединение с новыми адресами DNS-серверов от провайдера.

1. Отключите кабель питания от модема и роутера.
2. Подождите полные 30 секунд (конденсаторам нужно время для разрядки).
3. Сначала включите модем; дождитесь его полной синхронизации (стабильный индикатор WAN).
4. Затем включите роутер; дождитесь завершения его загрузки.
5. Подключите устройство заново и повторите тест nslookup из шага 1.

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

Шаг 3: Очистите локальный кэш DNS

Устаревшие или повреждённые записи кэша заставляют ОС возвращать неверные результаты или генерировать ошибки поиска ещё до того, как запрос покинет машину.

Windows:

ipconfig /flushdns

Вы должны увидеть: Successfully flushed the DNS Resolver Cache.

macOS (зависит от версии — используйте правильную команду для вашей ОС):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Шаг 4: Перейдите на надёжный публичный DNS-резолвер

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

Cloudflare 1.1.1.1 стабильно показывает наименьшую среднюю глобальную задержку запросов в независимых тестах. Quad9 — лучший выбор, если вы хотите пассивную блокировку доменов с вредоносным ПО без настройки отдельного DNS-фильтра.

Изменение DNS в Windows 10/11:

1. Откройте Параметры > Сеть и Интернет > Изменение параметров адаптера.
2. Щёлкните правой кнопкой мыши на активном адаптере и выберите Свойства.
3. Выберите Протокол Интернета версии 4 (TCP/IPv4) и нажмите Свойства.
4. Выберите Использовать следующие адреса DNS-серверов.
5. Введите выбранные IP-адреса основного и вторичного резолверов.
6. Нажмите ОК, затем выполните ipconfig /flushdns для очистки устаревших записей кэша.

Для сетей IPv6 повторите процедуру для Протокола Интернета версии 6 (TCP/IPv6), используя IPv6-адреса резолвера (например, Cloudflare: 2606:4700:4700::1111 и 2606:4700:4700::1001).

Изменение DNS в macOS:

1. Откройте Системные настройки > Сеть.
2. Выберите активное подключение и нажмите Подробнее.
3. Перейдите на вкладку DNS.
4. Удалите существующие записи кнопкой –, затем добавьте выбранные IP-адреса резолверов кнопкой +.
5. Нажмите ОК и Применить.

Изменение DNS в Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Шаг 5: Перезапустите службу DNS Client (Windows)

Служба DNS Client Windows (Dnscache) кэширует разрешённые имена и управляет stub-резолвером. Если она зависает, все DNS-запросы молча завершаются неудачей.

net stop dnscache
net start dnscache

Альтернативно, через консоль служб: нажмите Win + R, введите services.msc, найдите DNS Client, щёлкните правой кнопкой мыши и выберите Перезапустить. Обратите внимание, что в некоторых сборках Windows 11 опция перезапуска в графическом интерфейсе недоступна — используйте вместо неё метод командной строки.

Шаг 6: Временно отключите брандмауэр или защитное программное обеспечение

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

Брандмауэр Windows Defender (только для временного тестирования):

netsh advfirewall set allprofiles state off

Немедленно включите снова после тестирования:

netsh advfirewall set allprofiles state on

macOS:

Перейдите в Системные настройки > Конфиденциальность и безопасность > Брандмауэр и отключите его для тестирования.

Если отключение брандмауэра решает проблему, не оставляйте его отключённым. Вместо этого откройте редактор правил брандмауэра и найдите правила, блокирующие исходящий трафик на UDP-порту 53 и TCP-порту 53. Добавьте явные разрешающие правила для IP-адресов выбранного DNS-резолвера.

VPN-клиенты заслуживают особого внимания. Многие VPN-приложения устанавливают локальный DNS-прокси на 127.0.0.1:53 и перенаправляют все запросы через туннель. Если VPN-сервер недоступен, каждый DNS-запрос завершается неудачей. Отключите VPN, проверьте DNS, затем подключитесь снова и проверьте настройки утечки DNS в VPN-клиенте.

Шаг 7: Попробуйте другой браузер

Некоторые расширения браузера — особенно блокировщики рекламы, инструменты конфиденциальности и плагины безопасности — перехватывают запросы DNS-over-HTTPS (DoH) или изменяют поведение системного резолвера. Если DNS работает в одном браузере, но не в другом, проблема на уровне расширений, а не ОС.

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

Шаг 8: Обновите или откатите сетевые драйверы

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

Windows — обновление через Диспетчер устройств:

1. Нажмите Win + X и выберите Диспетчер устройств.
2. Разверните раздел Сетевые адаптеры.
3. Щёлкните правой кнопкой мыши на адаптере и выберите Обновить драйвер > Автоматический поиск драйверов.
4. Перезагрузитесь после установки.

Windows — откат недавно обновлённого драйвера:

Если ошибка DNS появилась сразу после обновления Windows, новый драйвер может быть причиной регрессии. В Диспетчере устройств щёлкните правой кнопкой мыши на адаптере, выберите Свойства > Драйвер > Откатить драйвер.

macOS: Драйверы NIC входят в состав macOS. Установите все ожидающие системные обновления через Системные настройки > Основные > Обновление ПО.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Шаг 9: Проверьте физические сетевые соединения

При проводном подключении повреждённый кабель Ethernet вызывает периодическую потерю пакетов, которая непропорционально сильно влияет на UDP-протоколы, такие как DNS (у которого нет встроенной повторной передачи на прикладном уровне).

• Переподключите оба конца кабеля Ethernet.
• Замените кабель на заведомо исправный.
• Попробуйте другой порт на роутере или коммутаторе.
• Проверьте индикаторы подключения NIC — стабильный зелёный или янтарный свет подтверждает физическое соединение; мигающий или отсутствующий свет указывает на проблему первого уровня.

Шаг 10: Запустите средство устранения неполадок сети Windows

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

Перейдите в Параметры > Система > Устранение неполадок > Другие средства устранения неполадок > Подключения к Интернету и запустите мастер. Он попытается выполнить автоматическое исправление и сообщит о найденных проблемах. Хотя он охватывает не все сценарии, это полезная проверка, занимающая менее минуты.

Шаг 11: Проверьте и отредактируйте файл hosts

Повреждённый или злонамеренно изменённый файл hosts может переопределять DNS для конкретных доменов, вызывая сбои разрешения имён, неотличимые от ошибки DNS-сервера.

Windows — откройте с повышенными привилегиями:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Ищите записи, перенаправляющие распространённые домены на 0.0.0.0 или 127.0.0.1. Этот файл изменяют защитное программное обеспечение, блокировщики рекламы и вредоносные программы. Удалите подозрительные записи, сохраните файл и очистите кэш DNS.

Шаг 12: Сброс стека TCP/IP и Winsock (Windows)

Если несколько сетевых компонентов настроены неправильно, полный сброс стека быстрее, чем поиск отдельных настроек:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Перезагрузите компьютер после выполнения всех пяти команд. Это сбрасывает параметры реестра TCP/IP и каталог Winsock до состояния по умолчанию без влияния на драйверы сетевого адаптера.

Шаг 13: Сброс роутера до заводских настроек

Используйте это как крайнюю меру перед обращением к провайдеру. Сброс до заводских настроек стирает всю пользовательскую конфигурацию — имена Wi-Fi сетей, пароли, правила переадресации портов и любые пользовательские настройки DNS — и восстанавливает роутер в исходное состояние.

На большинстве роутеров есть утопленная кнопка сброса. Удерживайте её булавкой 10–15 секунд до цикличного мигания индикаторов состояния. После перезагрузки роутера настройте сеть заново. Если DNS заработал сразу после сброса, причиной была неправильная настройка роутера.

Шаг 14: Обратитесь к провайдеру

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

• Результаты nslookup example.com с использованием как DNS вашего провайдера, так и публичного резолвера, например 8.8.8.8.
• Является ли проблема периодической или постоянной.
• Решает ли проблему переключение на мобильную точку доступа (полный обход провайдера).

Последний тест является окончательной проверкой изоляции провайдера.

Настройка DNS для администраторов серверов

Если вы управляете средой VPS Hosting или выделенным сервером, ошибки DNS приобретают дополнительные измерения. Неправильно настроенный резолвер на сервере влияет на каждое работающее на нём приложение — веб-серверы, доставка почты, менеджеры пакетов и агенты мониторинга — все они зависят от надёжного разрешения имён.

Проверка конфигурации резолвера на серверах Linux:

cat /etc/resolv.conf

Корректный файл должен содержать не менее двух строк nameserver, указывающих на надёжные резолверы:

nameserver 1.1.1.1
nameserver 8.8.8.8

На системах с systemd-resolved файл /etc/resolv.conf является символической ссылкой. Прямое редактирование не имеет эффекта. Используйте вместо этого resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Тестирование задержки разрешения с сервера:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

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

Для серверов под управлением cPanel VPS конфигурация DNS также управляется через страницу Basic cPanel & WHM Setup в WHM. Убедитесь, что указанные там резолверы совпадают с теми, что указаны в /etc/resolv.conf, чтобы избежать проблем с раздельным разрешением имён.

DNS и регистрация доменов: связь с вышестоящим уровнем

Ошибка «DNS server not responding» на вашем собственном домене — а не чужом — часто восходит к конфигурации серверов имён на уровне регистратора. Если вы недавно зарегистрировали домен или изменили серверы имён через регистрацию доменов, распространение занимает до 48 часов. В течение этого времени некоторые резолверы по всему миру всё ещё хранят старые NS-записи.

Используйте инструмент проверки распространения или напрямую запросите несколько географически распределённых резолверов:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Расхождения между ответами резолверов в период распространения — это нормально. Если ответы по-прежнему несовместимы спустя 48 часов, NS-записи у регистратора, скорее всего, настроены неправильно.

Защита DNS: DNSSEC и DNS-over-HTTPS

Стандартные DNS-запросы передаются в открытом виде через UDP-порт 53, что делает их уязвимыми для атак DNS-спуфинга и отравления кэша. Две взаимодополняющие технологии решают эту проблему:

DNSSEC добавляет криптографические подписи к DNS-записям, позволяя резолверам проверять подлинность ответа и отсутствие его подделки. Технология защищает целостность данных, но не шифрует сам запрос.

DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) шифруют весь DNS-запрос, предотвращая перехват и манипуляции на пути передачи. Современные браузеры поддерживают DoH нативно. Чтобы включить его на уровне системы в Windows 11, перейдите в Параметры > Сеть и Интернет > [ваш адаптер] > Назначение DNS-сервера > Изменить и установите шифрование в значение Только зашифрованное (DNS over HTTPS).

Для серверов настройте systemd-resolved для использования DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Если вы используете хостинг электронной почты или управляете собственным почтовым сервером, правильная конфигурация DNS — в частности, записи SPF, DKIM и DMARC — критически важна для доставляемости. Сбои DNS на почтовом сервере не просто нарушают исходящий просмотр веб-страниц; они вызывают отложенную или отклонённую электронную почту и сбои при проверке TLS-сертификатов.

SSL-сертификаты и зависимость от DNS

Выдача и обновление TLS-сертификатов полностью зависят от DNS. Центры сертификации, выполняющие проверку домена (DV) через DNS-01 ACME challenge, должны разрешить TXT-запись _acme-challenge вашего домена. Если DNS неисправен в момент обновления, автоматизированные инструменты, такие как Certbot, завершатся неудачей без уведомления, и ваши SSL-сертификаты истекут — вместе с ними перестанет работать HTTPS.

Настройте мониторинг как работоспособности DNS-разрешения, так и срока действия сертификатов. Простая проверка на основе cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Матрица принятия решений: определение уровня сбоя DNS

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

Технический чек-лист ключевых выводов

• Сначала выполните ping 8.8.8.8. Если это не работает, DNS — не ваша основная проблема — сначала устраните проблемы с маршрутизацией или физическим подключением.
• Всегда очищайте локальный кэш DNS после изменения настроек резолвера; устаревшие записи скроют, сработало ли исправление.
• Переключитесь на Cloudflare 1.1.1.1 или Quad9 9.9.9.9 в качестве первого изменения резолвера — оба быстрее и надёжнее большинства резолверов провайдеров.
• В Windows, если в графическом интерфейсе служб опция перезапуска DNS Client недоступна, используйте net stop dnscache && net start dnscache из командной строки с повышенными привилегиями.
• На серверах Linux никогда не редактируйте /etc/resolv.conf напрямую на системах с systemd-resolved — изменения перезаписываются при перезапуске сети. Используйте resolvectl или nmcli.
• VPN-клиенты — частый скрытый виновник. Всегда проверяйте с отключённым VPN, прежде чем эскалировать проблему.
• Для ваших собственных доменов dig +trace обходит все кэши и показывает именно то, что возвращают авторитативные серверы — используйте это, прежде чем предполагать проблему с резолвером.
• Включите валидацию DNSSEC и DNS-over-TLS/HTTPS на производственных серверах, чтобы устранить целый класс сбоев DNS, основанных на спуфинге.
• На серверах отслеживайте работоспособность DNS-разрешения и срок действия SSL-сертификатов вместе — сбой DNS молча приведёт к сбою обновления сертификата через несколько дней.

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

Почему DNS не работает, хотя у меня есть рабочее интернет-соединение?

Разрешение DNS использует UDP-пакеты на порт 53, что отдельно от TCP-соединений, которые браузер использует для загрузки страниц. Правило брандмауэра, зависший DNS-ретранслятор на роутере или недоступный резолвер могут блокировать порт 53 конкретно, оставляя весь остальной трафик незатронутым. Выполните ping 8.8.8.8 для подтверждения IP-связности, затем nslookup example.com для подтверждения, что DNS является изолированной неисправностью.

Безопасно ли постоянно использовать Google или Cloudflare DNS вместо резолвера провайдера?

Да, для большинства пользователей и сценариев использования. Как Google Public DNS, так и Cloudflare 1.1.1.1 поддерживают валидацию DNSSEC и предлагают более высокие SLA по доступности, чем типичные резолверы провайдеров. Компромисс заключается в том, что ваши DNS-запросы обрабатываются сторонним поставщиком инфраструктуры, а не вашим провайдером. Cloudflare публикует строгую политику отсутствия логирования запросов; Google хранит анонимизированные логи до 48 часов.

В чём разница между очисткой кэша DNS и сменой DNS-сервера?

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

Почему nslookup выполняется успешно, но браузер по-прежнему показывает ошибку DNS?

Браузеры всё чаще используют собственную реализацию DNS-over-HTTPS, которая полностью обходит системный резолвер. Если настроенный DoH-эндпоинт браузера недоступен, он может не работать даже при исправном системном резолвере. Проверьте настройки конфиденциальности или безопасности браузера на наличие опции «Безопасный DNS» или «DNS over HTTPS» и либо отключите её, либо укажите доступный DoH-провайдер.

Как диагностировать проблемы DNS на Linux VPS без графического интерфейса?

Используйте dig, nslookup и resolvectl из командной строки. Выполните dig @1.1.1.1 example.com для тестирования конкретного резолвера напрямую, полностью обходя локальную конфигурацию. Выполните resolvectl status для просмотра текущего резолвера системы и проверки активности DNSSEC. Проверьте /etc/resolv.conf для подтверждения настроенных серверов имён и убедитесь, что файл не является неработающей символической ссылкой с помощью ls -la /etc/resolv.conf.