Data trecută în cadrul serialului “DNS” am vorbit despre directiva $TTL. Astăzi vom merge mai departe şi vom vorbi despre alte două elemente ce fac parte dintr-un fişier zonă.

Directiva $ORIGIN este standardizată prin RFC-ul 1035 şi defineşte numele de domeniu ce va fi “alăturat” oricărui nume incomplet (numit şi unqualified name) definit într-un RR. Acest proces prin care se “adaugă” o valoare oricărui nume care nu se termină “printr-un punct (.)” a reprezentat, reprezintă şi va reprezenta o sursă de confuzie şi o grămadă de nervi.

Despre ce este vorba? Păi dacă avem un nume ce apare într-un Resource Record şi nu se termină cu un (.), atunci ultima directivă $ORIGIN sau singura care există va fi adăugată acestui nume. Dacă numele se finalizează cu un (.) atunci avem de a face cu un FQDN (Fully Qualified Domain Name) şi nu va fi adăugat nimic acestuia. Punctul care “închide” un FQDN mai este numit şi root-ul acestui domain tree.

Sintaxa acestei directive este:

$ORIGIN domain-name

Dacă ne întoarcem la ultimul exemplu de zone file avem de a face cu $ORIGIN alexbobica.com.

“Variabila” domain-name din sintaxa de mai sus este întotdeauna un FQDN (adică se termină cu “punct”).

Directivele $ORIGIN se pot folosi în orice moment şi în orice loc într-un fişier zonă. Un exemplu mai jos:

$ORIGIN alexbobica.com.
;toate RR-urile de aici începînd li se va adăuga alexbobica.com.
….
….
$ORIGIN blogoperativa.com.
;toate RR-urile de aici începînd li se va adăuga blogoperativa.com.

Totuşi (bineînţeles că există un “totuşi” ) această directivă nu este obligatorie. BIND-ul (aplicaţia de DNS) va lua ca şi valoare a acestei directive numele zonei definit în fişierul de configurare, adică named.conf (o să vorbim şi despre acesta very soon).

SOA Resource Record

Acest RR (foarte important) defineşte caracteristicile cheie şi atributele pentru zonă sau domeniu şi este standardizat prin RFC-ul 1035. Sintaxa pentru SOA RR este următoarea:

name ttl class rr name-server e-mail sn refresh retry expiry min

Ne întoarcem din nou la fişierul zonă dat exemplu în materialele anterioare şi “scoatem” de acolo acest SOA RR:

@ IN SOA ns1.alexbobica.com. hostmaster.alexbobica.com. (
2008111800 ; sn = serial number
3h ; refresh time
15m ; retry = update retry
3w ; expiry
3h ; min = minimum
)

Avem două reguli în ceea ce priveşte acest RR:

- de obicei este definit prin mai multe linii şi în acest caz trebuie să folosim parantezele “( )” dar poate fi scris şi într-o linie.

- ca să separăm field-urile putem folosi “space” sau “tab”. De obicei se foloseşte “tab-ul” pentru a păstra un layout mai curat şi pentru a observa mai uşor, când este cazul, câmpurile lipsă.

Să analizăm puţin chestiile care apar în sintaxa SOA RR.

Avem name. În exemplul nostru, noi folosim simbolul “@” ce ţine locul valorii curente a directivei $ORIGIN.
Urmează apoi ttl. Nu avem definit nimic pentru acest parametru, aşa că se foloseşte valoarea default pentru zonă (2d sau 172800 secunde) derivată din $TTL.
La rând class. În exemplu folosim ca şi valoare pentru acest atribut IN, adică defineşte clasa ca fiind Internet.
Ce este cu atributul name-server? Presupun că vă daţi seama că se referă la Primary Master name server pentru zona respectivă. În cazul nostru este vorba despre ns1.alexbobica.com.
Name serverul definit aici trebuie apelat de asemena şi printr-un RR de tip NS. Vom vorbi şi despre acesta.
Avem apoi e-mail. Defineşte adresa de e-mail administrativă pentru această zonă. In our case: hostmaster@alexbobica.com.

Urmează acum sn, sau serial numberul asociat cu acestă zonă. Acest serial number trebuie updatat de fiecare dată când operăm o schimbare în domeniu şi poate lua orice valoare între 0 şi 4294967295. Prin convenţie se foloseşte un format de genul yyyymmddss. Adică anul, luna, ziua şi un număr care se incrementează dacă se operează mai multe schimbări în aceeaşi zi. Această valoare a sn-ului este folosită în operaţiile de transfer ale zonelor pentru a ne da seama dacă o zonă a fost schimbată sau nu.

Refresh-ul este o valoare care atunci când este atinsă, name serverul slave pentru această zonă va încerca şi va citi RR-ul SOA de pe name serverul master. Dacă valoarea sn-ului este mai mare decât cea de pe slave, o operaţiune de transfer de zonă este iniţiată.

Atributul expiry defineşte timpul în secunde după care înregistrările unei zone nu mai sunt autoritare. Ce înseamnă pentru BIND acest lucru? Că înregistrările nu mai sunt valide şi nu mai răspunde diferitelor queries pentru zona respectivă. De aceea când acest expiry time este atins, slave name serverul va încerca să “contacteze” master name serverul pentru zona respectivă, iar în cazul unui eşec va repeta încercarea la fiecare interval de timp definit prin atributul retry.  Dacă contactul este realizat, contorizarea atributelor refresh şi expiry se va reseta. În schimb dacă acest contact nu este realizat şi timpul definit prin expiry a fost atins, slave-ul se va opri din a răspunde oricărui query venit de la clienţi.

Şi în sfârşit ultima caracteristică, min-ul, defineşte perioada de timp în care răspunsurile negative pot fi “cached” de către slave name server.

Cam atât. Deocamdată. O să continuăm cu restul “piticilor” peste câteva zile.

Vă salut!