Jak naprawić błąd DNS server not responding

Co oznacza ten błąd

Każde połączenie zaczyna się od zapytania. Twoje urządzenie wysyła nazwę hosta do resolvera, zwykle Twojego routera, dostawcy internetu albo publicznej usługi takiej jak 1.1.1.1, i czeka na adres IP. Jeśli odpowiedź nie nadejdzie w limicie czasu, system operacyjny ponawia próbę, próbuje serwera zapasowego, a w końcu się poddaje. Windows uruchamia wtedy swoje narzędzie diagnostyczne, które zgłasza, że serwer DNS nie odpowiada.

Treść komunikatu wskazuje na serwer, ale w rzeczywistości mówi o całej trasie. Ten sam komunikat pojawi się w każdym z tych przypadków: resolver nie działa, resolver działa, ale jest nieosiągalny z Twojej sieci, zapora blokuje port 53, adres skonfigurowany na Twojej karcie sieciowej jest błędny, albo router pośrodku przestał przekazywać zapytania. Cisza wygląda identycznie we wszystkich pięciu przypadkach.

Zanim zaczniesz, odróżnij go od sąsiednich problemów. Resolver, który odpowiada "nie ma takiej nazwy", daje NXDOMAIN, opisane w DNS_PROBE_FINISHED_NXDOMAIN. Resolver, który odpowiada wolno, ale poprawnie, to zupełnie inny problem, opisany we własnej sekcji poniżej. Ten błąd to przypadek, gdy nic nie wraca.

Dlaczego tak się dzieje

• Router przestał przekazywać zapytania. Routery konsumenckie uruchamiają mały forwarder DNS, który zawiesza się częściej niż reszta urządzenia, więc sieć wygląda na działającą i zawodzą tylko zapytania o nazwy.
• Skonfigurowany serwer DNS jest zły. Statyczny adres pozostały po starej sieci albo serwer, który został wyłączony z użytku.
• Resolver dostawcy internetu ma awarię albo jest przeciążony i odrzuca zapytania zamiast na nie odpowiadać.
• Zapora sieciowa albo pakiet zabezpieczeń blokuje port 53. Niektóre produkty same przechwytują DNS i zawodzą, gdy ich własna usługa nie działa.
• VPN jest w połowie połączony. Tunel podmienił Ci resolvery wewnętrzne na karcie sieciowej, a potem się rozłączył, zostawiając adresy osiągalne tylko wewnątrz tunelu.
• IPv6 jest skonfigurowane, ale nieużywalne. System preferuje resolver IPv6, nie ma do niego trasy i czeka na przekroczenie limitu czasu, zanim się wycofa.
• Usługa Windows DNS Client jest zatrzymana albo jej pamięć podręczna jest uszkodzona.
• Złośliwe oprogramowanie albo niechciana aplikacja zmieniły resolver na adres, który kontrolują, a który potem przestaje działać.
• Sieć wymaga zalogowania się przez captive portal, które jeszcze nie nastąpiło, więc każde wychodzące zapytanie DNS jest pochłaniane.

Jak to naprawić

Zanim tkniesz ustawienia DNS, ustal, czy sama sieć działa. ping 1.1.1.1 nie używa żadnego rozwiązywania nazw. Jeśli to też zawodzi, masz problem z łącznością, a nie z DNS. Jeśli to się udaje, a ping example.com zawodzi, DNS jest potwierdzonym winowajcą i mają zastosowanie poniższe kroki.

Windows

1. Wyczyść pamięć podręczną i zrestartuj usługę klienta:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Sprawdź, czego używa Twoja karta sieciowa: ipconfig /all | findstr /C:"DNS Servers"
3. Ustaw zamiast tego publiczny resolver: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Przetestuj ten konkretny serwer bezpośrednio: nslookup example.com 1.1.1.1
5. Jeśli nic nie pomaga, zresetuj stos sieciowy, a potem uruchom ponownie komputer:

   netsh int ip reset
   netsh winsock reset

6. Odznacz IPv6 na karcie sieciowej, jeśli komputer nie ma działającego IPv6, a potem przetestuj ponownie.

macOS

1. Wyczyść pamięć podręczną: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Odczytaj używane resolvery: scutil --dns | grep nameserver
3. Zastąp je: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Wróć do tego, co przydziela DHCP: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Sprawdź stan i wyczyść: resolvectl status, potem sudo resolvectl flush-caches
2. Zapytaj jeden serwer wprost, żeby zobaczyć, czy w ogóle odpowiada: dig @1.1.1.1 example.com +short
3. Zmień resolver na poziomie połączenia, zamiast edytować /etc/resolv.conf, który zwykle jest generowany automatycznie:

   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. Zrestartuj resolver zaślepkowy, jeśli się zaciął: sudo systemctl restart systemd-resolved

Router

1. Wyłącz go z prądu i poczekaj, aż łącze WAN wróci, zanim zaczniesz testować.
2. Na stronie administracyjnej ustaw serwery DNS WAN na publiczną parę zamiast "uzyskaj automatycznie", jeśli podejrzewasz resolver dostawcy internetu.
3. Zaktualizuj firmware. Błędy forwardera DNS to częsty powód, dla którego router trzeba restartować co kilka tygodni.
4. Sprawdź, omijając go: podłącz telefon do sieci komórkowej i rozwiąż tę samą nazwę. Sukces zawęża usterkę do Twojej sieci.

Przeglądarka

1. Chrome, Edge i Firefox mogą wysyłać DNS przez HTTPS do własnego dostawcy, niezależnie od ustawień systemowych. Jeśli przeglądarka zawodzi, podczas gdy dig działa, wyłącz bezpieczne DNS w ustawieniach prywatności przeglądarki i przetestuj ponownie.
2. Wyczyść wewnętrzną pamięć podręczną Chrome pod adresem chrome://net-internals/#dns.

Gdy zapytanie jest wolne, a nie zepsute

Nie każda dolegliwość DNS to awaria. Jeśli strony w końcu się wczytują, ale najpierw na sekundę czy dwie zawisają, resolver odpowiada, tylko z opóźnieniem, i powyższe naprawy niewiele zmienią. Zmierz to, zanim zaczniesz zgadywać:

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

Wynik w pojedynczych albo niskich dwucyfrowych milisekundach z rozgrzanej pamięci podręcznej jest normalny. Kilkaset milisekund albo wartość, która mocno się zmienia między uruchomieniami, oznacza, że resolver jest daleko, przeciążony albo przekracza limit czasu na pierwszym serwerze i wraca do drugiego. To inna diagnoza z innymi naprawami, opisana w jak naprawić wolne zapytanie DNS.

Sprawdź to z zewnątrz

Wszystko dotychczas zakładało, że usterka jest blisko Ciebie, co zwykle jest prawdą. Potwierdź to, zanim spędzisz nad tym całe popołudnie. Zapytaj resolver niezwiązany z Twoją siecią, czy nazwa się rozwiązuje:

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

Odpowiedź od nich, gdy Twój własny resolver milczy, dowodzi, że z domeną wszystko w porządku i problem leży po Twojej stronie. Cisza od wszystkich przenosi uwagę na własne serwery nazw domeny, które mogą nie działać albo być nieosiągalne z części internetu.

Osiągalność serwera nazw nie jest globalna. Uruchom sprawdzenie zapytania DNS, aby wysłać to samo zapytanie z punktów kontrolnych w różnych krajach i porównać odpowiedzi obok siebie. Gdy część lokalizacji dostaje wynik, a inne przekraczają limit czasu, masz do czynienia z problemem trasowania albo dostawcy dotykającym regionu, a nie z zepsutym rekordem, i żadne czyszczenie pamięci podręcznej na laptopie tego nie pokaże.

Gdy Twój własny serwer nazw milknie

Serwer nazw, który milknie, wyłącza witrynę równie całkowicie jak martwy serwer WWW, i robi to bez zostawienia choćby jednej linii w Twoim logu dostępu. Nikt się nie odezwie, żeby o tym powiedzieć, bo nikt nie jest w stanie się z Tobą skontaktować. HostTracker uruchamia zaplanowane sprawdzenia z ponad 300 punktów kontrolnych w 158 miastach, w 13 typach monitorów, więc nazwa, która przestaje się rozwiązywać w jednym regionie, zostaje wyłapana przez tamtejsze punkty kontrolne, a nie przez e-mail od klienta. Resztę tej sekcji znajdziesz w grupie poradników "napraw to", a jeśli pytanie brzmi, czy niedawna zmiana DNS dotarła już do wszystkich, odpowiada na nie jak sprawdzić propagację DNS.