Serwer DNS nie odpowiada? Napraw problem krok po kroku

Przy problemach z otwieraniem stron najwięcej czasu traci się nie na samą naprawę, tylko na zgadywanie, gdzie naprawdę leży usterka. Gdy pojawia się komunikat, że serwer DNS nie odpowiada, problem zwykle siedzi w konfiguracji sieci, pamięci podręcznej, routerze albo w samych rekordach domeny. W tym artykule pokazuję, jak to rozpoznać, jak naprawić krok po kroku i kiedy trzeba już patrzeć na hosting, operatora lub strefę DNS domeny.

Co właściwie przestaje działać, gdy DNS się wykłada

DNS to warstwa, która zamienia nazwę domeny na adres IP. Bez tego przeglądarka wie, co chcesz otworzyć, ale nie wie, gdzie znaleźć serwer. W praktyce awaria DNS nie oznacza, że strona zniknęła z internetu - oznacza, że urządzenie nie potrafi dotrzeć do jej właściwego adresu.

Warto znać kilka pojęć, bo one od razu porządkują diagnozę: resolver to serwer, który odbiera zapytanie z Twojego urządzenia i szuka odpowiedzi; serwer autorytatywny przechowuje właściwe rekordy danej domeny; rekord A wskazuje adres IPv4, AAAA - IPv6, a NS mówi, które serwery są odpowiedzialne za strefę domeny. Z kolei TTL określa, jak długo odpowiedź może być pamiętana w cache po drodze.

To ważne rozróżnienie, bo objaw „nie działa strona” może oznaczać coś zupełnie innego niż „nie działa DNS”. Jeśli znam ten podział, diagnoza staje się szybsza i dużo mniej przypadkowa. Następny krok to sprawdzenie, czy problem rzeczywiście leży w rozpoznawaniu nazw, a nie w samym łączu.

Jak rozpoznać, że problem leży w DNS, a nie w łączu

Ja zaczynam od prostych testów, bo one od razu pokazują, czy warto grzebać w DNS, czy raczej w Wi-Fi, kablu albo operatorze. Najlepszy test to taki, który nie zależy od przeglądarki i nie jest mylony przez jej własny cache.

Nie polegałbym wyłącznie na ping, bo ICMP bywa blokowane albo filtrowane po drodze. Dużo bardziej miarodajne jest nslookup, bo sprawdza samą odpowiedź DNS. Jeśli wynik jest dobry, a przeglądarka nadal nie otwiera stron, problem może siedzieć w profilu sieci, w dodatku do przeglądarki albo w lokalnym filtrze DNS. To prowadzi nas do najczęstszych przyczyn awarii po stronie urządzenia i sieci.

Skąd biorą się awarie po stronie urządzenia i sieci

W praktyce najczęściej widzę kilka powtarzalnych scenariuszy. Żaden z nich nie jest widowiskowy, ale każdy potrafi skutecznie zatrzymać dostęp do domen.

• Ręcznie ustawiony błędny DNS - jeden literowy błąd w adresie serwera wystarcza, żeby cała konfiguracja przestała działać.
• Uszkodzony lub stary cache DNS - komputer potrafi zapamiętać także nieudaną odpowiedź, więc nawet poprawnie działająca domena nadal wygląda na niedostępną.
• VPN, proxy lub filtr rodzinny - ruch DNS bywa przechwytywany, filtrowany albo kierowany inną ścieżką niż reszta ruchu.
• Router z własną, wadliwą konfiguracją - w domu to częstsze, niż się wydaje, zwłaszcza po aktualizacji firmware albo zmianie operatora.
• Mieszanie IPv4 i IPv6 - część zapytań idzie poprawnie, a część utknie na jednym z torów, co daje mylące objawy.
• Blokada po stronie operatora lub sieci firmowej - zdarza się, że konkretny resolver jest niedostępny albo polityka sieci nie przepuszcza zapytań tak, jak oczekujesz.

Jest jeszcze jeden częsty błąd: mylenie cache przeglądarki z cache DNS systemu. Usunięcie ciasteczek czy historii nie naprawia błędnych odpowiedzi resolvera. Dlatego przy naprawie trzeba iść warstwami, a nie czyścić wszystkiego po kolei. Poniżej pokazuję kolejność, która zwykle daje najszybszy efekt.

Jak naprawić to krok po kroku

Gdybym miał działać najszybciej, zacząłbym od rzeczy prostych i odwracalnych. Takie podejście zwykle pozwala ustalić, czy problem leży lokalnie, czy poza urządzeniem.

1. Zrestartuj router i urządzenie - odłącz router na około 30 sekund, włącz go ponownie i daj sieci chwilę na stabilizację. Ten krok sam w sobie bywa zaskakująco skuteczny, zwłaszcza po długim uptime.
2. Wyłącz na próbę VPN, proxy i filtry DNS - jeśli korzystasz z aplikacji zabezpieczającej, adblockera systemowego albo filtra rodzinnego, wyłącz je na chwilę i sprawdź, czy domeny zaczynają działać.
3. Wyczyść pamięć DNS systemu - w Windows najczęściej robi się to komendą ipconfig /flushdns. To usuwa lokalne, także błędne odpowiedzi, które komputer mógł zapamiętać wcześniej.
4. Sprawdź odpowiedź przez nslookup - wpisz nslookup google.com albo nazwę problematycznej domeny. Jeśli narzędzie odpowiada poprawnie, a przeglądarka nadal nie, zawęziłeś problem do warstwy aplikacji lub profilu sieciowego.
5. Zweryfikuj ustawienia DNS w karcie sieciowej - jeśli masz wpisy ręczne, upewnij się, że adresy są poprawne. Jeśli nie masz powodu, żeby je nadpisywać, często bezpieczniej jest wrócić do automatycznego pobierania z routera.
6. Przetestuj alternatywny resolver - chwilowa zmiana na publiczny DNS, na przykład Google 8.8.8.8 lub Cloudflare 1.1.1.1, pozwala szybko sprawdzić, czy winny jest operator albo lokalny resolver.
7. Sięgnij po reset sieci tylko wtedy, gdy trzeba - w Windows to już cięższa operacja, bo może skasować zapisane sieci Wi-Fi i inne konfiguracje. Używam jej dopiero wtedy, gdy prostsze kroki nie przynoszą efektu.

Jeśli po tej sekwencji wszystko zaczyna działać, problem był lokalny. Jeśli nie, trzeba przejść poziom wyżej i sprawdzić samą domenę. I właśnie tam zaczynają się różnice między awarią użytkownika a awarią po stronie właściciela witryny.

Co zrobić, gdy nie działa tylko jedna domena

Jeżeli wszystkie inne strony otwierają się normalnie, a jedna konkretna domena nadal nie działa, nie szukałbym winy w domowym Wi-Fi. W takich przypadkach problem częściej dotyczy strefy DNS, delegacji albo niedawnej zmiany serwera lub hostingu.

• Brak albo zły rekord A/AAAA - domena wskazuje na nieistniejący albo stary adres IP.
• Nieprawidłowy rekord CNAME - subdomena prowadzi do hosta, który już nie istnieje lub został źle wpisany.
• Błędna delegacja NS - domena jest kierowana do niewłaściwych serwerów nazw.
• DNSSEC nie zgadza się z podpisem - część resolverów odrzuca odpowiedź jako nieprawidłową, nawet jeśli sama domena fizycznie istnieje.
• Propagacja po zmianie DNS - stare rekordy mogą jeszcze siedzieć w cache po drodze, dopóki nie wygaśnie ich TTL.

Tu właśnie widać, że DNS to nie jest jeden przełącznik, tylko łańcuch zależności. Gdy domena zmieniła hosting, rekordy mogły jeszcze mieć TTL ustawiony na 300 sekund, 3600 sekund albo nawet 86400 sekund, więc różne sieci zobaczą zmianę w różnym momencie. Jeśli problem występuje tylko u mnie, a nie u innych, najpierw patrzę na cache i resolver. Jeśli występuje wszędzie, wina zwykle leży po stronie domeny albo jej serwerów nazw. To naturalnie prowadzi do pytania, czy warto podmienić DNS na inny i jaki wybrać.

Jaki zapasowy DNS ma sens w praktyce

Zmiana DNS bywa bardzo dobrym testem, ale nie powinna być robiona bezmyślnie. Ja traktuję publiczny resolver jako bezpieczny punkt odniesienia, a nie magiczną naprawę wszystkiego.

Jeśli po zmianie DNS wszystko nagle zaczyna działać, nie oznacza to jeszcze, że problem został „naprawiony” u źródła. Najczęściej oznacza to tylko, że ominąłeś wadliwy resolver albo pośrednią blokadę. Gdyby natomiast również publiczny DNS zwracał błędną odpowiedź dla jednej domeny, skłaniałbym się już do problemu po stronie samej strefy. W sieciach firmowych trzeba przy tym uważać na prywatne rekordy i wewnętrzne nazwy, bo publiczny resolver ich nie zna i nie powinien znać. Na koniec zostaje jeszcze jedna rzecz: jak ograniczyć ryzyko, że awaria wróci.

Jak ograniczyć ryzyko, że problem wróci

Najlepsza profilaktyka DNS nie polega na ciągłym grzebaniu w ustawieniach, tylko na utrzymaniu spójnej konfiguracji i szybkiej diagnostyce, gdy coś się zmienia. W praktyce zapisuję sobie, który resolver działał, i nie trzymam pięciu różnych ręcznych konfiguracji na raz.

Jeśli problem dotyczy domu, warto ograniczyć liczbę miejsc, w których DNS jest nadpisywany: router, komputer, telefon, VPN i aplikacje filtrujące potrafią nadawać różne priorytety. Jeśli chodzi o własną domenę, dobrze jest kontrolować rekordy A, AAAA, NS i TXT po każdej zmianie hostingu lub CDN, a także sprawdzać, czy TTL nie jest ustawiony zbyt agresywnie. Zbyt niski TTL przyspiesza propagację, ale zwiększa liczbę zapytań do serwera; zbyt wysoki wydłuża czas widoczności zmian.

Ja trzymam się prostej zasady: najpierw stabilny resolver, potem szybki test przez nslookup, a dopiero później głębsza analiza rekordów domeny. Taki porządek pozwala odróżnić lokalną usterkę od problemu po stronie hostingu albo operatora i zwykle prowadzi do rozwiązania szybciej niż przypadkowe zmienianie wszystkiego naraz. Jeśli po tych krokach błąd nadal wraca, następnym miejscem do sprawdzenia są logi routera, ustawienia DNS na urządzeniu i poprawność strefy domeny po stronie usługodawcy.