System nie aktualizuje danych PTR

System nieaktualizujący danych PTR wskazuje na wyłączoną dynamiczną aktualizację rekordów odwrotnych na serwerze DNS.

Rekord PTR i odwrotne rozwiązywanie nazw

Rekord PTR (Pointer) służy do odwrotnego rozwiązywania nazw DNS, czyli do ustalenia nazwy hosta na podstawie adresu IP. Dla adresów IPv4 rekordy PTR są przechowywane w strefach znajdujących się pod domeną in-addr.arpa. Adres 192.0.2.25 jest zapisywany odwrotnie jako 25.2.0.192.in-addr.arpa. Dla IPv6 używa się domeny ip6.arpa, a adres przedstawia się jako odwróconą sekwencję pojedynczych cyfr szesnastkowych. Wynik zapytania PTR może wskazywać nazwę hosta, ale sam rekord nie służy do potwierdzania, że dana nazwa rzeczywiście wskazuje z powrotem na ten sam adres.

Brak aktualizacji danych PTR oznacza zwykle, że zmiana adresu IP, nazwy urządzenia albo dzierżawy DHCP nie została odzwierciedlona w strefie odwrotnej. Sam fakt, że serwer DNS odpowiada na zapytania, nie świadczy jeszcze o działaniu mechanizmu dynamicznej aktualizacji. Odpowiedź może zawierać stary rekord, komunikat NXDOMAIN oznaczający brak nazwy albo wynik pochodzący z pamięci podręcznej. Dlatego podczas analizy trzeba rozdzielić problem z zapisem danych od problemu z propagacją i odczytem już istniejącego rekordu.

Jak powstaje niespójność między adresem IP a nazwą hosta

W typowej sieci biurowej adres IP może być przydzielany przez DHCP, natomiast rekord PTR znajduje się w strefie odwrotnej obsługiwanej przez DNS. Aktualizacja wymaga współpracy klienta DHCP, serwera DHCP albo systemu operacyjnego z autorytatywnym serwerem DNS. Jeżeli strefa odwrotna nie istnieje, jest niedostępna dla właściwego serwera aktualizującego lub nie zezwala na modyfikację, rekord PTR nie zostanie utworzony ani zmieniony. Podobny skutek występuje wtedy, gdy klient otrzyma nową dzierżawę, lecz poprzedni rekord nie zostanie usunięty z powodu błędnej konfiguracji właściciela aktualizacji.

Dynamiczna aktualizacja DNS jest określona między innymi w RFC 2136. W praktyce serwer może wymagać uwierzytelnienia, a aktualizacje mogą być ograniczone do konkretnych hostów, zakresów DHCP lub podpisanych żądań. W środowiskach korzystających z mechanizmu GSS-TSIG autoryzacja jest powiązana z tożsamością klienta lub usługi. Jeżeli żądanie pochodzi z niewłaściwego źródła, używa nieprawidłowych danych uwierzytelniających albo próbuje zmienić rekord należący do innego klienta, serwer DNS może je odrzucić. W logach pojawiają się wtedy informacje o odmowie, braku uprawnień lub nieudanej aktualizacji.

Rozróżnienie błędu zapisu od opóźnienia odpowiedzi

Diagnozę należy rozpocząć od ustalenia, który serwer jest autorytatywny dla strefy odwrotnej. Zapytanie wykonane do lokalnego resolvera może zwrócić dane z pamięci podręcznej, dlatego wynik trzeba porównać z odpowiedzią autorytatywnego serwera. Narzędzia nslookup i dig pozwalają sprawdzić rekord PTR, serwer odpowiadający oraz status odpowiedzi. Warto wykonać zarówno zapytanie odwrotne dla adresu IP, jak i zapytanie typu A lub AAAA dla zwróconej nazwy. Jeżeli oba kierunki nie są zgodne, występuje niespójność między strefą do przodu i strefą odwrotną.

Na wynik wpływa również czas życia rekordu, czyli wartość TTL. Po poprawnej zmianie autorytatywnej odpowiedzi część resolverów może jeszcze przez określony czas zwracać poprzednią wartość. Nie jest to dowód, że aktualizacja nie zaszła. Należy także sprawdzić serial w rekordzie SOA oraz synchronizację między serwerem głównym i wtórnym. Jeżeli strefa jest replikowana, jeden serwer może zawierać nowy rekord, a drugi nadal starszą wersję. Osobnym przypadkiem jest poprawnie działający DNS, który nie posiada PTR dla adresu prywatnego, ponieważ zakres adresów został utworzony bez odpowiedniej strefy odwrotnej albo rekordy są utrzymywane ręcznie.

Przywrócenie poprawnego przepływu aktualizacji

Usunięcie problemu wymaga sprawdzenia całego przepływu: przydzielenia adresu, zgłoszenia aktualizacji, autoryzacji żądania, zapisu w strefie, replikacji oraz odczytu przez resolver. Należy potwierdzić, że dla właściwego zakresu IPv4 lub prefiksu IPv6 istnieje odpowiednia strefa odwrotna, a jej rekordy NS wskazują aktywne serwery DNS. Następnie trzeba zweryfikować, czy serwer DHCP albo klient ma skonfigurowany mechanizm aktualizacji PTR i czy używa konta lub klucza z prawem do zapisu. Przy zmianie sposobu zarządzania rekordami należy również usunąć stare wpisy, aby jeden adres IP nie pozostawał powiązany z nieaktualną nazwą.

Po korekcie konfiguracji test powinien obejmować zwolnienie i ponowne przydzielenie dzierżawy, sprawdzenie logów serwera DNS oraz porównanie odpowiedzi autorytatywnej z odpowiedzią resolvera. Nie należy traktować ręcznego dodania rekordu jako pełnego rozwiązania, jeżeli wpisy mają być zarządzane automatycznie przez DHCP. Ręczna zmiana może chwilowo poprawić wynik zapytania, ale kolejna dzierżawa, zmiana nazwy hosta albo ponowne użycie adresu może odtworzyć błąd. W przypadku komputerów i laptopów podłączonych do sieci firmowej lub domowej diagnostyka powinna objąć także lokalny resolver, konfigurację DHCP, zaporę sieciową i ewentualne filtrowanie żądań DNS.