Co to jest rekord SOA w DNS?

DNS
Opublikowane przez

Jeśli kiedykolwiek przeglądałeś rekordy DNS domeny za pomocą dig lub narzędzia online, prawdopodobnie natrafiłeś na rekord SOA, nie do końca wiedząc, do czego służy. To jeden z najważniejszych rekordów w każdej strefie DNS: definiuje, kto ma autorytet nad strefą, jak serwery DNS wtórne powinny się synchronizować i jak długo dane pozostają aktualne w razie awarii serwera głównego.

Co zawiera rekord SOA

SOA to skrót od Start of Authority. Każda strefa DNS musi zawierać dokładnie jeden rekord SOA. Znajduje się zawsze na szczycie strefy i zawiera siedem odrębnych pól. Oto jak wygląda typowy rekord SOA:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Omówmy każde pole:

  • MNAME (ns1.example.com.): główny autorytatywny serwer DNS strefy. To serwer, z którym kontaktują się serwery wtórne, aby pobrać aktualizacje
  • RNAME (admin.example.com.): adres email administratora strefy, ale z kropką zamiast @. Tu odpowiada [email protected]. Jeśli część lokalna zawiera kropkę, trzeba ją escapować backslashem (imie\.nazwisko.example.com.)
  • Serial (2025052901): numer wersji strefy. Każda zmiana musi zwiększyć ten numer, inaczej serwery wtórne nie wykryją aktualizacji. Typowy format to RRRRMMDDNN (data plus dzienny licznik)
  • Refresh (7200): interwał w sekundach między sprawdzeniami przez serwery wtórne. Tu co 2 godziny
  • Retry (3600): czas oczekiwania przed ponowną próbą, jeśli sprawdzenie Refresh się nie powiedzie. Tu 1 godzina
  • Expire (1209600): czas, po którym serwer wtórny przestaje odpowiadać za strefę, jeśli nie może skontaktować się z głównym. Tu 14 dni. Po tym terminie serwer wtórny uznaje swoje dane za przeterminowane i przestaje obsługiwać strefę
  • Minimum TTL (86400): od RFC 2308, to pole określa, jak długo odpowiedzi negatywne (NXDOMAIN) są buforowane. Tu 24 godziny. Jeśli ktoś zapyta o nieistniejącą subdomenę, resolver zapamiętaj odpowiedź "nie istnieje" na 24 godziny

Dlaczego numer seryjny jest tak ważny

Serial to prawdopodobnie pole, które w praktyce sprawia najwięcej kłopotów. Gdy serwer wtórny kontaktuje się z głównym podczas cyklu Refresh, porównuje swój lokalny numer seryjny z tym na serwerze głównym. Jeśli numer na głównym jest wyższy, wtórny uruchamia transfer strefy (AXFR lub IXFR), żeby się zaktualizować. Jeśli numer się nie zmienił, nic nie robi.

Klasyczny błąd: zmiana rekordu DNS na serwerze głównym bez zwiększenia seriala. Efekt: główny ma poprawną wersję, ale wtórne serwują starą przez godziny lub dni. Użytkownicy dostają różne odpowiedzi w zależności od tego, który serwer zapytają, a problem jest trudny do zdiagnozowania, jeśli nikt nie pomyśli o sprawdzeniu SOA.

Format RRRRMMDDNN to konwencja, nie wymóg. Serial to 32-bitowa liczba całkowita, więc każda wartość od 0 do 4 294 967 295 działa. Format datowy jest jednak zalecany, bo czyni błędy widocznymi: serial 2025052901 to wyraźnie pierwsza zmiana z 29 maja 2025.

Jak współdziałają Refresh, Retry i Expire

Te trzy wartości tworzą system odporności dla stref DNS. Refresh wyznacza normalny rytm synchronizacji. Retry wchodzi w grę, gdy Refresh zawiedzie. Expire to ostatnia deska ratunku: po upływie tego czasu bez kontaktu z serwerem głównym, wtórny woli w ogóle nie odpowiadać niż serwować potencjalnie nieaktualne dane.

Dla standardowej domeny RFC 1912 zaleca:

  • Refresh: 3 600 do 86 400 sekund (1 godzina do 24 godzin)
  • Retry: 600 do 3 600 sekund (10 minut do 1 godziny)
  • Expire: 1 209 600 do 2 419 200 sekund (2 do 4 tygodni)
  • Minimum TTL: 3 600 do 86 400 sekund (1 godzina do 24 godzin)

Jeśli strefa zmienia się często (np. CDN lub infrastruktura z dynamicznym load balancingiem), zmniejsz Refresh do 300 lub 600 sekund. Jeśli jest stabilna, 86 400 sprawdza się doskonale i zmniejsza obciążenie serwera głównego.

Jak sprawdzić rekord SOA domeny

Na Linuksie i macOS polecenie dig jest najprostsze:

dig SOA example.com

Na Windows użyj nslookup:

nslookup -type=SOA example.com

Odpowiedź pokazuje wszystkie siedem pól SOA. Szczególną uwagę zwróć na serial: jeśli wygląda na stary lub zamrożony, to często przyczyna, dlaczego zmiany DNS nie propagują się poprawnie.

Częste błędy w SOA

Kilka problemów spotykanych regularnie w praktyce:

  • RNAME używa @ zamiast kropki, co łamie składnię. [email protected] musi być zapisane jako admin.example.com. w SOA
  • Serial zostaje przypadkowo zmniejszony po przywróceniu kopii zapasowej. Serwery wtórne odmówią synchronizacji, dopóki serial na głównym nie wróci powyżej ich lokalnej wartości
  • Expire jest zbyt krótki (kilka godzin). Jeśli główny padnie w weekend, wtórne przestają odpowiadać, zanim ktokolwiek zdąży zainterweniować
  • Minimum TTL ustawiony na 0 oznacza, że resolwery nie buforują odpowiedzi negatywnych. Każde zapytanie o nieistniejącą subdomenę generuje pełny round trip, co może przeciążyć serwery DNS podczas skanowania lub ataku
Rekord SOA rzadko edytuje się jako pierwszy przy konfiguracji domeny, ale to on często wyjaśnia, dlaczego "DNS się nie propaguje". Zanim zaczniesz szukać skomplikowanych przyczyn, sprawdź, czy serial został poprawnie zwiększony i czy wartości Refresh i Expire odpowiadają twojemu zastosowaniu.