PRZYGOTOWANIE
Czego potrzebujesz
- Zainstalowane narzędzie dig
- Nazwa publicznej domeny do sprawdzenia
- Dla porównania: nazwa jednego z rzeczywistych serwerów NS swojej strefy
KROK 01
Przygotuj nazwę domeny
Zacznij od najprostszego zapytania: dig example.com A. Polecenie to wysyła zapytanie o rekord A (adres IPv4) domeny example.com. Użyj własnej domeny zamiast example.com, bo example.com jest zarezerwowane przez IANA i może nie odzwierciedlać rzeczywistej konfiguracji DNS.
Dig wysyła zapytanie do resolvera skonfigurowanego w systemie (np. do lokalnego serwera DNS lub publicznego resolvera). Nie modyfikuje on żadnych rekordów DNS – tylko odczytuje dane. Możesz go używać bez obaw o przypadkowe zmiany w konfiguracji domeny.
Polecenie wymaga zainstalowanego narzędzia dig. Nazwa pakietu zależy od dystrybucji; sprawdź ją w dokumentacji swojego systemu, jeśli powłoka zgłasza brak polecenia. Pracuj na domenie publicznej, którą chcesz diagnozować. Wewnętrznych nazw firmowych nie wysyłaj do przypadkowych publicznych resolverów: wybór serwera DNS wpływa na to, komu ujawniasz zapytanie.
dig example.com AWynik zawiera sekcję QUESTION (zapytanie), ANSWER (odpowiedź z adresem IP), AUTHORITY (serwery autorytatywne) i ADDITIONAL (dodatkowe dane). Status NOERROR oznacza, że zapytanie się powiodło, nawet jeśli brak rekordu danego typu.
KROK 02
Odróżnij rodzaje rekordów
Każdy typ rekordu DNS odpowiada na inne pytanie. A to adres IPv4, AAAA to adres IPv6, MX to serwery poczty, a TXT to dowolny tekst (często używany do SPF, DKIM, weryfikacji domeny). Użyj dig z odpowiednim typem, aby sprawdzić każdy z nich osobno.
Parametr +short upraszcza wynik do samych wartości, bez nagłówków. Jest wygodny, gdy potrzebujesz tylko adresu IP, ale nie pokazuje statusu zapytania ani TTL. Jeśli +short zwróci pusty wynik, nie wiesz, czy to brak rekordu, czy błąd zapytania – wtedy usuń +short, aby zobaczyć pełną odpowiedź.
Dla rekordu MX dig zwraca priorytet i nazwę serwera pocztowego. Niższy priorytet oznacza wyższe pierwszeństwo. Dla TXT zobaczysz łańcuchy znaków w cudzysłowie – mogą być podzielone na wiele segmentów, ale DNS traktuje je jako całość.
dig example.com AAAA
dig example.com MX
dig example.com TXTRekord AAAA zwraca adres IPv6 lub brak odpowiedzi, jeśli domena nie obsługuje IPv6. MX pokazuje serwery pocztowe z priorytetami. TXT wyświetla wpisy tekstowe – często wiele linii dla różnych celów (SPF, DKIM, weryfikacja).
KROK 03
Przeczytaj status i TTL
Status odpowiedzi to kluczowa informacja. NOERROR oznacza sukces – serwer zna domenę i zwrócił dane (lub brak rekordu danego typu, co też jest poprawną odpowiedzią). NXDOMAIN oznacza, że domena nie istnieje w tym widoku DNS. SERVFAIL to błąd serwera – może wynikać z problemów z autorytatywnym serwerem lub błędów DNSSEC.
TTL (Time To Live) w odpowiedzi to czas w sekundach, przez jaki resolver może przechowywać odpowiedź w cache. Wartość przy każdym rekordzie w sekcji ANSWER to pozostały czas ważności. To nie jest gwarantowany czas propagacji globalnej – każdy resolver może mieć własne ustawienia cache.
Sekcja SERVER w stopce wyniku wskazuje adres IP resolvera, który odpowiedział. To nie musi być serwer autorytatywny dla domeny – to tylko ten, do którego trafiło zapytanie. Aby sprawdzić dane autorytatywne, musisz zapytać bezpośrednio serwer autorytatywny.
Status NOERROR z brakującym rekordem to poprawna sytuacja – domena istnieje, ale nie ma rekordu danego typu. NXDOMAIN wymaga sprawdzenia, czy domena jest poprawnie zarejestrowana i delegowana. TTL w odpowiedzi to czas ważności w cache, a nie czas od utworzenia rekordu.
KROK 04
Zapytaj serwer autorytatywny
Aby ominąć cache lokalnego resolvera i sprawdzić dane bezpośrednio u źródła, musisz najpierw znaleźć serwery autorytatywne dla domeny. Użyj dig example.com NS, aby uzyskać listę serwerów nazw. Następnie wyślij zapytanie bezpośrednio do jednego z nich, używając składni dig @ns1.example.com example.com A.
Parametr +norecurse ustawia zapytanie bez żądania rekurencji. Sam w sobie nie dowodzi, że odpowiedź jest autorytatywna: serwer może odpowiedzieć z cache, zwrócić delegację lub odmówić odpowiedzi. Użyj rzeczywistej nazwy NS otrzymanej dla swojej strefy, zamiast dosłownego ns1.example.com z przykładu. Potem sprawdź status i flagi odpowiedzi.
Flaga aa znajduje się w nagłówku odpowiedzi, w polu flags — nie w sekcji ANSWER. Wskazuje odpowiedź autorytatywną dla odpowiedniej nazwy. Jeśli jej brak, sprawdź status, sekcję AUTHORITY i delegację: możesz pytać niewłaściwy serwer lub otrzymywać odesłanie do innej strefy. Nie uznawaj dowolnej zwróconej wartości za dane bezpośrednio ze strefy.
dig example.com NS
dig @ns1.example.com example.com A +norecursePierwsze zapytanie zwraca listę serwerów NS. Drugie wysyła zapytanie bezpośrednio do jednego z nich z wyłączoną rekurencją. W odpowiedzi szukaj flagi aa w sekcji flags, która potwierdza odpowiedź autorytatywną.
KROK 05
Porównaj cache i autorytatywne dane
Porównanie pomaga ustalić, czy resolver widzi te same dane co serwer autorytatywny. Rozbieżność może wynikać z cache, niespójności serwerów lub świadomego rozdzielenia odpowiedzi wewnętrznych i publicznych, czyli split-DNS. Sama różnica nie dowodzi ataku. Zapisz dokładną nazwę, typ rekordu i adres serwera, aby porównywać to samo zapytanie.
Aby porównać, wykonaj to samo zapytanie (ten sam typ rekordu) najpierw bez @ (do lokalnego resolvera), a potem z @serwer_autorytatywny. Zwróć uwagę na różnice w wartościach rekordów i TTL. Jeśli dane są identyczne, DNS działa poprawnie z perspektywy tego resolvera.
Pamiętaj, że negatywne cache (przechowywanie informacji o braku rekordu) też ma TTL. Jeśli niedawno dodałeś rekord, a zapytanie do resolvera go nie zwraca, podczas gdy autorytatywny serwer już go ma, to normalna sytuacja – poczekaj na wygaśnięcie negatywnego cache.
Zgodne odpowiedzi potwierdzają zgodność tych konkretnych zapytań w chwili pomiaru. Nie dowodzą, że wszystkie resolvery na świecie otrzymują już tę samą wartość. Przy różnicy sprawdź TTL i każdy serwer autorytatywny, zamiast określać z góry jeden uniwersalny czas propagacji.
KROK 06
Ustal, czy awaria dotyczy DNS czy aplikacji
Poprawny adres A to dopiero jeden element działania strony. Problem może dotyczyć połączenia, TLS, konfiguracji WWW, ale również innego rekordu DNS — na przykład nieprawidłowego AAAA używanego przez klienta z IPv6. Tak samo obecność MX nie potwierdza kompletności konfiguracji pocztowej. Sprawdź dokładną nazwę i rodzaj połączenia, z którego korzysta niedziałający klient.
Jeśli strefa ma kilka serwerów autorytatywnych, porównaj ich odpowiedzi dla tego samego zapytania. Rozbieżności wymagają wyjaśnienia synchronizacji strefy lub celowej polityki odpowiedzi. Delegacja w strefie nadrzędnej powinna wskazywać odpowiednie serwery; rekordy NS odczytane tylko z jednego miejsca nie stanowią jeszcze pełnej kontroli delegacji.
Brak rekordu (pusta odpowiedź z NOERROR) nie jest dowodem na problem z DNS – to po prostu brak danego typu rekordu. Jeśli potrzebujesz dodać rekord, zrób to w panelu zarządzania DNS, a nie przez modyfikację plików lokalnych. Dig nie tworzy ani nie modyfikuje rekordów.
Dobra odpowiedź dla jednego rekordu zawęża diagnozę, ale nie wyklucza wszystkich problemów DNS. Pustą odpowiedź NOERROR odróżniaj od błędu serwera i sprawdzaj, czy ten typ rekordu w ogóle powinien istnieć. Przy dalszym teście strony możesz przejść do curl, zachowując ten sam adres domeny.
Pytania i odpowiedzi
Dlaczego jest adres IP w odpowiedzi dig, a strona nie działa?
Sprawdź, czy adres jest właściwy i czy klient korzysta z A czy AAAA. Udane zapytanie o jeden rekord nie potwierdza wszystkich danych DNS ani połączenia HTTPS. Kolejny etap to sprawdzenie odpowiedzi HTTP, certyfikatu i dostępności portu. Poradnik o curl pokazuje, jak odróżnić kod statusu strony od błędu połączenia.
Co oznacza status SERVFAIL w odpowiedzi dig?
SERVFAIL to błąd serwera DNS. Przyczyną może być problem z autorytatywnym serwerem, błąd walidacji DNSSEC, przeciążenie resolvera lub tymczasowa awaria sieci. Spróbuj zapytać bezpośrednio serwer autorytatywny (dig @ns...), aby sprawdzić, czy problem leży po stronie resolvera.
Dlaczego dig z +short nie pokazuje nic, mimo że rekord istnieje?
+short pomija nagłówki i pokazuje tylko wartości. Jeśli rekord istnieje, ale +short jest pusty, przyczyną może być filtr w resolverze, tymczasowy błąd lub rekord nieistniejącego typu. Usuń +short i sprawdź pełną odpowiedź – zobaczysz wtedy status, sekcję ANSWER i ewentualne błędy.