Jak sprawdzić serwer DNS w systemie?

Serwer DNS sprawdzisz na dwa sposoby. Dla publicznej domeny odczytaj rekordy NS poleceniem dig NS domena.pl lub whois domena.pl. Jeśli diagnozujesz własny BIND, wymuś zapytanie do konkretnego adresu za pomocą dig @IP_serwera domena.pl, a następnie sprawdź logi i poprawność plików strefy.

Jak sprawdzić serwer DNS przypisany do domeny?

Rekord NS wskazuje serwery nazw odpowiedzialne za obsługę domeny. Zapytanie wysłane bez wskazania serwera korzysta z resolvera skonfigurowanego w systemie, więc do dokładnej diagnostyki warto później odpytać konkretny adres DNS.

1. Sprawdź informacje rejestracyjne domeny poleceniem whois domena.pl. Wynik zwykle zawiera nazwy serwerów nazw w polach Name Server lub nserver.
2. Odczytaj rekordy NS za pomocą dig NS domena.pl. W sekcji ANSWER znajdziesz serwery autorytatywne dla domeny.
3. Sprawdź wynik narzędziem host -t NS domena.pl albo nslookup -type=NS domena.pl.
4. Porównaj odpowiedź z kilku serwerów, na przykład dig @1.1.1.1 NS domena.pl i dig @8.8.8.8 NS domena.pl. Różnice mogą wynikać z pamięci podręcznej lub trwającej propagacji zmian.

Do podstawowej weryfikacji możesz wybrać jedno z trzech popularnych narzędzi:

Sam rekord NS nie potwierdza jeszcze, że serwer poprawnie zwraca wszystkie dane domeny. Sprawdź także rekord A, MX lub SOA, na przykład:

dig A domena.pl
dig MX domena.pl
dig SOA domena.pl

Jak sprawdzić działanie własnego serwera DNS BIND?

W przypadku własnego serwera, na przykład BIND, nie wystarczy wykonać zwykłego zapytania dig domena.pl. Taka komenda może korzystać z resolvera systemowego, który wskaże inny serwer lub zwróci dane z pamięci podręcznej. Do testu użyj składni @IP_serwera.

1. Sprawdź odpowiedź serwera dla rekordu A: dig @192.0.2.10 domena.pl A. Zastąp przykładowy adres rzeczywistym adresem serwera DNS.
2. Sprawdź rekordy NS i SOA: dig @192.0.2.10 domena.pl NS oraz dig @192.0.2.10 domena.pl SOA.
3. Zweryfikuj rekord pocztowy, jeśli domena obsługuje pocztę: dig @192.0.2.10 domena.pl MX.
4. Jeżeli odpowiedź zawiera SERVFAIL, sprawdź konfigurację BIND, plik strefy i logi systemowe. W zależności od dystrybucji użyj na przykład journalctl -u bind9, grep named /var/log/syslog lub tail -f /var/log/daemon.log.

Odpowiedź SERVFAIL oznacza, że serwer nie był w stanie poprawnie obsłużyć zapytania. Nie wskazuje jednej konkretnej przyczyny. Często oznacza błąd składni lub ładowania strefy, problem z delegacją, brak wymaganych rekordów albo niedostępność serwera autorytatywnego.

Przed przeładowaniem usługi sprawdź plik główny i strefę. Przydatne polecenia to:

named-checkconf /etc/bind/named.conf
named-checkzone domena.pl /etc/bind/domena.pl

Jeśli używasz pliku named.conf, zwróć uwagę na średniki, nawiasy oraz poprawną deklarację strefy. Sam wpis strefy nie wystarczy, jeśli serwer nadrzędny nie deleguje domeny do wskazanych serwerów NS. Po zmianie danych strefy zwiększ numer seryjny w rekordzie SOA, aby serwer pomocniczy mógł rozpoznać aktualizację.

Na co uważać przy błędach DNS?

Przed szukaniem problemu w sieci sprawdź lokalną składnię i zawartość plików. Najczęstsze przyczyny niepoprawnej odpowiedzi BIND to:

• Brak kropki na końcu pełnej nazwy, na przykład ns1.domena.pl. zamiast nazwy względnej.
• Nieaktualny numer serial w rekordzie SOA, przez co serwer pomocniczy nie pobiera zmienionej strefy.
• Niepoprawne uprawnienia do plików strefy, które uniemożliwiają procesowi BIND ich odczytanie.
• Błędy składniowe w named.conf lub pliku strefy, w tym brak średnika po dyrektywie.

Uwaga: wpisy takie jak mail, www, ns1 i ns2 muszą mieć odpowiednie rekordy adresowe, jeśli są używane jako nazwy hostów. Po każdej zmianie sprawdź strefę poleceniem named-checkzone, a działanie serwera testuj przez dig @IP_serwera, nie tylko przez zwykłe zapytanie systemowe.

Najkrótsza ścieżka diagnostyczna wygląda więc tak: najpierw dig NS domena.pl dla sprawdzenia delegacji, następnie dig @IP_serwera domena.pl dla bezpośredniego testu BIND, a przy błędzie SERVFAIL – named-checkconf, named-checkzone i analiza logów.