Dalej Wyżej Poprzednio Spis treści indeks
Dalej: Rekord NS Wyżej: Standardowe rekordy baz danych Poprzednio: Standardowe rekordy baz danych

Rekord SOA

   Format rekordu SOA jest następujący:
[zone] [ttl] IN SOA origin contact (
serial
refresh
retry
expire
minimum
)

Znaczenie poszczególnych pól jest następujące:

zone
nazwa domeny; Najczęściej w tym miejscu (rekord wpisujemy tylko na komputerze będącym nameserwerem głównym!) wpisuje się znak ,,@'' (at) - tak użyty nawiązuje on do nazwy domeny użytej w dyrektywie primary znajdującej się w pliku named.boot a kierującej do pliku zawierającego rekord SOA.
ttl
czas ważnowści rekordu - zawsze pozostawia się puste.
origin
nazwa komputera będącego serwerem pierwotnym dla domeny; zwykle wpisywana jako pełna nazwa komputera (FQDN - Fully Qualified Domain Name).
contact
adres osoby odpowiedzialnej za domenę. Adres jest zmodyfikowany w ten sposób, że znak ,,@'' oddzielający nazwę użytkownika od nazwy komputera zastępuje się kropką. Zatem adres hostmaster@immt.pwr.wroc.pl zapisany będzie jako hostmaster.immt.pwr.wroc.pl. Najczęściej w przykładach znajdujących się w dokumentacji nazwa użytkownika to hostmaster. Proszę nie zapominać o powiązaniu tego adresu z adresem fizycznej osoby czytającej (i odpowiadającej) na pocztę. Można tu wpisać adres dowolnej osoby. Nie musi on znajdować się na komputerze wymienionym w polu origin.
serial
numer wersji danych zawartych w pliku. Powinna to być liczba całokwita (niektóre, stare wersje programu named mają kłopoty z liczbami zawierającymi kropkę dziesiętną). Trudno zalecić jakąś zasadę numerowania wersji: doświadczenie uczy, że jeżeli wybierzemy jakąś zasadę - powinniśmy się jej trzymać. Zwłaszcza trzeba pamiętać, żeby numery wersji rosły. Znam przypadek, gdy jeden z administratorów zmienił zasady numeracji - rozpoczął ją w pewnym momencie od zera. Oczywiście znalazł się w sieci komputer, który był serwerem wtórnym tej domeny (nie został co prawda wyznaczony do tej roli). W plikach miał stary numer wersji i nie przyjmował nowej zawartości plików o niższych numerach wersji.

Bardzo dobrym zwyczajem jest numerowanie kolejnych wersji datą: rrmmddv (jednocyfrove pole v pozwala na odnotowywanie drobnych zmian robionych jednego dnia), na przykład 1995050101.

refresh
określa czas (w sekundach) co jaki serwery wtórne sprawdzają czy nie wzrósł numer wersji informacji pamiętanych na serwerze pierwotnym. Jeżeli numer zwiększył sie - serwer wtórny prosi o przetransferowanie zawartości całego pliku. Jeżeli nie nie podejmuje żadnych działań.

Serwer wtórny zawsze dokonuje takiego sprawdzenia w momencie startu i wtedy, kiedy odbierze sygnał SIGHUP.

Trudno zalecić jakąś konkretną wartość. Należy przyjąć zasadę, że jeżeli planujemy jakieś poważne zmiany i rekonfiguracje sieci, które będą miały istotny wpływ na zawartość baz danych - należy z odpowiednim wyprzedzeniem zmienić (zmniejszyć) ten okres (zmieniając oczywiście numer wersji na większy).

W większości przypadków odświeżanie raz na dobę jest (86400 s) jest wielkością poprawną.

retry
określa jak długe serwer wtórny powinien czekać z powtórną próbą odświeżenia informacji o domenie, gdy poprzednia się nie powiodła. Czas ten nie powinien być zbyt krótki - gdyż zbytnio absorbuje zasoby serwerów wtórnych oraz zasoby sieciowe. Dobrą wartością jest 3600 (godzina) czy 1800 (pół godziny).
expire
liczba ta określa po jakim czasie nieodświeżone dane o domenie poeinny być skasowane z pamięci serwerów wtórnych. Zwykle jest to bardzo duży czas, na przykład 3600000 (ok. 42 dni).
minimum
  liczba określa domniemaną wartość czasu życia (ttl) wszystkich rekordów - o ile nie zadeklarowano inaczej. Dobierając jej wartość należy uwzględniać jeden tylko fakt: jak długo umieszczone w bazie danych informacje będą aktualne. Jeżeli nie planujemy żadnych zmian - wartość może być bardzo duża: 1 tydzień (604800), a nawet 1 miesiąc (2592200). Zwracam jednak uwagę, że przez taki okres dane moga "leżeć" na odleglym serwerze (nie wszystkie komputery na swiecie restartuje się co dwa dni) i jezeli zechcemy dokonać jakichś zmian (nazwa komputera, numer IP) to będziemy w kłopocie. Dlatego też wszelkie istotne zmiany powinniśmy poprzedzić (najlepiej z wyprzedzeniem większym niż ttl) zmianą ttl na niewielka wartość (doba, kilka godzin) i dopiero robić zmiany. Nie ma potrzeby dokonywać takiej zmiany dla całej domeny - można to zrobić dla pojedyńczych rekordów.

Oczywiście długi czas życia rekordów w pamięci cache ma również pewien minus - obciąża pamięć zdalnych serwerów.

Przykładowy rekord SOA: 

@   IN   SOA  ldhpux.immt.pwr.wroc.pl. hostmaster.ldhpux.immt.pwr.wroc.pl. (
                1995050502 ; Serial
                28800      ; Refresh (28800)
                7200       ; Retry
                604800     ; Expire
                86400      ; Minimum TTL 1 day
                )

NASK  (w chwili obecnej zarządca domeny .pl) określił ,,typowe'' wartości dla parametrów rekordu SOA. Można znaleźć je na ich serwerze ftp. Tu zacytuję jedynie podstawowe informacje:

Dalej Wyżej Poprzednio Spis treści indeks
Dalej: Rekord NS Wyżej: Standardowe rekordy baz danych Poprzednio: Standardowe rekordy baz danych

Wojciech Myszka
pią, 14 lis 1997 11:12:41