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!

Întâi de toate să punem repede aici un model de configurare standard a unui fişier zonă. Mai apoi vom lua rând pe rând în materialele care vor urma fiecare RR şi îl vom diseca după bunul nostru plac. Să începem.

$TTL 2d
$ORIGIN alexbobica.com.
@ IN SOA ns1.alexbobica.com. hostmaster.alexbobica.com. (
2008111800
12h
15m
3w
2h
)
IN NS ns1.alexbobica.com.
IN NS ns2.blogoperativa.com.
3w IN MX 10 mail.alexbobica.com.
IN MX 20 mail.blogoperativa.com.

ns1 IN A 192.168.1.2
mail IN A 192.168.1.4
blog IN A 192.168.1.6
www IN A 192.168.1.7
ftp IN CNAME ftp.alexbobica.com.

În acest exemplu, zona alexbobica.com are următoarele caracteristici:

- zona dispune de două name servere, unul hostat în acest domeniu (ns1.alexbobica.com) iar celălalt extern (ns2.blogoperativa.com);

- zona are la dispoziţie două servere de mail, la fel, unul în acelaşi domeniu altul într-un domeniu extern;

- în această zonă este prezent un serviciu web intern www.alexbobica.com;

- mai este prezent şi un server de FTP (ftp.alexbobica.com);

- în zonă este prezent doar un singur host public (blog.alexbobica.com).

Cred că este destul de intuitiv pentru voi din ce cauză avem nevoie de două servere de DNS şi două de mail. Redundanţă. Asta încercăm să obţinem. În mod normal, în cazul companiilor mai mici, cel de-al doilea server, fie el de mail sau name server, se află în acelaşi site. E ok şi aşa…nu este nimic greşit. Dar recomandabil ar fi ca backup-urile pentru mail şi name service să fie furnizate de către maşini exterioare sitului principal. Dar să revenim la RR-urile şi directivele noastre.

Prima directivă despre care o să vorbim mai în detaliu este directiva $TTL.

Această directivă este standardizată prin RFC-ul 2038 şi defineşte valoarea default TTL (Time to Live) pentru orice Resource Record (RR) care nu are un TTL specificat deja. Dar ce înseamnă de fapt TTL în contextul serviciul de DNS? Înseamnă timpul (secunde) în care un name server sau un resolver poate păstra în cache o înregistrare. Sintaxa pentru această directivă este următoarea:

$TTL timpul-în-secunde

În exemplul de mai sus observăm cum este definit acest TTL: $TTL 2d
O să ziceţi: “Păi stai puţin, că tu ai zis că e vorba de secunde.” d este forma scurtă specifică BIND-ului pentru zi (day). Conform RFC 2038 formatul echivalent pentru 2d este $TTL 172800.
Timpul în secunde poate lua valori între 0 (adică nu se face cache) şi 2147483647 (68 de ani adicătelea). Sfatul specialiştilor este ca să folosim o valoarea mai mare de o zi iar pentru RR-urile care se schimbă foarte rar să folosim o valoarea echivalentă mai multor săptămâni.

Această valoare a TTL-ului influenţează două caracteristici operaţionale ale DNS-ului:

-Access load: adică cu cât TTL-ul va fi mai mic, cu atît mai dese vor fi query-urile către DNS server, astfel încărcarea operaţională pe name serverul respectiv va fi mai mare;
- Change propagation: adică replicarea sau propagarea schimbărilor de pe name server către toţi userii. Mda. Ce formulare am găsit şi eu. Vreau să spun că TTL-ul reprezintă timpul maxim în care o schimbare se propagă din DNS server către toţi utilizatorii.

Ca şi sfat pentru utilizarea acestei directive. Atunci când avem de făcut schimbări sau update-uri în zonă, de exemplu intrări de tip A (IP-uri) sau servicii noi adăugate, este recomandabil să setăm acest TTL mai mic (să zicem undeva la 12h sau 43200). După ce terminăm de implementat aceste change-uri putem reveni la o valoare mai mare a TTL-ului.

Directiva $TTL trebuie pusă în faţa oricărui Resource Record (RR) pentru care vrem să fie aplicat.

Şi cu asta punem punct aici. Materialul următor va veni mai repede şi vom continua discuţia cu directiva $ORIGIN şi SOA Resource Record. Vom vorbi despre acestea mai în detaliu decât am facut-o până acum.

Internetul, sau orice altă reţea, funcţionează alocînd un IP local sau global fiecărui endpoint(host, server, router, interfaţă,etc.). Fără această posibilitate de asignare a unui nume unei resurse anume, de fiecare dată când am vrea să accesăm o resursă din reţea, de exemplu situl www.abcdefg.com, ar trebui să ştim adresa ei IP, cum ar fi 192.168.100.122. Cu sute de milioane de hosturi şi cu încă vreo 50 de milioane de situri, este cam imposibil…nu? Ar fi chiar dificil chiar şi pentru câteva zeci de hosturi şi resurse.

Pentru a rezolva această problemă, conceptul de “name servers” a fost creat la mijlocul anilor ’70, astfel încât anumite atribute ale unei resurse, în acest caz adresa IP, să fie păstrate într-o locaţie bine-cunoscută, ideea principală fiind că este mult mai uşor de memorat un nume decât o adresă numerică.

Când într-o reţea este prezent un name server, orice host are nevoie să ştie doar adresa IP a acelui server şi numele resursei, numele unui site de exemplu ce se vrea accesat. Folosind această informaţie, poate afla adresa(sau orice atribut sau proprietate) resursei interogînd (querying) name serverul. Resursele pot fi adăugate, mutate, schimbate, sau şterse într-o singură locaţie, din name server, iar noile informaţii fiind imediat disponibile pentru fiecare host ce foloseşte acest name server. Name serverul este o simplă bază de date ce traduce numele în proprietăţi(adrese IP) şi vice versa. Name serverele simplifică managementul unei reţele şi totodată face ca o reţea să fie mai dinamică şi receptivă la schimbări.

Totuşi pot exista şi probleme…Dacă name serverul nostru nu este disponibil din orice motiv, hosturile din reţea nu pot accesa nicio resursă. Avem de a face astfel cu un name server ca şi resursă critică. Astfel că ar fi bine dacă am avea mai mult de un name server în caz de outage. Soluţia iniţială a disponibilităţii name serverului a fost introducerea de Primary şi Secondary name servere. Aşa de important este acest serviciu de DNS, că astăzi putem vedea liste de câte 3,4 sau mai multe servere de DNS.

Cu cât reţeaua noastră creşte mai mult, începem să construim un număr serios de nume în serverul nostru de DNS. Astfel se ridică 3 probleme importante:

1. Organizare: găsirea unei intrări în baza de date devine din ce în ce mai greoaie când căutăm prin milioane de nume. Ne trebuie o metodă de indexare şi organizare a numelor.

2. Scalability: Dacă fiecare host accesează DNS-ul, încărcătura devine foarte ridicată. Este necesar un procedeu de a “împrăştia” încărcătura pe mai multe name servere.

3. Management: Cu cât creşte numărul de înregistrări în baza noastră de date, problema managementului devine una stringentă, deoarece mai mulţi administratori încearcă să updateze înregistrările în acelaşi timp. Avem nevoie de o metodă de separare(delegating) a administrării acestor nume(resurse).

Nevoia de a satisface aceste 3 cerinţe a condus la crearea şi evoluţia Internet Domain Name System.

Internet’s Domain Name System este o implementare specifică a conceptului de name server, optimizat pentru a face faţă condiţiior din Internet. Avem 3 cerinţe:

-nevoia de ierarhizare a numelor;

-nevoia de împărţire a încărcării operaţionale a name serverelor;

-nevoia de delegări diferite pentru administrarea name serverelor.

Domenii şi delegare

DNS-ul foloseşte o structură de tip tree(ierarhică) pentru nume. În vârful “copacului” este nodul root, urmat de Top-Level Domains (TLDs), apoi de Second-Level Domains (SLD) şi tot aşa…cu câte nivele dorim, fiecare separate de un punct(.).

De cele mai multe ori, root-ul este reprezentat cu un punct(.).

TLD-urile sunt împărţite în două tipuri:

1. Generic Top-Level Domains (gTLD): de exemplu, .com, .edu, .net, .org, .mil, etc.

2. Country Code Top-Level Domains (ccTLD): de exemplu, .us, .ca, .tv, .uk, .ro, etc.

Mai jos aveţi o schemă care sper să fie cât de cât edificatoare în ce priveşte ierarhizarea domeniilor:

Ceea ce denumim în mod curent nume de domeniu, este format dintr-o combinaţie de SLD şi TLD, scris de la stânga la dreapta cu cel mai inferior nivel din ierarhie scris în stânga şi cu cel mai înalt în dreapta: sld.tld .

Termenul de Second-Level Domain vine de la nodul definit la al doilea nivel al ierarhiei. La fel şi cu Third-Level Domain. Să luam un domeniu exemplu: exemplu.com. Care este SLD-ul? Păi SLD-ul este “exemplu”, iar TLD-ul este “com”…iar “punctul” de la sfârşit este chiar root-ul.

Cam atât pentru început despre DNS…sper că aţi înţeles cam ce înseamnă acest serviciu foarte important. O să continuăm în materialele următoare să îl aprofundăm, configurăm, etc.

Numai bine vă urez!