Як виправити "DNS server not responding"

Що означає ця помилка

Кожне з'єднання починається із запиту. Ваш пристрій надсилає ім'я хоста резолверу, зазвичай вашому роутеру, провайдеру чи публічному сервісу на кшталт 1.1.1.1, і чекає на IP-адресу. Якщо відповідь не приходить протягом тайм-ауту, операційна система повторює спробу, пробує вторинний сервер і зрештою здається. Тоді Windows запускає свій засіб усунення несправностей, який повідомляє, що DNS-сервер не відповідає.

Формулювання вказує на сервер, але насправді це твердження про шлях. Будь-яке з цього дає те саме повідомлення: резолвер недоступний, резолвер працює, але недосяжний з вашої мережі, брандмауер відкидає порт 53, адреса, налаштована на вашому адаптері, неправильна, або роутер посередині перестав пересилати запити. Мовчання виглядає однаково в усіх п'яти випадках.

Відрізніть це від сусідніх проблем, перш ніж почати. Резолвер, який відповідає "такого імені немає", дає NXDOMAIN, розглянуто в посібнику DNS_PROBE_FINISHED_NXDOMAIN. Резолвер, який відповідає повільно, але правильно, - це вже зовсім інша проблема, і в неї є свій розділ нижче. Ця помилка - той випадок, коли не приходить нічого.

Чому це трапляється

• Роутер перестав пересилати запити. Побутові роутери запускають невеликий DNS-форвардер, який зависає частіше, ніж решта пристрою, тож мережа виглядає онлайн, а не працюють лише запити на визначення імені.
• Налаштований DNS-сервер неправильний. Статична адреса, що лишилася від старої мережі, або сервер, який вивели з експлуатації.
• У резолвера провайдера збій або він перевантажений і відкидає запити замість відповіді на них.
• Брандмауер чи захисний комплект блокує порт 53. Деякі продукти самі перехоплюють DNS і відмовляють у доступі, коли їхня власна служба не працює.
• VPN підключений наполовину. Тунель нав'язав вашому адаптеру свої внутрішні резолвери, а потім обірвався, залишивши адреси, доступні лише всередині тунелю.
• IPv6 налаштований, але непридатний до використання. Система віддає перевагу IPv6-резолверу, не отримує до нього маршруту й чекає завершення тайм-ауту, перш ніж відкотитися назад.
• Служба Windows DNS Client зупинена або її кеш пошкоджений.
• Шкідливе ПЗ чи небажаний застосунок змінили резолвер на адресу, яку контролюють самі, а вона потім зникає.
• Мережа вимагає входу через captive-портал, який ще не відбувся, тож весь вихідний 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. На сторінці адміністрування встановіть WAN DNS-сервери на публічну пару замість "отримувати автоматично", якщо підозра падає на резолвер провайдера.
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

Відповідь від них, поки ваш власний резолвер мовчить, доводить, що з доменом усе гаразд, а проблема на вашому боці. Мовчання від усіх них переводить увагу на власні nameserver-и домену, які можуть бути недоступні чи недосяжні з частини інтернету.

Досяжність nameserver-а не глобальна. Запустіть перевірку DNS-запиту, щоб надіслати той самий пошук із контрольних точок у різних країнах і порівняти відповіді одна поряд з іншою. Коли деякі локації отримують результат, а інші впираються в тайм-аут, ви дивитеся на проблему маршрутизації чи провайдера, що зачіпає регіон, а не на зламаний запис, і жодна кількість очищення кешу на вашому ноутбуці цього не покаже.

Коли ваш власний nameserver замовкає

Nameserver, що замовкає, кладе сайт так само повністю, як мертвий вебсервер, і робить це, не залишаючи жодного рядка у вашому лозі доступу. Ніхто не звертається до вас, бо просто не може до вас дістатися. HostTracker виконує заплановані перевірки з понад 300 контрольних точок у 158 містах у 13 типах моніторів, тож ім'я, що перестає визначатися в одному регіоні, ловлять тамтешні контрольні точки, а не лист від клієнта. Решта цього розділу - у розділі виправлень, а якщо питання в тому, чи нещодавня зміна DNS уже дійшла до всіх, це як перевірити поширення DNS.