Błąd przy aktualizacji rekordów przez nsupdate

Błąd przy aktualizacji rekordów przez `nsupdate` oznacza odrzucenie dynamicznej aktualizacji DNS przez serwer — częsta przyczyna to brak uprawnień klucza TSIG lub wyłączona dynamiczna aktualizacja strefy.

Czym jest błąd przy aktualizacji rekordów przez nsupdate

Błąd przy aktualizacji rekordów przez nsupdate oznacza, że żądanie zmiany wpisów w strefie DNS nie zostało zaakceptowane przez serwer autorytatywny. Narzędzie nsupdate służy do wykonywania dynamicznych aktualizacji DNS, czyli dodawania, modyfikowania lub usuwania rekordów bez ręcznej edycji pliku strefy. Taki mechanizm jest często wykorzystywany przy automatycznym rejestrowaniu adresów hostów, zmianach infrastruktury sieciowej, obsłudze usług uruchamianych tymczasowo oraz aktualizacji rekordów tworzonych przez skrypty.

Samo polecenie może zostać wysłane poprawnie, a mimo to serwer zwróci odmowę wykonania operacji. W komunikacie pojawiają się wtedy między innymi kody REFUSED, NOTAUTH, NOTZONE, FORMERR lub BADSIG. Każdy z nich wskazuje na inną grupę przyczyn: brak uprawnień, niewłaściwy serwer docelowy, niezgodność nazwy ze strefą, błędny format żądania albo nieprawidłową weryfikację podpisu TSIG.

W praktyce nie jest to zwykle błąd samego DNS jako usługi, lecz rozbieżność pomiędzy konfiguracją klienta, definicją strefy, kluczem uwierzytelniającym i regułami serwera. Do prawidłowej diagnozy potrzebne jest ustalenie, jaki rekord ma zostać zmieniony, do którego serwera trafia żądanie oraz na jakiej podstawie serwer ocenia uprawnienia.

Kontekst techniczny i porównanie sposobów aktualizacji DNS

Tradycyjna zmiana rekordu DNS polega na edycji pliku strefy, zwiększeniu numeru seryjnego SOA, sprawdzeniu składni i przeładowaniu konfiguracji serwera. Dynamiczna aktualizacja przez nsupdate przebiega inaczej: klient przesyła komunikat aktualizacyjny do serwera, a serwer sprawdza, czy operacja jest dozwolona dla wskazanej strefy i nazwy. Dzięki temu zmiana może być wykonywana przez automatyzację bez bezpośredniego zapisu do plików konfiguracyjnych.

Najczęściej stosowanym mechanizmem autoryzacji jest klucz TSIG. Klient podpisuje nim żądanie, a serwer porównuje podpis z własną kopią klucza. Zgodność musi obejmować nie tylko sam sekret, lecz także dokładną nazwę klucza, algorytm, sposób zapisania wartości oraz czas generowania podpisu. Różnica w wielkości liter, dodatkowy znak w nazwie albo użycie innego algorytmu może skutkować odrzuceniem aktualizacji.

Ważne jest również rozróżnienie serwera, do którego kierowane jest żądanie. Rekord może być obsługiwany przez serwer autorytatywny dla danej strefy, podczas gdy adres użyty w poleceniu wskazuje na resolver przeznaczony wyłącznie do wyszukiwania nazw. Resolver może prawidłowo odpowiadać na zapytania A, AAAA czy MX, ale nie musi przyjmować zmian. Podobny problem występuje przy kierowaniu aktualizacji do serwera wtórnego, który otrzymuje dane przez transfer strefy, a nie poprzez bezpośrednią edycję.

Istotna jest także zgodność nazwy rekordu z granicą strefy. Jeżeli aktualizowana nazwa nie należy do strefy wskazanej w komunikacie, serwer może zwrócić błąd NOTZONE. W konfiguracjach wykorzystujących delegacje trzeba dodatkowo sprawdzić, gdzie faktycznie znajduje się autorytatywna odpowiedzialność za daną nazwę. Przy rekordach typu CNAME, NS lub SOA mogą obowiązywać ograniczenia wynikające z samej struktury DNS, dlatego nie każda poprawna składniowo operacja jest dopuszczalna logicznie.

Przykładowa sesja może wyglądać następująco:

server dns.example.net
zone example.net
update delete host.example.net. A
update add host.example.net. 300 A 192.0.2.25
send

Jeżeli wymagane jest uwierzytelnienie, należy użyć właściwego klucza TSIG zgodnie z konfiguracją używanego serwera. Samo dodanie klucza do polecenia nie gwarantuje powodzenia, jeżeli po stronie serwera dynamiczne aktualizacje są wyłączone albo reguła zezwala na zmianę innej strefy, nazwy lub typu rekordu.

Typowe problemy i błędy podczas używania nsupdate

Jedną z najczęstszych przyczyn jest brak reguły zezwalającej na dynamiczne aktualizacje. Strefa może działać poprawnie dla zwykłych zapytań, ale pozostawać tylko do odczytu z punktu widzenia klientów. W takiej sytuacji żądanie dociera do odpowiedniego serwera, jednak zostaje odrzucone jako niedozwolone. Warto sprawdzić konfigurację strefy, reguły autoryzacji oraz to, czy po zmianie konfiguracji wykonano przeładowanie usługi.

Drugą grupę stanowią problemy z kluczem TSIG. Błąd może wynikać z niezgodności nazwy klucza, niewłaściwego sekretu, innego algorytmu skrótu, uszkodzenia pliku klucza lub nieprawidłowego sposobu jego wczytania. Przy ręcznym przepisywaniu wartości łatwo wprowadzić spację, znak końca linii albo pomylić znaki o podobnym wyglądzie. Jeżeli serwer zgłasza BADSIG, BADKEY albo NOTAUTH, należy porównać pełną konfigurację po obu stronach, a nie tylko samą nazwę klucza.

Problemy mogą pojawiać się również przy czasie systemowym. Podpisy TSIG mają ograniczoną ważność, dlatego znaczna różnica pomiędzy zegarem klienta i serwera może doprowadzić do odrzucenia żądania. Sprawdzane powinny być synchronizacja czasu, strefa czasowa używana w logach oraz stan usługi odpowiedzialnej za synchronizację.

Częstym błędem składniowym jest pominięcie końcowej kropki w pełnej nazwie domenowej. Nazwa host.example.net może zostać potraktowana jako względna wobec bieżącej strefy, natomiast host.example.net. jednoznacznie wskazuje pełną nazwę. Znaczenie mają również parametry TTL, typ rekordu, kolejność instrukcji oraz użycie polecenia send. Przy usuwaniu rekordów trzeba zachować zgodność typu i wartości z istniejącym wpisem, o ile nie jest usuwany cały rekord danego typu.

Warto przeanalizować odpowiedzi narzędzia oraz logi serwera, a następnie porównać je z wynikiem zapytań diagnostycznych, na przykład dig SOA, dig NS lub dig +tcp. Pozwala to ustalić, czy problem występuje przed dotarciem żądania do serwera, podczas autoryzacji, czy dopiero przy walidacji konkretnej zmiany. Należy też uwzględnić zaporę sieciową, filtrowanie ruchu na porcie DNS, transport TCP oraz ewentualne ograniczenia adresów źródłowych.

Kiedy warto oddać urządzenie do diagnozy - Błąd przy aktualizacji rekordów przez nsupdate

Zgłoszenie do serwisu jest uzasadnione, gdy aktualizacje DNS przestały działać po zmianie konfiguracji sieci, migracji usługi, wymianie urządzenia, odtworzeniu systemu z kopii albo wdrożeniu nowego skryptu. Szczególnej uwagi wymagają sytuacje, w których zwykłe zapytania DNS działają, lecz automatyczna aktualizacja jest odrzucana. Taki objaw wskazuje, że podstawowa łączność może być prawidłowa, a problem dotyczy uprawnień, kluczy, strefy lub sposobu obsługi żądania.

Przed przekazaniem zgłoszenia warto przygotować dokładny komunikat błędu, fragment polecenia bez ujawniania sekretu TSIG, nazwę strefy, adres użytego serwera, czas wystąpienia problemu oraz informację o ostatnich zmianach. Przydatne są także odpowiednie wpisy z dziennika i wynik zapytania potwierdzającego, który serwer jest autorytatywny dla danej nazwy. Nie należy przesyłać haseł ani pełnych kluczy uwierzytelniających w treści zgłoszenia.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie konfiguracji systemu, połączenia sieciowego i narzędzi odpowiedzialnych za aktualizację nazw; w przypadku laptopa dostępna jest darmowa diagnoza LAPTOPA. Analiza może objąć logi, ustawienia DNS, synchronizację czasu, reguły zapory oraz zależności pomiędzy skryptem aktualizującym a serwerem autorytatywnym, tak aby odróżnić błąd lokalnego środowiska od problemu po stronie usługi DNS.

Po usunięciu przyczyny powinno zostać wykonane kontrolne dodanie, modyfikacja i usunięcie testowego rekordu, a następnie sprawdzenie odpowiedzi z kilku punktów sieci. Pozwala to potwierdzić nie tylko przyjęcie komunikatu przez serwer, lecz także poprawne rozgłoszenie zmiany i działanie automatyzacji przy kolejnym uruchomieniu.