Serwer DNS nie odpowiada: Kompletny przewodnik rozwiązywania problemów

Błąd „DNS server not responding” oznacza, że system operacyjny wysłał zapytanie rozwiązywania nazw do resolwera DNS i nie otrzymał odpowiedzi w wyznaczonym czasie — przez co przeglądarka nigdy nie uzyskała adresu IP potrzebnego do nawiązania połączenia TCP. Skutkiem jest brak możliwości załadowania strony, nawet gdy fizyczne łącze sieciowe działa prawidłowo. Przyczyna problemu może leżeć w dowolnym miejscu łańcucha rozwiązywania nazw: w lokalnym resolwerze stub, rekurencyjnym resolwerze dostawcy ISP, nadrzędnym serwerze autorytatywnym lub błędnie skonfigurowanym urządzeniu sieciowym między użytkownikiem a którymkolwiek z nich.

Niniejszy przewodnik omawia każdą warstwę tego łańcucha — od 30-sekundowego restartu routera po wymianę sterownika na niskim poziomie — wraz z dokładnymi poleceniami dla systemów Windows, macOS i Linux, porównaniem publicznych resolwerów oraz macierzą decyzyjną pomagającą szybko zlokalizować usterkę.

Co tak naprawdę dzieje się podczas rozwiązywania nazw DNS

Zanim przystąpisz do naprawy błędu, warto zrozumieć ścieżkę rozwiązywania nazw, aby uniknąć zbędnych działań. Gdy wpisujesz example.com w przeglądarce:

1. System operacyjny sprawdza lokalną pamięć podręczną DNS (oraz plik hosts).
2. Jeśli nie ma zapisanego rekordu, resolwer stub przekazuje zapytanie do resolwera rekurencyjnego skonfigurowanego na interfejsie sieciowym (zazwyczaj router lub serwer przydzielony przez ISP).
3. Resolwer rekurencyjny przechodzi przez hierarchię DNS — serwery główne, serwery nazw TLD, serwery autorytatywne — i zwraca końcowy rekord A lub AAAA.
4. System operacyjny zapisuje wynik w pamięci podręcznej na czas określony przez TTL rekordu i przekazuje adres IP do przeglądarki.

Błąd „not responding” zazwyczaj pojawia się na etapie 2 lub 3. Resolwer stub wysłał pakiet UDP na port 53 i nie otrzymał odpowiedzi. Ta cisza ma zaskakująco wiele przyczyn.

Przyczyny błędu „DNS Server Not Responding”

Awarie po stronie resolwera DNS

• Skonfigurowany resolwer rekurencyjny jest tymczasowo przeciążony lub niedostępny.
• Infrastruktura DNS dostawcy ISP jest atakowana przez DDoS lub poddawana konserwacji.
• Adres IP resolwera uległ zmianie, ale urządzenie nadal przechowuje starą wartość.

Problemy z siecią lokalną i sprzętem

• Błędy w oprogramowaniu routera powodujące uszkodzenie przekazywania DNS (częste w urządzeniach klasy konsumenckiej po długim czasie pracy bez restartu).
• Dzierżawa DHCP, która przekazała nieaktualny lub nieprawidłowy adres serwera DNS.
• Uszkodzony kabel Ethernet lub słaby sygnał Wi-Fi powodujący utratę pakietów, szczególnie na porcie UDP 53.

Błędne konfiguracje na poziomie hosta

• Uszkodzona lub zatruta lokalna pamięć podręczna DNS zawierająca nieaktualne odpowiedzi negatywne.
• Ręcznie wprowadzony adres DNS, który jest błędny lub niedostępny.
• Wpis w pliku hosts kolidujący z oczekiwaną odpowiedzią DNS.

Zakłócenia ze strony oprogramowania zabezpieczającego

• Zapory sieciowe lub narzędzia zabezpieczające punkty końcowe, które blokują wychodzący ruch UDP/TCP na porcie 53 lub przechwytują zapytania DNS w celu inspekcji, a następnie je odrzucają.
• Klienci VPN przekierowujący ruch DNS przez punkt końcowy tunelu, który jest aktualnie niedostępny.
• Oprogramowanie kontroli rodzicielskiej działające jako lokalny serwer proxy DNS, które ulega cichej awarii.

Problemy ze sterownikami i systemem operacyjnym

• Przestarzały lub uszkodzony sterownik karty sieciowej, który nieprawidłowo obsługuje datagramy UDP.
• Usługa DNS Client systemu Windows (Dnscache) w stanie zawieszenia.
• Proces mDNSResponder w systemie macOS, który zużył nadmierną ilość pamięci i przestał odpowiadać.

Rozwiązania krok po kroku: uporządkowane według nakładu pracy i prawdopodobieństwa

Wykonuj kolejne kroki po kolei. Każdy zajmuje mniej niż pięć minut i eliminuje określoną warstwę problemu.

Krok 1: Najpierw sprawdź zakres problemu

Zanim zmienisz jakiekolwiek ustawienia, przeprowadź szybką diagnostykę, aby potwierdzić, że DNS jest rzeczywiście przyczyną awarii, a nie ogólna łączność:

# 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

Jeśli ping 8.8.8.8 działa, ale nslookup example.com nie, problem z rozwiązywaniem nazw DNS jest definitywnie potwierdzony. Jeśli ping 8.8.8.8 również nie działa, problem leży głębiej — prawdopodobnie w routingu lub łączności fizycznej — a DNS jest objawem, nie przyczyną.

Krok 2: Uruchom ponownie router i modem

Odłączenie zasilania czyści wewnętrzną pamięć podręczną przekazywania DNS routera, resetuje dzierżawy DHCP i ponownie nawiązuje połączenie WAN ze świeżymi przypisaniami serwerów DNS od dostawcy ISP.

1. Odłącz kabel zasilający zarówno od modemu, jak i od routera.
2. Odczekaj pełne 30 sekund (kondensatory potrzebują czasu na rozładowanie).
3. Najpierw włącz modem; poczekaj, aż w pełni się zsynchronizuje (stała lampka WAN).
4. Następnie włącz router; poczekaj, aż zakończy sekwencję rozruchu.
5. Ponownie podłącz urządzenie i powtórz test nslookup z kroku 1.

Przypadek szczególny: Jeśli router pracuje od tygodni bez restartu, jego przekaźnik DNS (dnsmasq lub podobny) może mieć pełną pamięć podręczną lub wyciek pamięci. Niektóre routery dostarczone przez ISP mają znane błędy, w których przekaźnik DNS przestaje przekazywać zapytania po przekroczeniu określonego czasu pracy. Restart jest najszybszym rozwiązaniem.

Krok 3: Wyczyść lokalną pamięć podręczną DNS

Nieaktualne lub uszkodzone wpisy w pamięci podręcznej powodują, że system operacyjny zwraca błędne wyniki lub generuje błędy wyszukiwania, zanim zapytanie w ogóle opuści maszynę.

Windows:

ipconfig /flushdns

Powinieneś zobaczyć: Successfully flushed the DNS Resolver Cache.

macOS (zależnie od wersji — użyj właściwego polecenia dla swojego systemu):

# 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

Krok 4: Zmień na niezawodny publiczny resolwer DNS

Jeśli resolwer DNS dostawcy ISP jest przyczyną problemu, przełączenie na dobrze utrzymywany publiczny resolwer jest najszybszym obejściem. Poniższa tabela porównuje najpopularniejsze opcje:

Cloudflare 1.1.1.1 konsekwentnie osiąga najniższe globalne średnie opóźnienie zapytań w niezależnych testach porównawczych. Quad9 jest lepszym wyborem, jeśli chcesz pasywnego blokowania domen złośliwego oprogramowania bez zarządzania osobnym filtrem DNS.

Zmiana DNS w systemie Windows 10/11:

1. Otwórz Ustawienia > Sieć i Internet > Zmień opcje karty sieciowej.
2. Kliknij prawym przyciskiem myszy aktywną kartę sieciową i wybierz Właściwości.
3. Wybierz Protokół internetowy w wersji 4 (TCP/IPv4) i kliknij Właściwości.
4. Wybierz Użyj następujących adresów serwerów DNS.
5. Wprowadź wybrane adresy IP głównego i zapasowego resolwera.
6. Kliknij OK, a następnie uruchom ipconfig /flushdns, aby wyczyścić nieaktualne wpisy w pamięci podręcznej.

W sieciach IPv6 powtórz proces dla Protokołu internetowego w wersji 6 (TCP/IPv6), używając adresów IPv6 resolwera (np. Cloudflare: 2606:4700:4700::1111 i 2606:4700:4700::1001).

Zmiana DNS w systemie macOS:

1. Otwórz Ustawienia systemowe > Sieć.
2. Wybierz aktywne połączenie i kliknij Szczegóły.
3. Przejdź do zakładki DNS.
4. Usuń istniejące wpisy przyciskiem –, a następnie dodaj wybrane adresy IP resolwera przyciskiem +.
5. Kliknij OK i Zastosuj.

Zmiana DNS w systemie 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"

Krok 5: Uruchom ponownie usługę klienta DNS (Windows)

Usługa klienta DNS systemu Windows (Dnscache) buforuje rozwiązane nazwy i zarządza resolwerem stub. Jeśli przejdzie w stan zawieszenia, wszystkie zapytania DNS kończą się cichym niepowodzeniem.

net stop dnscache
net start dnscache

Alternatywnie, przez konsolę Usługi: naciśnij Win + R, wpisz services.msc, znajdź Klient DNS, kliknij prawym przyciskiem myszy i wybierz Uruchom ponownie. Należy pamiętać, że w niektórych kompilacjach systemu Windows 11 opcja restartu jest wyszarzona w interfejsie graficznym — w takim przypadku należy użyć metody wiersza poleceń.

Krok 6: Tymczasowo wyłącz zaporę sieciową lub oprogramowanie zabezpieczające

Zapory sieciowe innych firm i pakiety ochrony punktów końcowych czasami przechwytują ruch DNS w celu inspekcji i — z powodu konfliktu reguł lub błędu silnika — całkowicie odrzucają pakiety.

Zapora Windows Defender (tylko tymczasowy test):

netsh advfirewall set allprofiles state off

Włącz ponownie natychmiast po zakończeniu testu:

netsh advfirewall set allprofiles state on

macOS:

Przejdź do Ustawienia systemowe > Prywatność i bezpieczeństwo > Zapora sieciowa i wyłącz ją w celach testowych.

Jeśli wyłączenie zapory rozwiązuje problem, nie pozostawiaj jej wyłączonej. Zamiast tego otwórz edytor reguł zapory i poszukaj reguł blokujących ruch wychodzący na porcie UDP 53 i porcie TCP 53. Dodaj jawne reguły zezwalające dla wybranych adresów IP resolwera DNS.

Klienci VPN zasługują tu na szczególną uwagę. Wiele aplikacji VPN instaluje lokalny serwer proxy DNS na 127.0.0.1:53 i przekierowuje wszystkie zapytania przez tunel. Jeśli serwer VPN jest niedostępny, każde zapytanie DNS kończy się niepowodzeniem. Rozłącz VPN, przetestuj DNS, a następnie ponownie połącz i sprawdź ustawienia wycieku DNS w kliencie VPN.

Krok 7: Wypróbuj inną przeglądarkę

Niektóre rozszerzenia przeglądarki — szczególnie blokery reklam, narzędzia do ochrony prywatności i wtyczki zabezpieczające — przechwytują zapytania DNS-over-HTTPS (DoH) lub modyfikują zachowanie systemowego resolwera. Jeśli DNS działa w jednej przeglądarce, ale nie w innej, problem leży na poziomie rozszerzenia, a nie systemu operacyjnego.

Najpierw przetestuj w oknie prywatnym/incognito (rozszerzenia są zazwyczaj wyłączone). Jeśli to rozwiąże problem, wyłączaj rozszerzenia jedno po drugim, aby zidentyfikować winowajcę. Jeśli problem utrzymuje się we wszystkich przeglądarkach, usterka leży na poziomie systemu operacyjnego lub sieci.

Krok 8: Zaktualizuj lub przywróć poprzednią wersję sterowników sieciowych

Uszkodzony sterownik karty sieciowej może powodować nieregularne problemy z obsługą pakietów UDP, co objawia się sporadycznymi błędami DNS nawet wtedy, gdy połączenia TCP działają prawidłowo.

Windows — aktualizacja przez Menedżera urządzeń:

1. Naciśnij Win + X i wybierz Menedżer urządzeń.
2. Rozwiń Karty sieciowe.
3. Kliknij prawym przyciskiem myszy kartę sieciową i wybierz Aktualizuj sterownik > Wyszukaj sterowniki automatycznie.
4. Uruchom ponownie po instalacji.

Windows — przywracanie poprzedniej wersji niedawno zaktualizowanego sterownika:

Jeśli błąd DNS pojawił się bezpośrednio po aktualizacji systemu Windows, nowy sterownik może być przyczyną regresji. W Menedżerze urządzeń kliknij prawym przyciskiem myszy kartę sieciową, wybierz Właściwości > Sterownik > Przywróć poprzedni sterownik.

macOS: Sterowniki karty sieciowej są dołączone do systemu macOS. Zastosuj wszystkie oczekujące aktualizacje systemowe przez Ustawienia systemowe > Ogólne > Aktualizacja oprogramowania.

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

Krok 9: Sprawdź fizyczne połączenia sieciowe

Jeśli korzystasz z połączenia przewodowego, uszkodzony kabel Ethernet powoduje sporadyczną utratę pakietów, która nieproporcjonalnie dotyka protokołów opartych na UDP, takich jak DNS (który nie ma wbudowanej retransmisji na poziomie aplikacji).

• Ponownie podłącz oba końce kabla Ethernet.
• Wymień kabel na sprawdzony.
• Przetestuj inny port w routerze lub przełączniku.
• Sprawdź diody LED wskaźnika łącza karty sieciowej — stałe zielone lub pomarańczowe światło potwierdza fizyczne połączenie; migające lub nieświecące wskazuje na problem warstwy 1.

Krok 10: Uruchom narzędzie do rozwiązywania problemów sieciowych systemu Windows

System Windows zawiera zautomatyzowaną diagnostykę, która może wykrywać i naprawiać typowe błędy konfiguracji DNS, w tym resetowanie klienta DNS i czyszczenie pamięci podręcznej.

Przejdź do Ustawienia > System > Rozwiązywanie problemów > Inne narzędzia do rozwiązywania problemów > Połączenia internetowe i uruchom kreator. Podejmie on próbę automatycznej naprawy i zgłosi, co znalazł. Choć nie wykrywa każdego scenariusza, jest przydatną weryfikacją zajmującą mniej niż minutę.

Krok 11: Sprawdź i edytuj plik hosts

Uszkodzony lub złośliwie zmodyfikowany plik hosts może nadpisywać DNS dla określonych domen, powodując błędy rozwiązywania nazw wyglądające identycznie jak błąd serwera DNS.

Windows — otwórz z podwyższonymi uprawnieniami:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Szukaj wpisów przekierowujących popularne domeny na 0.0.0.0 lub 127.0.0.1. Oprogramowanie zabezpieczające, blokery reklam i złośliwe oprogramowanie modyfikują ten plik. Usuń podejrzane wpisy, zapisz plik i wyczyść pamięć podręczną DNS.

Krok 12: Resetowanie stosu TCP/IP i Winsock (Windows)

Jeśli wiele składników sieciowych jest błędnie skonfigurowanych, pełny reset stosu jest szybszy niż szukanie poszczególnych ustawień:

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

Uruchom ponownie komputer po wykonaniu wszystkich pięciu poleceń. Spowoduje to reset parametrów rejestru TCP/IP oraz katalogu Winsock do stanu domyślnego bez wpływu na sterowniki karty sieciowej.

Krok 13: Przywróć router do ustawień fabrycznych

Użyj tej opcji jako ostateczności przed kontaktem z dostawcą ISP. Reset fabryczny usuwa całą niestandardową konfigurację — nazwy sieci Wi-Fi (SSID), hasła, reguły przekierowania portów i wszelkie niestandardowe ustawienia DNS — i przywraca router do stanu fabrycznego.

Większość routerów ma zagłębiony przycisk resetowania. Przytrzymaj go szpilką przez 10–15 sekund, aż diody LED statusu zaczną cyklicznie migać. Po ponownym uruchomieniu routera skonfiguruj sieć od nowa. Jeśli DNS działa natychmiast po resecie, przyczyną było błędnie skonfigurowane ustawienie routera.

Krok 14: Skontaktuj się z dostawcą ISP

Jeśli wszystkie powyższe kroki zawiodły, a problem dotyczy wszystkich urządzeń w sieci, przyczyna niemal na pewno leży powyżej routera — w infrastrukturze rekurencyjnego resolwera ISP lub na samym łączu WAN. Skontaktuj się z pomocą techniczną dostawcy ISP, mając przygotowane następujące informacje:

• Wyniki nslookup example.com zarówno dla DNS dostawcy ISP, jak i publicznego resolwera, np. 8.8.8.8.
• Czy problem jest sporadyczny czy stały.
• Czy przełączenie na mobilny hotspot (całkowite ominięcie ISP) rozwiązuje problem.

Ten ostatni test jest definitywnym sprawdzeniem izolacji ISP.

Konfiguracja DNS dla administratorów serwerów

Jeśli zarządzasz środowiskiem Hosting VPS lub Serwerem Dedykowanym, błędy DNS nabierają dodatkowego wymiaru. Błędnie skonfigurowany resolwer na serwerze wpływa na każdą działającą na nim aplikację — serwery WWW, dostarczanie poczty, menedżery pakietów i agenci monitorowania — wszystkie zależą od niezawodnego rozwiązywania nazw.

Weryfikacja konfiguracji resolwera na serwerach Linux:

cat /etc/resolv.conf

Prawidłowy plik powinien zawierać co najmniej dwie linie nameserver wskazujące na niezawodne resolwery:

nameserver 1.1.1.1
nameserver 8.8.8.8

W systemach używających systemd-resolved, /etc/resolv.conf jest dowiązaniem symbolicznym. Bezpośrednia edycja nie przynosi efektu. Zamiast tego użyj resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Testowanie opóźnienia rozwiązywania nazw z serwera:

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

Jeśli czasy zapytań konsekwentnie przekraczają 200 ms, resolwer jest geograficznie odległy lub przeciążony. Przełącz się na resolwer z punktem obecności bliżej centrum danych serwera.

W przypadku serwerów z środowiskami cPanel VPS, konfiguracja DNS jest również zarządzana przez stronę Basic cPanel & WHM Setup w WHM. Upewnij się, że resolwery tam wymienione są zgodne z tymi w /etc/resolv.conf, aby uniknąć problemów z rozdzielonym rozwiązywaniem nazw.

DNS i rejestracja domen: połączenie z poziomem nadrzędnym

Błąd „DNS server not responding” dotyczący własnej domeny — a nie cudzej — często wynika z konfiguracji serwerów nazw na poziomie rejestratora. Jeśli niedawno zarejestrowałeś domenę lub zmieniłeś serwery nazw przez Rejestrację Domen, propagacja trwa do 48 godzin. W tym czasie niektóre resolwery na świecie nadal przechowują stare rekordy NS.

Użyj narzędzia do sprawdzania propagacji lub bezpośrednio odpytaj wiele geograficznie rozproszonych resolwerów:

# 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

Rozbieżności między odpowiedziami resolwerów podczas propagacji są normalne. Jeśli odpowiedzi nadal są niespójne po 48 godzinach, rekordy NS u rejestratora są prawdopodobnie błędnie skonfigurowane.

Zabezpieczanie DNS: DNSSEC i DNS-over-HTTPS

Standardowe zapytania DNS są przesyłane w postaci niezaszyfrowanej przez port UDP 53, co czyni je podatnymi na ataki DNS spoofing i cache poisoning. Dwie uzupełniające się technologie rozwiązują ten problem:

DNSSEC dodaje podpisy kryptograficzne do rekordów DNS, umożliwiając resolwerom weryfikację autentyczności odpowiedzi i potwierdzenie, że nie została ona zmodyfikowana. Chroni integralność danych, ale nie szyfruje samego zapytania.

DNS-over-HTTPS (DoH) i DNS-over-TLS (DoT) szyfrują całe zapytanie DNS, zapobiegając podsłuchiwaniu i manipulacji na ścieżce przesyłu. Nowoczesne przeglądarki obsługują DoH natywnie. Aby włączyć tę funkcję systemowo w systemie Windows 11, przejdź do Ustawienia > Sieć i Internet > [karta sieciowa] > Przypisanie serwera DNS > Edytuj i ustaw szyfrowanie na Tylko szyfrowane (DNS over HTTPS).

Na serwerach skonfiguruj systemd-resolved do używania 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

Jeśli korzystasz z Hostingu Poczty E-mail lub zarządzasz własnym serwerem pocztowym, prawidłowa konfiguracja DNS — w szczególności rekordy SPF, DKIM i DMARC — jest kluczowa dla dostarczalności wiadomości. Awarie DNS na serwerze pocztowym nie tylko blokują przeglądanie stron; powodują opóźnienia lub odrzucenia wiadomości e-mail oraz niepowodzenia walidacji certyfikatów TLS.

Certyfikaty SSL i zależność od DNS

Wydawanie i odnawianie certyfikatów TLS jest całkowicie zależne od DNS. Urzędy certyfikacji przeprowadzające walidację domeny (DV) za pomocą wyzwania DNS-01 ACME muszą rozwiązać rekord TXT _acme-challenge Twojej domeny. Jeśli DNS jest uszkodzony w momencie odnowienia, zautomatyzowane narzędzia takie jak Certbot zakończą się cichym niepowodzeniem, a Twoje Certyfikaty SSL wygasną — wyłączając wraz z nimi HTTPS.

Skonfiguruj monitorowanie zarówno stanu rozwiązywania DNS, jak i daty wygaśnięcia certyfikatu. Prosty test oparty na cron:

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

Macierz decyzyjna: identyfikacja warstwy awarii DNS

Użyj tej macierzy, aby zidentyfikować warstwę usterki przed poświęceniem czasu na rozwiązania, które nie będą miały zastosowania w Twojej sytuacji.

Lista kontrolna kluczowych wniosków technicznych

• Najpierw uruchom ping 8.8.8.8. Jeśli to nie powiedzie się, DNS nie jest Twoim głównym problemem — najpierw napraw routing lub łączność fizyczną.
• Zawsze czyść lokalną pamięć podręczną DNS po zmianie ustawień resolwera; nieaktualne wpisy mogą maskować skuteczność naprawy.
• Przełącz się na Cloudflare 1.1.1.1 lub Quad9 9.9.9.9 jako pierwszą zmianę resolwera — oba są szybsze i bardziej niezawodne niż większość resolwerów ISP.
• W systemie Windows, jeśli interfejs graficzny Usług wyszarza opcję restartu klienta DNS, użyj net stop dnscache && net start dnscache z wiersza poleceń z podwyższonymi uprawnieniami.
• Na serwerach Linux nigdy nie edytuj /etc/resolv.conf bezpośrednio w systemach systemd-resolved — zmiany są nadpisywane przy restarcie sieci. Użyj resolvectl lub nmcli.
• Klienci VPN są częstym cichym winowajcą. Zawsze testuj z rozłączonym VPN przed eskalacją problemu.
• W przypadku własnych domen dig +trace omija wszystkie pamięci podręczne i pokazuje dokładnie to, co zwracają serwery autorytatywne — używaj tego przed założeniem problemu z resolwerem.
• Włącz walidację DNSSEC i DNS-over-TLS/HTTPS na serwerach produkcyjnych, aby wyeliminować całą klasę awarii DNS opartych na spoofingu.
• Na serwerach monitoruj jednocześnie stan rozwiązywania DNS i datę wygaśnięcia certyfikatu SSL — awaria DNS spowoduje ciche niepowodzenie odnowienia certyfikatu kilka dni później.

Często zadawane pytania

Dlaczego DNS nie działa, mimo że mam działające połączenie internetowe?

Rozwiązywanie nazw DNS używa pakietów UDP na porcie 53, co jest oddzielne od połączeń TCP używanych przez przeglądarkę do ładowania stron. Reguła zapory sieciowej, awaria przekaźnika DNS na routerze lub niedostępny resolwer mogą blokować port 53 specyficznie, pozostawiając cały pozostały ruch bez zmian. Uruchom ping 8.8.8.8, aby potwierdzić łączność IP, a następnie nslookup example.com, aby potwierdzić, że DNS jest izolowaną przyczyną awarii.

Czy bezpieczne jest stałe używanie DNS Google lub Cloudflare zamiast resolwera ISP?

Tak, dla większości użytkowników i przypadków użycia. Zarówno Google Public DNS, jak i Cloudflare 1.1.1.1 obsługują walidację DNSSEC i oferują wyższe umowy SLA dotyczące dostępności niż typowe resolwery ISP. Kompromisem jest to, że zapytania DNS są przetwarzane przez infrastrukturę zewnętrznego dostawcy, a nie przez ISP. Cloudflare publikuje ścisłą politykę braku logowania zapytań; Google przechowuje zanonimizowane logi przez maksymalnie 48 godzin.

Jaka jest różnica między czyszczeniem pamięci podręcznej DNS a zmianą serwera DNS?

Czyszczenie pamięci podręcznej usuwa lokalnie przechowywane wyniki rozwiązywania nazw, zmuszając system operacyjny do wysyłania nowych zapytań do skonfigurowanego resolwera. Zmiana serwera DNS przekierowuje miejsce, do którego te zapytania są wysyłane. Jeśli pamięć podręczna zawiera zatrute lub nieaktualne wpisy, wyczyszczenie jej rozwiązuje problem bez zmiany resolwera. Jeśli sam resolwer jest niedostępny lub wolny, zmiana adresu serwera rozwiązuje problem bez dotykania pamięci podręcznej. W praktyce wykonanie obu czynności razem po awarii DNS jest najczystszym podejściem.

Dlaczego nslookup działa, ale przeglądarka nadal wyświetla błąd DNS?

Przeglądarki coraz częściej używają własnej implementacji DNS-over-HTTPS, która całkowicie omija resolwer systemu operacyjnego. Jeśli skonfigurowany punkt końcowy DoH przeglądarki jest niedostępny, może ona nie działać nawet wtedy, gdy systemowy resolwer działa prawidłowo. Sprawdź ustawienia prywatności lub bezpieczeństwa przeglądarki pod kątem opcji „Bezpieczny DNS” lub „DNS over HTTPS” i wyłącz ją lub wskaż na dostępnego dostawcę DoH.

Jak diagnozować problemy DNS na VPS z systemem Linux bez interfejsu graficznego?

Użyj dig, nslookup i resolvectl z wiersza poleceń. Uruchom dig @1.1.1.1 example.com, aby przetestować konkretny resolwer bezpośrednio, całkowicie omijając lokalną konfigurację. Uruchom resolvectl status, aby sprawdzić, którego resolwera system aktualnie używa i czy DNSSEC jest aktywny. Sprawdź /etc/resolv.conf, aby potwierdzić skonfigurowane serwery nazw, i zweryfikuj, czy plik nie jest uszkodzonym dowiązaniem symbolicznym za pomocą ls -la /etc/resolv.conf.