Czym jest rekord SOA w DNS i dlaczego ma znaczenie dla Twojej domeny

Czym jest rekord SOA?

Rekord SOA (Start of Authority) to pierwszy rekord w każdej strefie DNS i jedyny, który musi istnieć dokładnie raz. Wskazuje podstawowy serwer nazw strefy, adres kontaktowy administratora oraz zestaw liczników czasu, które mówią wtórnym serwerom nazw, jak utrzymywać swoją kopię strefy w synchronizacji.

W odróżnieniu od rekordu A czy MX, SOA nie służy do odpowiadania na zapytania użytkowników. To metadane samej strefy: kto jest dla niej autorytatywny, która to wersja strefy i jak długo inne serwery mogą tej wersji ufać lub ją buforować. Jeśli SOA jest błędny, strefa może dziś nadal się rozwiązywać — ale przestanie się aktualizować, nie wygaśnie na czas albo będzie buforować błędy o wiele za długo.

Rekord SOA dowolnej domeny możesz zobaczyć za pomocą dig:

dig SOA example.com +short

Typowa odpowiedź wygląda tak:

ns1.example.com. hostmaster.example.com. 2026082601 3600 900 1209600 300

Siedem wartości to podstawowy serwer nazw, skrzynka osoby odpowiedzialnej oraz pięć liczb — numer seryjny i cztery liczniki czasu — objaśnione poniżej.

Siedem pól rekordu SOA

Każdy rekord SOA zawiera te same siedem pól, w tej kolejności:

MNAME — podstawowy serwer nazw strefy. Serwery wtórne wysyłają do tego hosta zapytania odświeżające i oczekują od niego komunikatów NOTIFY. Powinna to być nazwa hosta, która się rozwiązuje, a nie adres IP.

RNAME — skrzynka osoby odpowiedzialnej za strefę, zapisana z kropką zamiast @: hostmaster.example.com oznacza [email protected]. Jeśli sama część lokalna zawiera kropkę, jest ona poprzedzona odwrotnym ukośnikiem.

Serial — numer wersji strefy. Serwery wtórne porównują go z własną kopią, aby stwierdzić, czy strefa się zmieniła. To najważniejsze pole dla utrzymywania wtórnych serwerów nazw w aktualnym stanie.

Refresh — jak często, w sekundach, serwer wtórny pyta serwer podstawowy o bieżący numer seryjny. Częstą wartością jest 3600 (jedna godzina). Przy skonfigurowanym NOTIFY ten licznik to tylko zabezpieczenie.

Retry — jak długo serwer wtórny czeka, zanim zapyta ponownie po nieudanej próbie odświeżenia. Powinien być krótszy niż refresh; typowo 900 (15 minut).

Expire — jak długo serwer wtórny nadal obsługuje strefę po tym, jak ostatni raz udało mu się połączyć z serwerem podstawowym. Gdy ten licznik dobiegnie końca, serwer wtórny całkowicie przestaje odpowiadać na zapytania o strefę. Zwykła wartość to 1209600 (dwa tygodnie).

Minimum — historycznie domyślny TTL rekordów; od RFC 2308 określa TTL negatywnego buforowania: jak długo resolwery mogą przechowywać w cache informację, że nazwa nie istnieje (NXDOMAIN). Efektywny negatywny TTL to mniejsza z dwóch wartości: tego pola i TTL samego rekordu SOA. Rozsądny zakres to od 300 do 3600.

Jak wtórne serwery nazw korzystają z SOA

Rekord SOA to umowa między Twoim podstawowym serwerem nazw a każdym serwerem wtórnym obsługującym Twoją strefę. Serwer wtórny realizuje następujący cykl:

1. Co refresh sekund odpytuje serwer podstawowy o rekord SOA. 2. Porównuje numer seryjny z odpowiedzi z numerem seryjnym własnej kopii. 3. Jeśli numer seryjny serwera podstawowego jest wyższy, żąda transferu strefy (AXFR lub IXFR) i instaluje nową kopię. 4. Jeśli zapytanie się nie powiedzie, próbuje ponownie po retry sekundach. 5. Jeśli nie może połączyć się z serwerem podstawowym przez expire sekund, odrzuca strefę i zwraca SERVFAIL, dopóki serwer podstawowy nie wróci.

Większość serwerów podstawowych wysyła też komunikat NOTIFY w chwili zmiany strefy, więc serwer wtórny sprawdza numer seryjny natychmiast, zamiast czekać na upływ licznika refresh. Liczniki nadal mają znaczenie: NOTIFY może zaginąć, zostać zablokowany przez zaporę albo po prostu nie być skonfigurowany — wtedy refresh i retry to jedyne, co utrzymuje kopie w synchronizacji.

Właśnie dlatego hostowana usługa wtórnego DNS może utrzymać Twoją domenę online, gdy serwer podstawowy nie działa: ma już pełną, aktualną kopię strefy i odpowiada na zapytania o nią, dopóki nie upłynie expire. Szerszy obraz znajdziesz w Redundancja DNS, a opis samego transferu w Jak działają transfery stref AXFR.

Numer seryjny: formaty i klasyczne błędy

Numer seryjny to 32-bitowa liczba całkowita bez znaku, a jedyna zasada wymuszana przez protokół brzmi: nowsza strefa musi mieć większy numer seryjny niż poprzednia. Serwery wtórne nie patrzą na daty ani znaczniki czasu plików — tylko na tę liczbę.

Numery seryjne oparte na dacie to najczęstsza konwencja: RRRRMMDDnn, na przykład 2026082601 dla pierwszej zmiany 26 sierpnia 2026. Dwie ostatnie cyfry pozwalają na maksymalnie 100 edycji dziennie, a liczba pozostaje czytelna dla człowieka w wyniku dig.

Numery seryjne jako uniksowe znaczniki czasu stosuje wielu dostawców zarządzanego DNS oraz BIND skonfigurowany z serial-format unixtime. Rosną automatycznie i nigdy nie kolidują.

Zwykłe liczniki (1, 2, 3, …) są równie poprawne. Format to konwencja, nie wymóg.

Błędy, które naprawdę psują strefy:

- Zapomnienie o zwiększeniu numeru seryjnego. Edytujesz plik strefy, przeładowujesz serwer podstawowy i ten odpowiada nowymi danymi — ale każdy serwer wtórny wciąż widzi stary numer seryjny, uznaje, że nic się nie zmieniło, i bez końca obsługuje nieaktualne rekordy. To najczęstsza przyczyna sytuacji „zmiana działa na ns1, ale nie na ns2”.

- Cofnięcie numeru. Przejście z dużego numeru seryjnego opartego na znaczniku czasu na mały numer oparty na dacie albo przywrócenie starego pliku strefy sprawia, że serwer wtórny ma wyższy numer seryjny niż podstawowy. Nigdy więcej nie wykona transferu, dopóki numer seryjny serwera podstawowego go nie przegoni. Wyjście daje arytmetyka numerów seryjnych (RFC 1982): dodaj do numeru seryjnego 2^31 − 1 (2147483647), pozwól każdemu serwerowi wtórnemu go pobrać, a potem ustaw wartość, którą naprawdę chcesz — drugi krok znów zostanie uznany za zwiększenie.

- Edycja numeru seryjnego na serwerze wtórnym. Serwerów wtórnych nigdy nie wolno edytować ręcznie; kolejny transfer nadpisuje kopię, a ręczna zmiana znika.

Dobór wartości refresh, retry, expire i minimum

RFC 1912 podaje klasyczne wskazówki, które wciąż są aktualne. Rozsądne wartości domyślne dla strefy ze skonfigurowanym NOTIFY:

Refresh — 1 godzina (3600) Retry — 15 minut (900) Expire — 2 tygodnie (1209600) Minimum — od 5 minut do 1 godziny (300 – 3600)

Dwie zasady ważniejsze niż dokładne liczby:

Retry musi być krótszy niż refresh, a najlepiej stanowić jego niewielki ułamek — w przeciwnym razie nieudane odświeżenie po prostu czeka na kolejne zaplanowane, a licznik retry nic nie robi.

Expire musi być dłuższy niż najdłuższa awaria serwera podstawowego, jaką jesteś w stanie sobie wyobrazić. Jeśli serwer podstawowy padnie w piątek wieczorem i nikt tego nie zauważy do poniedziałku, expire równy 86400 (jeden dzień) oznacza, że każdy serwer wtórny przestał odpowiadać już w sobotę — i cały sens posiadania serwerów wtórnych przepada. Dwa tygodnie to częsty wybór i zarazem dolna granica dla strefy produkcyjnej; RFC 1912 zaleca od dwóch do czterech tygodni.

W przypadku minimum (negatywne buforowanie) krótsze wartości sprawiają, że nowo utworzony rekord staje się widoczny szybciej, jeśli odpytano go, zanim istniał; dłuższe wartości zmniejszają obciążenie powtarzanymi zapytaniami o nazwy, które nigdy nie będą istnieć. Nie ustawiaj go powyżej kilku godzin — literówka w nazwie hosta zostałaby wtedy zbuforowana jako nieistniejąca na cały dzień.

Diagnozowanie nieaktualnego serwera wtórnego za pomocą dig

Gdy zmiana w DNS jest widoczna na jednym serwerze nazw, a na innym nie, numer seryjny SOA wskazuje, gdzie leży problem. Zapytaj bezpośrednio każdy serwer autorytatywny:

dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

Trzy możliwe wyniki:

Ten sam numer seryjny na obu — strefa jest zsynchronizowana. Jeśli rekord nadal wygląda błędnie, problemem jest buforowanie na resolwerze, a nie replikacja; poczekaj na upływ TTL rekordu albo odpytaj bezpośrednio serwer autorytatywny.

Niższy numer seryjny na serwerze wtórnym — serwer wtórny zna strefę, ale nie pobrał najnowszej wersji. Sprawdź, czy numer seryjny na serwerze podstawowym rzeczywiście został zwiększony, czy serwer podstawowy zezwala na transfery z adresu IP serwera wtórnego (allow-transfer / allow-axfr-ips), czy port TCP 53 jest między nimi otwarty oraz czy serwer podstawowy w ogóle wysyła NOTIFY.

SERVFAIL lub REFUSED z serwera wtórnego — strefa albo nigdy nie została przetransferowana, albo wygasła. Zajrzyj do dziennika serwera wtórnego w poszukiwaniu ostatniego udanego transferu; jeśli jest starszy niż wartość expire, serwer wtórny poprawnie porzucił strefę i potrzebuje powrotu serwera podstawowego, aby móc ją ponownie wczytać.

Serwer wtórny, który powinien być zsynchronizowany, a nie jest, to cicha awaria: nadal odpowiada, tylko starymi danymi. Monitorowanie numeru seryjnego na każdym serwerze nazw — nie tylko osiągalności — to jedyny sposób, aby wykryć problem, zanim zrobią to użytkownicy.

Przykład rekordu SOA dla typowej strefy

Kompletny rekord SOA w składni pliku strefy, z licznikami czasu z powyższej tabeli:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
        2026082601  ; serial  (YYYYMMDDnn)
        3600        ; refresh (1 hour)
        900         ; retry   (15 minutes)
        1209600     ; expire  (2 weeks)
        300 )       ; minimum (negative caching TTL, 5 minutes)

3600 przed IN to TTL samego rekordu SOA — jak długo resolwery mogą go buforować. Ogranicza on też od góry TTL negatywnego buforowania: przy 3600 tutaj i minimum 300 resolwery buforują odpowiedzi NXDOMAIN przez 300 sekund — mniejszą z dwóch wartości.

Jeśli korzystasz z panelu hostingowego lub interfejsu WWW dostawcy DNS, rekord SOA jest zwykle generowany za Ciebie, a numer seryjny zwiększa się automatycznie przy każdym zapisie. Mimo to warto raz sprawdzić wartości liczników: niektóre panele ustawiają expire na jeden dzień, co po cichu unieważnia każdy serwer wtórny, który dodasz później.

Powiązane przewodniki

Rekord SOA to mechanizm; te przewodniki opisują, czemu on służy:

- Redundancja DNS: dlaczego ma znaczenie i jak ją osiągnąć - Jak działają transfery stref AXFR - Jak skonfigurować wtórny serwer DNS