Sprawdzanie rekordów DNS przydaje się zawsze wtedy, gdy strona nie odpowiada, poczta utknęła w kolejce albo subdomena prowadzi nie tam, gdzie powinna. W praktyce najczęściej chodzi o to, jak sprawdzić DNS domeny i szybko ustalić, czy problem leży w rekordzie, cache czy delegacji serwerów nazw. Poniżej pokazuję najkrótszą i najbardziej użyteczną drogę: od wyboru narzędzia, przez odczyt wyniku, po sytuacje, w których DNS jest poprawny, ale usługa nadal nie działa.
Najpierw sprawdź rekord, serwer i TTL, bo to zwykle rozwiązuje problem najszybciej
- Do szybkiej weryfikacji używam najczęściej `dig`, a na Windows także `nslookup`.
- Stronę internetową sprawdzasz zwykle przez rekordy `A`, `AAAA` i `CNAME`, a pocztę przez `MX` oraz `TXT`.
- Jeśli wynik różni się między resolverami, winny bywa cache lub TTL, nie sam rekord.
- Najpewniejszy test to porównanie publicznego resolvera z odpowiedzią z autorytatywnego serwera DNS.
- Rekord `PTR` służy do reverse DNS i zwykle ustawia go operator IP, a nie panel domeny.
Najkrótsza droga do sprawdzenia rekordów DNS
Ja zwykle zaczynam od prostego pytania: co dokładnie mam zweryfikować i czy chcę zobaczyć odpowiedź z cache, czy z serwera autorytatywnego. To rozróżnienie oszczędza najwięcej czasu, bo nie każdy wynik, który widzisz w terminalu, pochodzi z tej samej warstwy DNS. Do szybkiej pracy wystarczą dwa narzędzia: `dig` na macOS i Linux oraz `nslookup` na Windows, choć oba działają też w innych środowiskach.
dig example.pl A
dig example.pl AAAA
dig example.pl MX
dig example.pl NS
dig example.pl TXT
dig @1.1.1.1 example.pl A
dig @8.8.8.8 example.pl MX
dig @ns1.twoj-hosting.pl example.pl A
dig -x 203.0.113.10
nslookup -type=a example.pl
nslookup -type=mx example.pl
nslookup -type=txt example.pl
nslookup -type=ns example.plW tych zapytaniach najważniejsze jest to, że pytasz o konkretny typ rekordu. Nie sprawdzasz “DNS-u ogólnie”, tylko wyciągasz odpowiedź dla tego elementu strefy, który ma znaczenie w danym problemie. Jeśli domena działa inaczej dla `www` i bez `www`, to nie jest drobiazg, tylko sygnał, że patrzysz na dwa różne nazwy DNS. Żeby nie błądzić po omacku, dobrze od razu wiedzieć, który rekord ma znaczenie w danym scenariuszu.
Który rekord ma znaczenie w twoim problemie
Najwięcej błędów widzę wtedy, gdy ktoś sprawdza nie ten rekord, który faktycznie odpowiada za objaw. Strona nie działa z powodu złego `A` albo `CNAME`, poczta przestaje dochodzić przez `MX` lub `TXT`, a delegacja domeny psuje się przez `NS`. Poniżej masz praktyczne zestawienie, które skraca diagnozę.
| Rekord | Do czego służy | Kiedy go sprawdzać | Co powinno cię uspokoić |
|---|---|---|---|
| A | Wskazuje adres IPv4 domeny | Gdy strona ma ładować się z konkretnego IP | Wynik pokazuje właściwy adres serwera |
| AAAA | Wskazuje adres IPv6 | Gdy hosting obsługuje IPv6 albo użytkownicy wchodzą po nowoczesnych sieciach | Adres IPv6 zgadza się z konfiguracją hostingu |
| CNAME | Tworzy alias do innej nazwy | Gdy `www` lub subdomena mają kierować na inną nazwę hosta | Alias prowadzi do właściwego celu i nie koliduje z innymi rekordami |
| MX | Określa serwer odbierający pocztę | Gdy e-maile nie dochodzą lub wysyłka zwraca błędy | Wynik pokazuje poprawny host pocztowy i właściwy priorytet |
| TXT | Przechowuje tekstowe wpisy w strefie | Gdy trzeba sprawdzić SPF, DKIM, DMARC albo weryfikację domeny | Wartość TXT zgadza się z tym, czego oczekuje usługa |
| NS | Wskazuje autorytatywne serwery nazw | Gdy chcesz sprawdzić, kto naprawdę obsługuje strefę | Delegacja prowadzi do serwerów, na których edytujesz rekordy |
| SOA | Opisuje strefę i jej parametry techniczne | Gdy chcesz potwierdzić, że strefa istnieje i odczytać serial lub timery | SOA zwraca spójne dane dla tej samej strefy |
| PTR | Reverse DNS, czyli IP → nazwa hosta | Gdy diagnozujesz pocztę, reputację IP albo logi serwerowe | PTR wskazuje nazwę zgodną z infrastrukturą serwera |
W praktyce jedna zasada oszczędza najwięcej czasu: najpierw sprawdź rekord związany z objawem, potem dopiero resztę strefy. Jeśli problem dotyczy strony, zacznij od `A` albo `CNAME`; jeśli dotyczy poczty, zacznij od `MX` i `TXT`. Kiedy już wiesz, co sprawdzasz, pozostaje odczytać odpowiedź bez mylenia cache z błędem konfiguracji.
Jak czytać wynik z dig i nslookup
Najważniejsze jest to, żeby nie patrzeć wyłącznie na sam adres IP albo nazwę hosta. W odpowiedzi DNS liczy się również to, kto odpowiedział, jaki był status zapytania i czy wynik pochodzi z serwera autorytatywnego, czy z resolvera po drodze. `dig` pokazuje to bardzo wyraźnie, a `nslookup` bywa prostszy w podstawowej diagnozie, szczególnie na Windows.
- ANSWER SECTION - tutaj widzisz właściwy rekord, czyli to, czego szukasz.
- AUTHORITY SECTION - przydaje się, gdy odpowiedź nie zawiera rekordu i chcesz zobaczyć, kto odpowiada za strefę.
- SERVER - pokazuje resolver, który obsłużył zapytanie.
- TTL - mówi, jak długo odpowiedź może siedzieć w cache.
- NOERROR - zapytanie się udało, ale nie zawsze oznacza to, że dany typ rekordu istnieje.
- NXDOMAIN - nazwa nie istnieje w DNS.
- SERVFAIL - serwer lub resolver miał problem z obsługą zapytania.
W `nslookup` często pojawia się komunikat typu non-authoritative answer. To ważna informacja, bo oznacza odpowiedź z resolvera, a nie bezpośrednio z serwera, na którym trzymasz strefę. Taki wynik może być poprawny, ale nadal nie rozstrzyga, czy rekord został już rozpropagowany wszędzie. Ja przy zmianach zawsze porównuję go z odpowiedzią z autorytatywnego nameservera, bo dopiero wtedy widać, czy problem siedzi w konfiguracji, czy w cache. I właśnie cache prowadzi nas do kolejnego kroku.
Dlaczego wynik nie zawsze zgadza się od razu
DNS nie działa jak przełącznik, który w jednej sekundzie zmienia odpowiedź wszędzie. Po drodze działają cache przeglądarki, systemu operacyjnego, routera i publicznych resolverów, a każdy z nich może trzymać starszą wersję rekordu do momentu wygaśnięcia TTL. W praktyce zmiana bywa widoczna po kilku minutach, ale zdarza się też, że trzeba poczekać dłużej, zwłaszcza gdy TTL jest wysoki albo zmieniasz delegację NS.
Ja przy takich testach robię trzy porównania:
- Sprawdzam rekord na publicznym resolverze, na przykład przez `@1.1.1.1` albo `@8.8.8.8`.
- Sprawdzam ten sam rekord na autorytatywnym nameserverze, czyli tam, gdzie naprawdę leży strefa.
- Porównuję TTL, żeby ocenić, jak długo stary wynik może jeszcze żyć w cache.
Warto też pamiętać, że zmiana samych rekordów i zmiana nameserverów u rejestratora to nie to samo. Rekord A czy TXT może aktualizować się stosunkowo szybko, ale jeśli delegacja NS wciąż wskazuje stare serwery, panel hostingu będzie wyglądał poprawnie, a Internet dalej będzie pytał kogoś innego. Dobrą praktyką jest także świadome ustawianie TTL. W panelach spotyka się wartości rzędu 300 s, 3600 s albo 86400 s, przy czym im wyższy TTL, tym dłużej mogą utrzymywać się stare odpowiedzi. To brzmi banalnie, ale właśnie na TTL najczęściej wykładają się wdrożenia domen i poczty.
Kiedy już rozumiesz cache i TTL, łatwiej wyłapać błędy, które na pierwszy rzut oka wyglądają jak “problem z DNS”, a wcale nimi nie są.
Najczęstsze błędy przy sprawdzaniu DNS
Tu najczęściej widzę te same pomyłki, tylko w różnych konfiguracjach. Nie są spektakularne, ale potrafią skutecznie zmylić nawet doświadczoną osobę, jeśli patrzy wyłącznie na jeden wynik z jednego miejsca.
- Sprawdzanie złego typu rekordu - strona nie działa, a ktoś analizuje `MX` zamiast `A` albo `CNAME`.
- Mylenie domeny głównej z `www` - `example.pl` i `www.example.pl` to dwa osobne wpisy.
- Zakładanie, że CNAME może stać obok innych rekordów - pod tą samą nazwą zwykle nie powinno być konfliktujących rekordów.
- Oczekiwanie, że MX wskaże bezpośrednio IP - w praktyce MX kieruje na nazwę hosta, a ta dopiero rozwiązuje się dalej.
- Weryfikacja tylko na jednym resolverze - jeden publiczny wynik nie mówi jeszcze, jak widzą to inni użytkownicy.
- Zmiana rekordów w złym panelu - jeśli domena ma inne NS, edytowanie strefy u nieaktywnego dostawcy nic nie da.
- Próba ustawienia PTR w panelu domeny - reverse DNS zwykle kontroluje operator adresu IP, nie rejestrator domeny.
Jeżeli po wyeliminowaniu tych błędów rekord nadal wygląda poprawnie, a usługa wciąż nie działa, problem zwykle siedzi już poza samą strefą DNS. Właśnie dlatego w praktyce zawsze zamykam diagnozę czymś więcej niż tylko jednym odpytaniem DNS.
Gdy rekord jest poprawny, a strona albo poczta nadal nie działa
To najważniejszy etap, bo tutaj kończy się czyste sprawdzanie DNS, a zaczyna normalna diagnostyka infrastruktury. Jeśli rekord się zgadza, ja od razu sprawdzam trzy kolejne warstwy: delegację domeny, usługę docelową i elementy bezpieczeństwa albo routingu, które potrafią wyglądać jak problem DNS, choć nim nie są.
- Delegacja NS - upewnij się, że rejestrator domeny wskazuje właściwe nameserwery.
- Serwer WWW - nawet poprawny rekord A nie pomoże, jeśli aplikacja, vhost albo reverse proxy nie odpowiadają.
- Certyfikat TLS - przeglądarka może zgłaszać błąd certyfikatu, choć DNS działa prawidłowo.
- Poczta - poza MX sprawdź `SPF`, `DKIM`, `DMARC` oraz `PTR`, bo to one często blokują dostarczanie wiadomości.
- CDN lub proxy - jeśli używasz warstwy pośredniej, rekord DNS może wskazywać poprawnie, ale źródło wciąż mieć złą konfigurację.
W takich sytuacjach nie szukam już kolejnego narzędzia do DNS, tylko odpowiadam sobie na pytanie, co dokładnie ma się wydarzyć po rozwiązaniu nazwy. Jeśli domena ma prowadzić do strony, muszą działać jeszcze HTTP, HTTPS i konfiguracja hostingu. Jeśli ma działać poczta, liczy się też infrastruktura mailowa i reputacja IP. DNS jest tylko pierwszą warstwą, ale bez poprawnej pierwszej warstwy reszta i tak nie ma szans zadziałać.
Jeżeli chcesz sprawdzić DNS szybko i bez błądzenia, trzymaj się prostego schematu: wybierz konkretny rekord, porównaj odpowiedź z resolvera i serwera autorytatywnego, a potem oceń TTL oraz delegację NS. To wystarcza w większości przypadków i pozwala odróżnić błąd w strefie od problemu po stronie hostingu, poczty albo cache. Dzięki temu diagnoza jest krótsza, a naprawa zwykle trafia w właściwe miejsce za pierwszym razem.
