błędna konfiguracja reverse DNS

Błędna konfiguracja reverse DNS to usterka, w której adres IP serwera nie jest poprawnie powiązany z jego nazwą domenową.

Na czym polega błędna konfiguracja reverse DNS

Reverse DNS, nazywany także odwrotnym DNS, służy do ustalenia nazwy domenowej przypisanej do konkretnego adresu IP. W zwykłym, czyli odwrotnym z punktu widzenia użytkownika, zapytaniu DNS nazwa domenowa jest tłumaczona na adres IP za pomocą rekordu A dla IPv4 albo AAAA dla IPv6. Reverse DNS działa w przeciwnym kierunku: dla adresu IP wyszukiwany jest rekord PTR, którego wartością jest nazwa domenowa hosta. Błędna konfiguracja występuje wtedy, gdy rekord PTR nie istnieje, wskazuje nieprawidłową nazwę, jest zapisany w niewłaściwej strefie albo nie odpowiada rzeczywistemu przeznaczeniu adresu.

Dla adresów IPv4 zapytanie reverse DNS korzysta ze strefy in-addr.arpa. Oktety adresu są odwracane, więc dla adresu 192.0.2.25 sprawdzana jest nazwa 25.2.0.192.in-addr.arpa. Dla adresów IPv6 używana jest strefa ip6.arpa, a adres jest przedstawiany jako odwrócona sekwencja pojedynczych cyfr szesnastkowych. Rekord PTR powinien zawierać pełną nazwę domenową zakończoną kropką w zapisie strefowym, na przykład host.example.net. Sam rekord PTR nie tworzy jednak automatycznie rekordu A lub AAAA. Te rekordy są konfigurowane oddzielnie.

Rekord PTR, delegacja strefy i zgodność z DNS

Za konfigurację reverse DNS odpowiada właściciel zakresu adresów IP albo operator, któremu ten zakres został delegowany. W przypadku adresów przydzielonych przez dostawcę internetu możliwość ustawienia rekordu PTR może znajdować się w panelu operatora lub wymagać zgłoszenia. Dla adresu należącego do własnej infrastruktury konieczne jest poprawne przygotowanie delegacji strefy reverse oraz serwerów nazw autorytatywnych dla tej strefy. Zmiana rekordu w zwykłej strefie domenowej nie naprawi reverse DNS, jeśli zapytanie dla adresu IP kierowane jest do innej, niepoprawnie delegowanej strefy.

Ważnym sprawdzeniem jest tak zwany forward-confirmed reverse DNS. Polega ono na porównaniu dwóch kierunków rozwiązywania nazwy: adres IP powinien zwracać nazwę z rekordu PTR, a ta nazwa powinna następnie zwracać ten sam adres w rekordzie A lub AAAA. Brak zgodności nie zawsze oznacza awarię całego DNS, ale może powodować odrzucanie połączeń przez systemy, które wykorzystują nazwę hosta jako jeden z elementów weryfikacji. Typowym błędem jest również wskazanie nazwy wewnętrznej, tymczasowej albo nieaktualnej po zmianie serwera, adresacji lub operatora sieci.

Na wynik zapytania wpływa także czas życia rekordu, czyli TTL. Po zmianie rekordu PTR część resolverów może nadal zwracać poprzednią wartość do czasu wygaśnięcia pamięci podręcznej. Dlatego odczyt wykonany bezpośrednio po zmianie nie musi od razu pokazywać stanu z serwera autorytatywnego. Trzeba odróżnić brak rekordu od odpowiedzi przechowywanej w cache, błędną delegację od niedostępności serwera DNS oraz odpowiedź NXDOMAIN od odpowiedzi z pustym zestawem rekordów.

Sprawdzanie odpowiedzi reverse DNS

Podstawowe sprawdzenie można wykonać narzędziem dig, używając zapytania dig -x 192.0.2.25 PTR dla przykładowego adresu IPv4. Opcja -x automatycznie buduje nazwę reverse DNS, a typ PTR ogranicza zapytanie do właściwego rodzaju rekordu. W systemie Windows podobną kontrolę można przeprowadzić poleceniem nslookup 192.0.2.25. Wynik należy analizować razem z sekcjami odpowiedzi, informacją o serwerze odpowiadającym oraz kodem statusu DNS. Odpowiedź NXDOMAIN oznacza, że pytana nazwa nie istnieje w systemie DNS, natomiast brak rekordu PTR przy istniejącej strefie może mieć inną przyczynę.

Przydatne jest także sprawdzenie serwera autorytatywnego oraz porównanie odpowiedzi z kilku resolverów. Polecenie dig +trace -x 192.0.2.25 może pomóc prześledzić delegację od serwerów głównych przez odpowiednią strefę domenową do serwera, który powinien udzielić odpowiedzi. Następnie warto wykonać zapytanie o nazwę zwróconą przez PTR, na przykład dig host.example.net A oraz, jeśli host korzysta z IPv6, dig host.example.net AAAA. Należy sprawdzić, czy oczekiwany adres znajduje się w odpowiedzi i czy nie występują stare rekordy, literówki, nieprawidłowe końcowe kropki lub wskazania na adres należący do innego urządzenia.

Diagnoza powinna uwzględniać także zakres problemu. Jeżeli reverse DNS działa z jednego resolvera, a nie działa z innego, przyczyną może być cache albo niespójność serwerów autorytatywnych. Jeżeli nie działa wszędzie, bardziej prawdopodobny jest brak rekordu PTR, błędna delegacja lub nieosiągalny serwer autorytatywny. W przypadku IPv6 trzeba zweryfikować pełne odwrócenie wszystkich nibble adresu, ponieważ pominięcie jednej cyfry lub użycie skróconego zapisu IPv6 prowadzi do zapytania o inną nazwę.

Skutki naprawy nieprawidłowego reverse DNS

Niepoprawny reverse DNS nie zmienia samego routingu pakietów i nie zastępuje konfiguracji adresów IP, bramy ani zapory sieciowej. Może jednak wpływać na sposób identyfikowania hosta przez narzędzia diagnostyczne, systemy monitoringu, mechanizmy kontroli dostępu oraz niektóre usługi sieciowe. W logach zamiast oczekiwanej nazwy może pojawiać się sam adres IP, nazwa tymczasowa albo komunikat o braku możliwości rozwiązania nazwy. W zależności od konkretnego systemu błędny PTR może również powodować opóźnienia przy wykonywaniu zapytań lub dodatkowe ostrzeżenia podczas nawiązywania połączeń.

Naprawa polega na ustaleniu właściwej nazwy hosta, utworzeniu albo poprawieniu rekordu PTR we właściwej strefie, a następnie sprawdzeniu zgodności z rekordem A lub AAAA. Jeżeli zmian dokonuje operator adresacji, trzeba przekazać mu dokładny adres IP i docelową pełną nazwę domenową. Po wdrożeniu należy odczekać na propagację zgodną z TTL i ponowić testy z resolvera lokalnego oraz z niezależnego resolvera. Przy diagnostyce serwerów i urządzeń sieciowych warto zachować wyniki zapytań, ponieważ pozwalają rozdzielić problem z konfiguracją DNS od problemów z łącznością, routingiem lub dostępnością badanego hosta.