Polecenie nslookup przydaje się wtedy, gdy internet „jest”, ale strony nie otwierają się poprawnie, poczta przestaje rozpoznawać domeny albo router 5G zachowuje się inaczej niż sieć mobilna w telefonie. W praktyce to szybki sposób, by sprawdzić, czy problem leży w DNS, czy raczej w Wi-Fi, hotspotcie lub konfiguracji operatora. Poniżej pokazuję, jak odczytywać wynik, jakich zapytań używać i jak nie pomylić awarii nazwy z problemem z łączem.
Najważniejsze rzeczy, które sprawdzam przed diagnozą DNS
- Najpierw odróżniam DNS od łącza. Jeśli adres IP odpowiada, a nazwa domeny nie, problem zwykle dotyczy rozwiązywania nazw.
- Porównuję kilka resolverów. Ten sam host potrafi dać inny wynik na DNS operatora i na publicznym serwerze.
- Patrzę na typ rekordu. A, AAAA, CNAME, MX i PTR odpowiadają na różne pytania i dają inne tropy.
- Nie mylę błędu z brakiem rekordu. NXDOMAIN, SERVFAIL i timeout oznaczają różne problemy.
- Sprawdzam zarówno Wi-Fi, jak i sieć komórkową. W hotspotach i routerach 4G/5G problemy z DNS często wyglądają jak awaria całego internetu.
Kiedy to polecenie pomaga najbardziej
Dokumentacja Microsoft Learn opisuje to narzędzie jako sposób diagnozowania infrastruktury DNS. Ja traktuję je przede wszystkim jako test warstwy nazw: pokazuje, czy system umie znaleźć adres przypisany do domeny, a nie czy sam sygnał radiowy jest mocny.
Najczęściej sięgam po nie w kilku sytuacjach:
- strona działa po wpisaniu adresu IP, ale nie działa po nazwie domenowej;
- na domowym Wi-Fi wszystko wygląda normalnie, a aplikacje na telefonie nie potrafią otworzyć usług po nazwie;
- hotspot z telefonu albo router 4G/5G daje dostęp do sieci, ale część domen „znika”;
- trzeba porównać odpowiedź lokalnego DNS z publicznym resolverem i sprawdzić, gdzie pojawia się różnica;
- chcesz potwierdzić, czy domena ma poprawny rekord A, AAAA, MX albo PTR.
W praktyce to bardzo oszczędzające czas narzędzie, bo pozwala szybko zawęzić problem do konkretnej warstwy. Gdy już wiadomo, po co po nie sięgać, warto przejść do samego trybu pracy i wyniku, bo tam najłatwiej o nieporozumienia.
Jak uruchomić je i odczytać odpowiedź
W manpage Ubuntu opisano dwa tryby pracy: interaktywny i nieinteraktywny. W pierwszym możesz zadawać kilka pytań po kolei, w drugim podajesz nazwę od razu w linii poleceń i dostajesz jedną odpowiedź. Do szybkich testów w domu, na routerze albo w hotspocie zwykle zaczynam od trybu interaktywnego.
nslookupPo uruchomieniu zobaczysz zwykle nazwę domyślnego serwera DNS i jego adres. To ważne, bo właśnie ten resolver odpowiada za wynik, więc od razu wiesz, czy patrzysz na DNS operatora, routera czy własnoręcznie ustawiony serwer.
W odpowiedzi warto zwrócić uwagę na kilka elementów:
- Server i Address pokazują, kto odpowiada na zapytanie.
- Non-authoritative answer oznacza odpowiedź z resolvera pośredniego, a nie wprost z serwera autorytatywnego domeny.
- Name i Address potwierdzają, że nazwa rzeczywiście została rozwiązana do IP.
- Jeśli dostajesz odpowiedź dla adresu IP, szukasz rekordu PTR, czyli odwrotnego mapowania.
Jeśli chcesz szybko sprawdzić kilka wariantów, możesz w trybie interaktywnym zmieniać typ zapytania bez zamykania programu. Ja często przełączam się między rekordami A i AAAA, a potem porównuję wynik z publicznym serwerem DNS, bo to od razu pokazuje, czy problem jest lokalny, czy szerszy. Teraz przejdźmy do tego, jakie zapytania dają najwięcej informacji.
Jakie zapytania sprawdzają najwięcej
W diagnostyce DNS liczy się nie tylko sama domena, ale też to, czego o niej szukasz. Ten sam host może mieć adres IPv4, IPv6, alias, rekord pocztowy albo wpis zwrotny, a każdy z nich odpowiada na inne pytanie.
| Co sprawdzasz | Typ rekordu | Po co to robić |
|---|---|---|
| Adres IPv4 | A | Sprawdzasz, czy domena prowadzi do właściwego adresu w sieci IPv4. |
| Adres IPv6 | AAAA | Wykrywasz sytuację, w której IPv4 działa, ale ścieżka IPv6 już nie. |
| Alias lub przekierowanie nazwy | CNAME | Widzisz, dokąd naprawdę prowadzi nazwa pośrednia. |
| Serwer poczty | MX | Sprawdzasz, czy domena poprawnie obsługuje pocztę elektroniczną. |
| Serwer nazw strefy | NS | Ustalasz, kto jest autorytatywny dla danej domeny. |
| Odwrotne mapowanie IP | PTR | Weryfikujesz, czy adres IP ma sensowną nazwę zwrotną. |
| Weryfikacje i polityki | TXT | Sprawdzasz rekordy używane przez SPF, DKIM i różne mechanizmy potwierdzania własności. |
Dwa szybkie testy robię najczęściej tak: porównuję rekord A i AAAA tej samej domeny na DNS operatora oraz na publicznym resolverze, a potem sprawdzam, czy CNAME nie kieruje mnie do miejsca, które samo ma już błędny adres. Jeśli domena działa na jednej sieci bezprzewodowej, a na innej nie, taki podział zwykle od razu pokazuje, gdzie zacząć dalsze sprawdzanie.
Gdy rekordy wyglądają poprawnie, a strona nadal nie działa, problem zwykle leży albo niżej, albo wyżej w stosie sieciowym. I właśnie dlatego trzeba odróżnić DNS od awarii łącza.
Jak odróżnić problem DNS od awarii Wi-Fi lub sieci komórkowej
W sieciach bezprzewodowych ten test jest szczególnie ważny, bo użytkownik często widzi tylko objaw: telefon ma zasięg, laptop jest połączony z routerem, ale aplikacje nie odpowiadają. W praktyce rozdzielam to na kilka scenariuszy.
| Objaw | Co sprawdzam najpierw | Najbardziej prawdopodobna przyczyna |
|---|---|---|
| Ping do adresu IP działa, ale domena nie | Rekord A lub AAAA, a potem resolver używany przez sieć | DNS, cache lub błędna konfiguracja nazw |
| Problem występuje tylko na Wi-Fi, a na LTE działa | DNS routera, filtrację i ewentualny captive portal | Lokalny resolver, router lub ograniczenia sieci Wi-Fi |
| Ta sama domena działa w jednej sieci, a w drugiej nie | Porównanie wyników z dwóch resolverów | Split-horizon DNS, różne cache albo polityka operatora |
| Adres IPv4 działa, a IPv6 nie | Rekord AAAA i ścieżkę IPv6 | Problem z implementacją IPv6 po stronie urządzenia lub sieci |
| Wszystko kończy się timeoutem | Dostępność serwera DNS i reguły firewall | Brak łączności z resolverem albo blokada ruchu |
Jedna rzecz, która często myli początkujących: ping do nazwy domenowej nie jest czystym testem łącza, bo sam zaczyna od DNS. Jeśli naprawdę chcesz oddzielić warstwy, najpierw sprawdź adres IP, potem nazwę i dopiero później aplikację. W publicznych sieciach Wi-Fi dochodzi jeszcze captive portal, który potrafi tymczasowo przechwytywać ruch i sprawiać wrażenie, że „internet nie działa”, choć problem dotyczy tylko logowania do sieci.
Po takim rozróżnieniu zwykle zostaje już tylko kilka typowych błędów, które warto wyłapać, zanim zacznie się zmieniać ustawienia na ślepo.
Najczęstsze błędy podczas testów i jak ich nie popełniać
- Sprawdzanie tylko jednego resolvera. Jeśli testujesz wyłącznie DNS operatora, możesz nie zauważyć, że publiczny serwer odpowiada poprawnie i problem leży lokalnie.
- Pomijanie rekordów AAAA. W sieciach z IPv6 to częsty błąd, bo IPv4 działa, a użytkownik i tak widzi awarię części usług.
- Mylenie NXDOMAIN z awarią. NXDOMAIN oznacza, że nazwa nie istnieje, ale czasem powód jest banalny: literówka, zły subdomenowy prefiks albo rekord jeszcze nie został utworzony.
- Zakładanie, że zmiana DNS naprawi słaby sygnał. Nie naprawi. Jeśli Wi-Fi gubi pakiety albo 5G ma niestabilne połączenie, resolver tylko odsłoni problem, a nie go rozwiąże.
- Ignorowanie cache i TTL. Przy TTL 300 s zmiana może pojawić się po kilku minutach, ale przy TTL 3600 s część resolverów trzyma stary wynik przez godzinę lub dłużej.
- Nieczytanie komunikatów o błędach. Timeout, REFUSED i SERVFAIL oznaczają różne rzeczy, więc każdą z tych odpowiedzi trzeba traktować osobno.
W praktyce najbardziej opłaca się robić dwa porównania: ten sam rekord na DNS lokalnym i na publicznym, a potem ten sam rekord dla A i AAAA. To zwykle wystarcza, żeby odsiać przypadkowe wnioski i zobaczyć, czy problem siedzi w nazwie, w serwerze czy w łączu bezprzewodowym. Zostaje jeszcze pytanie, kiedy warto po prostu zmienić DNS, a kiedy to strata czasu.
Kiedy zmiana DNS ma sens, a kiedy to nic nie da
W sieci domowej, w hotspotcie z telefonu i w routerze 4G lub 5G najczęściej zaczynam od porównania odpowiedzi z DNS operatora z publicznym resolverem. Jeśli ten drugi zwraca poprawny adres, a pierwszy nie, zmiana DNS na routerze albo w urządzeniu końcowym ma sens i często daje szybki efekt.
- Zmiana DNS ma sens, gdy problem dotyczy tylko rozpoznawania nazw, a po adresie IP połączenie działa.
- Zmiana DNS ma sens, gdy jedna sieć bezprzewodowa zwraca błędne odpowiedzi, a druga nie.
- Zmiana DNS ma sens, gdy urządzenia w domu lub w hotspocie korzystają z tego samego wadliwego resolwera.
- Zmiana DNS nie ma sensu, gdy Wi-Fi zrywa połączenie, transfer spada albo pakiety gubią się niezależnie od domeny.
- Zmiana DNS nie ma sensu, gdy problem dotyczy certyfikatów, logowania do aplikacji albo samej usługi po drugiej stronie.
Dla mnie to narzędzie jest najbardziej użyteczne wtedy, gdy trzeba w minutę zawęzić winnego do jednej warstwy. Jeśli po porównaniu kilku serwerów DNS odpowiedzi są spójne, a problem nadal występuje, szukam przyczyny w routerze, radiu, aplikacji albo po stronie usługi. To właśnie taki porządek diagnostyki oszczędza najwięcej czasu w sieciach bezprzewodowych.
