Как исправить ошибку «DNS-сервер не отвечает»

Что означает эта ошибка

Любое соединение начинается с запроса имени. Устройство отправляет имя хоста резолверу, обычно роутеру, провайдеру или публичному сервису вроде 1.1.1.1, и ждет IP-адрес. Если ответ не приходит в отведенное время, операционная система повторяет запрос, пробует запасной сервер и в итоге сдается. Windows запускает мастер устранения неполадок, и тот сообщает, что DNS-сервер не отвечает.

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

Отделите эту ошибку от соседних до того, как начнете что-то делать. Резолвер, который отвечает «нет такого имени», дает NXDOMAIN, о нем написано в руководстве DNS_PROBE_FINISHED_NXDOMAIN. Резолвер, который отвечает медленно, но правильно, это уже третья история, и ей посвящен раздел ниже. Здесь речь про случай, когда не возвращается ничего.

Почему это происходит

• Роутер перестал пересылать запросы. Домашние роутеры держат небольшой DNS-форвардер, и он подвисает чаще, чем остальная часть устройства: сеть выглядит рабочей, а отваливается только разрешение имен.
• Прописан не тот DNS-сервер. Статический адрес, оставшийся от старой сети, или сервер, который давно вывели из эксплуатации.
• У резолвера провайдера авария или перегрузка, и он отбрасывает запросы вместо того, чтобы на них отвечать.
• Брандмауэр или защитный пакет блокирует порт 53. Некоторые продукты сами перехватывают DNS и закрываются наглухо, когда их собственная служба не запущена.
• VPN подключен наполовину. Туннель прописал на адаптере свои внутренние резолверы, а потом отвалился, и остались адреса, доступные только внутри туннеля.
• IPv6 настроен, но не работает. Система предпочитает резолвер по IPv6, не находит до него маршрута и досиживает таймаут, прежде чем откатиться назад.
• Служба DNS-клиента в Windows остановлена или ее кэш поврежден.
• Вредоносная или нежелательная программа сменила резолвер на подконтрольный ей адрес, который затем пропал.
• Сеть требует входа через captive portal, а вход еще не выполнен, и весь исходящий DNS проглатывается.

Как это починить

Сначала выясните, работает ли сама сеть, и только потом трогайте настройки DNS. Команда ping 1.1.1.1 вообще не использует разрешение имен. Если и она не проходит, у вас проблема со связностью, а не с DNS. Если она проходит, а ping example.com нет, DNS подтвержден как сломанное звено и шаги ниже применимы.

Windows

1. Сбросьте кэш и перезапустите службу клиента:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Посмотрите, что использует адаптер: ipconfig /all | findstr /C:"DNS Servers"
3. Пропишите вместо них публичный резолвер: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Опросите конкретный сервер напрямую: nslookup example.com 1.1.1.1
5. Если ничего не держится, сбросьте стек и перезагрузитесь:

   netsh int ip reset
   netsh winsock reset

6. Снимите галочку IPv6 на адаптере, если рабочего IPv6 на машине нет, и проверьте снова.

macOS

1. Сбросьте кэш: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Прочитайте используемые резолверы: scutil --dns | grep nameserver
3. Замените их: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Вернитесь к тому, что выдает DHCP: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Проверьте состояние и сбросьте кэш: resolvectl status, затем sudo resolvectl flush-caches
2. Опросите один сервер явно, чтобы понять, отвечает ли он вообще: dig @1.1.1.1 example.com +short
3. Меняйте резолвер на самом соединении, а не правкой /etc/resolv.conf, который обычно генерируется:

   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"

4. Перезапустите заглушку резолвера, если она заклинила: sudo systemctl restart systemd-resolved

Роутер

1. Выключите и включите его, дождитесь возврата линка WAN и только потом проверяйте.
2. В админке пропишите в качестве DNS для WAN пару публичных серверов вместо «получать автоматически», если подозрение падает на резолвер провайдера.
3. Обновите прошивку. Ошибки в DNS-форвардере это частая причина, по которой роутер приходится перезагружать раз в несколько недель.
4. Обойдите его для проверки: подключите телефон к мобильной сети и разрешите то же имя. Успех там сужает поиск до вашей сети.

Браузер

1. Chrome, Edge и Firefox умеют отправлять DNS поверх HTTPS собственному провайдеру, независимо от системных настроек. Если браузер не справляется, а dig справляется, выключите защищенный DNS в настройках приватности браузера и проверьте снова.
2. Очистите внутренний кэш Chrome на странице chrome://net-internals/#dns.

Когда запрос медленный, а не сломанный

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

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

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

Проверка снаружи

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

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

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

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

Когда замолкает ваш собственный сервер имен

Замолчавший сервер имен кладет сайт так же полностью, как мертвый веб-сервер, и не оставляет при этом ни строчки в журнале доступа. Никто не напишет вам об этом, потому что до вас никто не может дозвониться. HostTracker выполняет проверки по расписанию из более чем 300 точек проверки в 158 городах и поддерживает 13 типов проверок, так что имя, переставшее разрешаться в одном регионе, поймают тамошние точки, а не письмо от клиента. Остальная часть раздела собрана в кластере починки, а если вопрос в том, дошло ли недавнее изменение DNS до всех, это как проверить распространение DNS.