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

Короткий ответ: «DNS-сервер не отвечает» значит, что ваш компьютер отправил запрос на имя DNS-серверу, указанному в настройках сетевого адаптера, и не получил ответа — поэтому не может превратить имя вроде example.com в IP-адрес. Проверьте, что соединение работает без DNS, очистите кеш DNS, укажите в адаптере два рабочих публичных резолвера и только если это не помогло — сбросьте Winsock и стек TCP/IP. На Windows Server, к которому вы заходите по Remote Desktop, сначала прочитайте предупреждение в разделе «Сброс Winsock»: сброс TCP/IP может удалить статический IP сервера.

Диагностика сети Windows формулирует это так: компьютер «настроен правильно», но «устройство или ресурс (DNS-сервер) не отвечает». nslookup пишет DNS request timed out. и timeout was 2 seconds., а Chrome показывает DNS_PROBE_FINISHED_BAD_CONFIG либо DNS_PROBE_FINISHED_NO_INTERNET, если не может достучаться ни до одного резолвера вообще. Все три описывают одно и то же: сайт, может, в порядке, но сервер, который должен перевести его имя, не отвечает именно вам.

Если Chrome вместо этого показывает DNS_PROBE_FINISHED_NXDOMAIN, какой-то DNS-сервер всё же ответил, и дело в конкретном имени, а не в вашем резолвере.

Это DNS или всё соединение целиком?

Четыре команды в PowerShell скажут, какая у вас проблема:

# 1. Уходит ли трафик с машины вообще, без DNS?
ping 1.1.1.1
Test-NetConnection 1.1.1.1 -Port 443        # если ping фильтруется

# 2. Какие DNS-серверы использует Windows?
Get-DnsClientServerAddress | Where-Object ServerAddresses

# 3. Спросить настроенный сервер, затем публичный резолвер напрямую
Resolve-DnsName example.com -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly

• Шаг 1 не проходит: дело не в DNS. У машины нет рабочего маршрута наружу. Проверьте кабель или Wi-Fi, роутер и ipconfig /all на наличие IPv4-адреса и шлюза по умолчанию. Адрес, начинающийся с 169.254., значит, что адаптер вообще не получил адрес по DHCP.
• Публичный резолвер отвечает, а настроенный — нет: проблема в DNS-сервере на вашем адаптере. Это самый частый случай — переходите к Фиксу 1 и 2.
• Оба не отвечают: что-то между вами и любым резолвером блокирует DNS: клиент VPN, защитный пакет, правило файрвола или сеть, которая пускает только свой резолвер. Попробуйте Resolve-DnsName example.com -Server 1.1.1.1 -TcpOnly. Если TCP работает, а обычный (UDP) запрос — нет, значит фильтр режет UDP-порт 53. Переходите к Фиксу 4.

Причины по частоте, с которой они виноваты

Фикс 1: перезагрузить роутер и очистить кеш DNS

Дома DNS-сервером на вашем адаптере обычно выступает сам роутер, который пересылает запросы провайдеру. Когда этот форвардер подвисает, ошибку видят все устройства в доме, а обычный IP-трафик при этом работает. Перезагрузите роутер, подождите, пока он полностью поднимется, и очистите кеш Windows из поднятой с правами строки:

ipconfig /flushdns
Clear-DnsClientCache     # тот же результат средствами PowerShell

Очистка убирает кешированные ответы, включая неудачные запросы, которые Windows запомнила во время сбоя. Заставить замолчавший сервер отвечать она не может — если шаг 3 выше всё ещё не работает, идите дальше. Часто советуют и ipconfig /registerdns — он перерегистрирует имя вашего компьютера в зоне DNS, что важно в сети Active Directory, и ничего не делает для этой ошибки.

Фикс 2: указать адаптеру рабочие DNS-серверы

Замена DNS-серверов адаптера решает большинство случаев. Берите двух разных провайдеров, чтобы сбой одного не положил сразу обоих. В примере — Cloudflare (1.1.1.1) и Quad9 (9.9.9.9), плюс их адреса IPv6; в России привычный вариант — DNS Яндекса, 77.88.8.8 и 77.88.8.1. Запустите PowerShell от имени администратора:

# найдите имя адаптера, который поднят (Ethernet, Wi-Fi, Ethernet 2 ...)
Get-NetAdapter | Where-Object Status -eq 'Up'

# указать DNS-серверы для IPv4 и IPv6
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9','2606:4700:4700::1111','2620:fe::fe')
Clear-DnsClientCache
Resolve-DnsName example.com

# чтобы вернуть всё как было: серверы, которые выдаёт DHCP
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses

Серверы, указанные так, перекрывают всё, что назначает DHCP для этого адаптера. 9.9.9.9 от Quad9 также блокирует домены, которые считает вредоносными; для того же сервиса без фильтра используйте 9.9.9.10 и 2620:fe::10. В графических настройках тот же переключатель — в Параметры → Сеть и Интернет → ваше подключение → Назначение DNS-сервера → Изменить → Вручную в Windows 11, либо ncpa.cpl → адаптер → Свойства → IP версии 4 (TCP/IPv4) в Windows 10 и Windows Server.

Фикс 3: проверить и серверы DNS по IPv6

Get-DnsClientServerAddress показывает по две строки на адаптер — для IPv4 и для IPv6. Роутеры и провайдеры могут выдавать серверы DNS по IPv6, которые не отвечают, а Windows всё равно будет их пробовать. Если строка IPv6 называет адреса, которые не отвечают при проверке командой Resolve-DnsName example.com -Server <адрес>, команда из Фикса 2 их уже заменяет, потому что настраивает оба семейства сразу.

Не отключайте IPv6, чтобы избавиться от проблемы. Microsoft советует не отключать его, потому что часть Windows ожидает, что он есть. Вместо этого замените сломанные серверы.

Фикс 4: клиенты VPN, прокси и защитное ПО

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

Get-DnsClientServerAddress          # ищите адаптер VPN и его серверы
Get-DnsClientNrptPolicy             # правила, отправляющие отдельные имена на конкретные серверы

Вторая команда выводит таблицу политик разрешения имён (NRPT), которую VPN и корпоративные политики используют, чтобы направлять отдельные домены на отдельные серверы. Оставшаяся запись от удалённого VPN может ломать разрешение этих имён. Защитные пакеты с веб-фильтром и некоторые «приватность»-утилиты встраиваются в DNS так же. Приостановите или обновите их для проверки, а если после удаления одной из них сеть осталась сломанной, Фикс 5 убирает оставшиеся следы.

Сети отелей, офисов и учебных заведений часто блокируют DNS ко всему, кроме своего резолвера. В такой сети Фикс 2 только усугубит дело: верните серверы на DHCP через -ResetServerAddresses.

Фикс 5: сбросить Winsock и стек TCP/IP

Если серверы указаны верно, а запросы всё равно не проходят, сбросьте сетевой стек. Откройте командную строку от имени администратора:

ipconfig /all > %USERPROFILE%\ip-before.txt
netsh winsock reset
netsh int ip reset C:\resetlog.txt
ipconfig /flushdns
shutdown /r /t 0

netsh winsock reset пересобирает каталог Winsock и удаляет стороннние слои-провайдеры — те самые хуки, которые ставят VPN и защитное ПО. netsh int ip reset перезаписывает настройки TCP/IP в реестре, что Microsoft описывает как равносильное удалению и переустановке TCP/IP. Обе команды требуют перезагрузки в конце. Первая строка сохраняет текущие настройки в ip-before.txt в вашей папке пользователя, чтобы можно было вернуть их обратно.

На Windows Server VPS через Remote Desktop

Remote Desktop подключается по IP-адресу сервера, так что сбой DNS на сервере сам по себе не закроет вам доступ. Он ломает браузер, Windows Update и всё, что ищет имена. Исправить это можно из самой сессии, если не трогать сеть целиком:

1. 1Узнайте, статический ли адрес

   Выполните ipconfig /all. Если строка DHCP Enabled говорит No, адрес статический. Запишите IPv4-адрес, маску подсети, шлюз по умолчанию и DNS-серверы.

2. 2Меняйте только DNS-серверы

   Set-DnsClientServerAddress из Фикса 2 не прерывает сессию. Перезапуск или отключение адаптера, netsh int ip reset и сброс сети прерывают, поэтому избегайте их по RDP, если нет другого способа зайти.

3. 3Если доступ пропал — используйте консоль

   Откройте консоль VNC в панели VMHeaven. Она показывает экран сервера даже когда его сеть не работает. Войдите, выключите DHCP, если сброс его включил, и верните сохранённые значения с длиной префикса, которая соответствует вашей маске (24 — это 255.255.255.0):

   Set-NetIPInterface -InterfaceAlias 'Ethernet' -AddressFamily IPv4 -Dhcp Disabled
   New-NetIPAddress -InterfaceAlias 'Ethernet' -IPAddress 203.0.113.20 -PrefixLength 24 -DefaultGateway 203.0.113.1
   Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9')

Стоит проверить и две причины, характерные именно для сервера. Если адаптер указывает на 127.0.0.1 или ::1, сервер должен отвечать за DNS сам — обычно потому, что роль DNS-сервера установили для Active Directory. Если эта служба остановлена, любой запрос проваливается: проверьте Get-Service DNS и запустите Start-Service DNS. А если кто-то настроил брандмауэр Windows блокировать исходящий трафик, Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction покажет Block, и DNS нужно разрешающее правило для исходящих UDP и TCP на порту 53.

Если сам Remote Desktop не подключается — это другая проблема, разобранная в «Удалённый рабочий стол не подключается» (англ.) (англ.). У каждого Windows VPS VMHeaven в панели есть консоль VNC, поэтому неудачное изменение сети стоит вам несколько минут, а не сам сервер.

На Mac

Те же решения применимы и на macOS, из Terminal. Сначала посмотрите, какие серверы DNS используются и как называются ваши сетевые службы:

scutil --dns | grep nameserver
networksetup -listallnetworkservices

Затем укажите два публичных резолвера для службы, через которую вы подключены, и очистите кеш. Замените Wi-Fi на имя из списка, например Ethernet:

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 9.9.9.9
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo networksetup -setdnsservers Wi-Fi empty возвращает серверы, которые выдаёт роутер. В настройках системы то же поле — в разделе «Сеть», ваше подключение, Подробнее, DNS.

На Linux-сервере: резолвер не отвечает

Linux сообщает о том же сбое как Temporary failure in name resolution, либо dig выводит communications error to … timed out, а за ним no servers could be reached. Отделите сломанную настройку резолвера от заблокированного трафика DNS:

cat /etc/resolv.conf               # что используют программы; 127.0.0.53 = systemd-resolved
resolvectl status                  # какие DNS-серверы на каком интерфейсе
resolvectl query example.com       # запрос через systemd-resolved
dig @1.1.1.1 example.com +short    # обойти локальный резолвер целиком
sudo ufw status verbose            # по умолчанию должно быть "allow (outgoing)"

Молчащий резолвер выглядит в dig так. Замените 192.0.2.1 на сервер из resolvectl status или /etc/resolv.conf:

dig @192.0.2.1 example.com +tries=1 +time=2; echo "код выхода $?"

;; communications error to 192.0.2.1#53: timed out

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> @192.0.2.1 example.com +tries=1 +time=2
; (1 server found)
;; global options: +cmd
;; no servers could be reached
exit status 9

Код выхода 9 у dig значит «нет ответа от сервера». Имя, которого не существует, заканчивается кодом 0, потому что сервер всё же ответил, пусть и NXDOMAIN, — это и есть граница между этой ошибкой и отсутствующим именем.

Если dig @1.1.1.1 отвечает, а обычный запрос — нет, настроенные серверы неверны или недоступны. В Ubuntu работает systemd-resolved; в чистом Debian его часто нет, и тогда resolvectl отсутствует, а серверы лежат прямо в /etc/resolv.conf. С systemd-resolved drop-in-файл задаёт серверы глобально, не трогая netplan:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNS=1.1.1.1 9.9.9.9\n' | sudo tee /etc/systemd/resolved.conf.d/dns.conf
sudo systemctl restart systemd-resolved
resolvectl flush-caches

Если dig @1.1.1.1 тоже не отвечает, исходящий DNS заблокирован или у сервера вообще нет сети. Политика ufw, запрещающая исходящий трафик, требует sudo ufw allow out 53. Если dig не установлен, поставьте bind9-dnsutils.

Когда не отвечает ваш собственный DNS-сервер

Если вы держите на VPS BIND, Unbound, dnsmasq или PowerDNS, и клиенты сообщают, что он не отвечает, проверьте его снаружи командой dig @203.0.113.10 example.com, затем проверьте на сервере:

sudo ss -lntup 'sport = :53'      # кто слушает порт 53 и на каком адресе
sudo ufw allow 53                  # открывает порт 53 и для TCP, и для UDP
sudo journalctl -u named -n 50     # BIND; для остальных — unbound, dnsmasq или pdns

• Слушает только 127.0.0.1. Укажите публичный адрес в собственной настройке сервера (listen-on в BIND, interface: в Unbound).
• Не запускается с «address already in use». Stub-слушатель systemd-resolved держит порт 53 на 127.0.0.53 и 127.0.0.54. Выключите его и направьте /etc/resolv.conf на файл, где сразу перечислены вышестоящие серверы:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNSStubListener=no\n' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
sudo systemctl restart systemd-resolved
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Закрыт TCP. Большие ответы, в том числе с DNSSEC, повторяются по TCP. Откройте оба протокола на порту 53 — это и делает ufw allow 53.
• Отвечает, но с REFUSED. Это ответ, а не молчание. Авторитетный сервер отказывает в именах, которые он не обслуживает. Если вы хотели резолвер для себя, разрешите только свои адреса (allow-recursion в BIND, access-control в Unbound) и никого больше: открытые резолверы используют для атак усиления DNS.

Если сервер должен отвечать за ваш домен в интернете, он также должен быть указан одним из серверов имён домена у регистратора.

Как не допустить повторения

• Настройте по два резолвера от двух разных провайдеров на каждой машине.
• На серверах задавайте DNS там, где это держит система (адаптер, netplan или drop-in для resolved), а не в генерируемом файле, который перезатрётся.
• Перед любым сбросом сети сохраните вывод ipconfig /all или ip addr и ip route, и убедитесь, что у вас есть доступ к консоли.
• На сервере добавьте периодический запрос в мониторинг, чтобы умерший резолвер показался как алерт, а не как провалившиеся обновления неделю спустя.

Без системы мониторинга справится и строка в cron. Добавьте её через crontab -e:

*/5 * * * * dig example.com +time=2 +tries=2 | grep -q 'status: NOERROR' || logger -t dns-check "lookup of example.com failed"

Она проверяет именно ответ NOERROR, а не код выхода dig, поэтому заодно ловит SERVFAIL, который возвращает systemd-resolved, например когда DNS-сервер вообще не настроен. Сбои попадают в системный лог, где их показывает journalctl -t dns-check.

Удалённый Windows-рабочий стол, который можно починить самому без обращения в поддержку, — это и есть смысл тарифов Windows RDP: доступ администратора, свой IPv4-адрес и консоль в панели для тех моментов, когда RDP уже не хватает.

Частые вопросы