O interogare inversă mapează un RR pentru un domeniu. Un exemplu de acest gen de query ar fi: “Care este numele de domeniu pentru acestă înregistrare de tip MX?”. Totuşi acest fel de interogări au fost întotdeauna un serviciu opţional pentru DNS, iar name serverele puteau livra un răspuns NOTIMP (Not implemented). Prima oară eşti tentat să zici că acest fel de interogări află hostul în funcţie de un IP. Dar acest proces de fapt se cheamă reverse mapping sau reverse lookup şi foloseşte interogări recursive şi iterative cu un domeniu special IN-ADDR.ARPA.

DNS Reverse Mapping

Până acum am vorbit despre interogări normale de tipul “îţi dau numele hostului, află-mi IP-ul”, dar trebuie să discutăm şi despre cele de genul “îţi dau IP-ul, află-mi hostul”. Aceste tipuri de queries sunt folosite din motive de securitate. De exemplu, multe sisteme de mailing folosesc acest feature  de reverse mapping pentru a asigura o atentificare corectă.
Astfel, pentru a putea implementa reverse mapping-ul folosinf interogări normale recursive şi nerecursive (iterative), băieţii au definit un domeniu special numit IN-ADDR.ARPA.

Trebuie să discutăm un pic despre acest domeniu.

Structura normală a unui nume de domeniu porneşte cu de la “root”. Un nume de domeniu este scris de la stânga la dreapta, dar structura acestuia se desfăşoara de la dreapta la stânga: nume_de_domeniu = www.alexbobica.com
Cea mai înaltă “structură de stat” din domeniul de mai sus este TLD-ul (Top-Level Domain) .com; următoarea în grad este .alexbobica (Second-Level Domain); lebăda cea slabă şi urâtă este www, care de fapt reprezintă numele hostului şi este definit într-un fişier zonă.
Pentru a putea folosi o adresă IPv4 într-o interogare trebuie să o traducem într-un nume de domeniu. Să zicem că avem următorul IP: 192.168.100.15. Acest IP defineşte o adresă de host, 15, în reţeaua 192.168.100.x. În acest caz, cea mai importantă parte se află la stânga şi nu la dreapta, adică 192.
Soluţia este simplă. Pentru a creea un nume de domeniu, inversează ordinea adresei şi foloseşte ca şi SLD partea cu IN-ADDR iar ca TLD partea cu ARPA. Ce rezultă?

IPv4: 192.168.100.15
Network: 192.168.100 – omitem hostul (15)
Inversul network-ului: 100.168.192
Adăugăm în domeniul IN-ADDR.ARPA: 100.168.192.IN-ADDR.ARPA

Am terminat? Nu. Mai trebuie să creăm şi un fişier zonă care să descrie toate hosturile folosind RR-uri de tip PTR. Fişierul zonă va arăta ceva de genul:

$TTL  2d
$ORIGIN  100.168.192.IN/ADDR.ARPA
@      IN      SOA      ns1.alexbobica.com. hostmaster.alexbobica.com.  (
2009012700 ; sn = serial number
12h             ; refresh
15m            ; retry
3w              ; expiry
2h              ; min = minimum
)
IN      NS      ns1.alexbobica.com.
IN      NS      ns2.blogoperativa.com.
5     IN      PTR     ns1.alexbobica.com.
15   IN      PTR     www.alexbobica.com

That’s all folks…for now! To be continued!

name      ttl      class      rr      ipv4

Hai să dăm şi un exemplu de folosire:

ns1        IN      A      192.168.100.1
mail      IN      A      192.168.100.2
alex      IN      A      192.168.100.3
www     IN      A    192.168.100.4

Atributele folosite în sintaxa resursei sunt aceleaşi ca şi în cazul celorlalte RR-uri, aşa că nu are rost să mai repetăm încă o dată acelaşi lucru. Singurul care rămâne neexplicat este atributul ipv4, dar sunt sigur că ştiţi despre ce este vorba. Da, aţi ghicit, este vorba despre clasica adresă de IP pe care o ştim cu toţii.

Vă amintiţi cum declaram RR-urile de tip NS şi MX? Dacă da, mai trebuie să mai ştiţi un lucru. Acele “name-uri” din declararea resurselor (mail sau ns1) trebuie să aibă o intrare de tip A corespunzătoare. Să fiu mai clar…Orice host pe care vrem să îl facem vizibil public, trebuie definit printr-o intrare de tip A.

Este permis de asemenea să avem acelaşi IP asignat pe mai multe nume. Dacă să zicem că ţinem un web server şi un name server pe aceeaşi maşină va trebui să adăugăm intrările de tip A următoare:

ns1      IN      A       192.168.100.2
mail    IN      A       192.168.100.3
alex    IN      A       192.168.100.4
www   IN      A     192.168.100.2

Poate unii dintre voi vă întrebaţi dacă este permis să avem mai multe adrese IPv4 pentru un singur host. Normal că da. Ok. Păi şi atunci ce IP ne livrează aplicaţia de DNS când o întrebăm despre IP-ul hostului respectiv? Care dintre adresele IP ni se trimite? Păi softul de DNS ne poate trimite adresele random sau poate face load balancing (round-robin).

Resource Record de tip CNAME

CNAME-ul defineşte un alias pentru un host deja existent şi definit de un A RR.

Sintaxa prin care creăm un alias este:  name      ttl      class      rr      canonical-name

Şi repede băgăm un exemplu:   ftp      IN      CNAME      ftp.blogoperativa.com.

Prin ce am scris mai sus am creat un alias pentru ftp.blogoperativa.com., şi anume ftp.alexbobica.com.. Am considerat directiva $ORIGIN ca fiind alexbobica.com.. Atributului canonical-name din sintaxa de mai sus i se mai spune şi “real name”.

Resursele CNAME sunt folosite atunci când asignăm un nume de serviciu unui host, de exemplu, dacă un host se cheamă alex şi pe el rulează un server web şi unul de ftp, atunci pentru a defini aceste două servicii folosim CNAME-urile:

ftp          IN      CNAME      alex
www      IN     CNAME       alex
alex       IN     A                    192.168.100.2

În general, doar două cazuri necesită neapărat folosirea de intrări CNAME. Atunci când un “real name” face parte dintr-un domeniu extern şi atunci când vrem “să apelăm” un site folosind “www.alexbobica.com” şi “alexbobica.com”.

Pentru cel de-al doilea caz, aveţi exemplul de mai jos:

;  definim IP-ul în care este rezolvat alexbobica.com
IN        A                      192.168.100.2
; creăm aliasul www.alexbobica.com care pointează înspre alexbobica.com
www           IN        CNAME          alexbobica.com.
Cam atât deocamdată despre aceste două resurse. Bineînţeles că ar fi mult mai multe lucruri de spus, dar vom vorbi despre ele pe parcurs.

Va urma…

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.

Configurarea greşită a unui zone file poate face un domeniu unreachable, trimiterea mailurilor să fie total anapoda şi chiar redirectarea clienţilor tăi spre un site concurent cu cel al tău. Fără glumă şi vorbind foarte serios, poţi intra în necazuri mari greşind aici. Gândiţi-vă că răspunsurile la queries venite dinspre un DNS prost configurat pot fi păstrate în cache de către alte sisteme DNS ore, zile şi chiar săptămâni. Remedierea unor astfel de probleme ia mult timp de obicei…şi gândeşte-te cam cum ar reacţiona un client de-al tău dacă nu ar putea folosi anumite servicii. Ar fi un adevărat dezastru.

În acest material m-am gândit să vorbim puţin despre RR-urile şi directivele folosite într-o zonă. Să începem discuţia cu stabilirea formatului unei zone.

Fişierele zonă sunt fişiere text care pot fi citite sau editate folosind orice editor standard. Ele pot conţine trei tipuri de intrări:

- comentarii: toate aceste comentarii încep cu “;” şi continuă până la sfârşitul unei linii.

- directive: încep cu simbolul “$” şi sunt folosite pentru a controla procesarea unui fişier zonă.

- resource records (RR-uri): sunt folosite pentru a putea defini caracteristicile, proprietăţile sau entităţile unui domeniu. RR-urile se pot pune doar pe o singură linie, cu menţiunea că intrările închise de paranteze se pot întinde pe mai multe linii.

; exemplu comentariu

$TTL 12h      ;directivă

$ORIGIN example.com.

; SOA (Start of Authority) record – defineşte zona

; exemplu de RR care se întinde pe mai multe linii

; folosind parantezele

@      IN      SOA      ns1.alexbobica.com.      hostmaster.alexbobica.com.      (

2008102800   ;   se = serial number

3h                   ;   ref = refresh

15m                ;   ret = update retry

3w                  ;    ex = expiry

2h20m            ;   min = minimum

)

; un RR pe o singură linie

IN      NS      ns1.alexbobica.com.

s.a.m.d

În general fişierele zonă conţin următoarele RR-uri şi directive:

-directiva $TTL: defineşte noţiunea de TTL(Time to Live) – perioada pe care un server de DNS poate păstra în cache un RR. Această directivă este obligatorie

- directiva $ORIGIN: defineşte domain name-ul pentru zona respectivă. Directiva este opţională.

- SOA RR: trebuie să apară ca primul RR într-un fişier zonă şi descrie caracteristicile globale ale unei zone sau ale unui domeniu. Acest RR este obligatoriu.

- Name Server(NS) RR: defineşte name serverele care sunt autoritare pentru zona sau domeniul respectiv. Trebuie să fie minim două NS RR într-un fişier zonă. RR-urile de tip NS pot “descrie” name servere din acelaşi domeniu sau din alt domeniu extern. RR-urile NS sunt obligatorii.

- The Mail Exchange (MX) RR: definesc serverele de mail din domeniu. Acest RR este opţional.

- The Address (A) RR: se foloseşte pentru a defini toate adresele IP ale hosturilor (sau serviciilor) care există în zonă şi trebuiesc să fie publice. Ne referim la adrese IPv4…cele IPv6 sunt definite folosind RR-ul AAAA (numit şi Quad A RR). Acest tip de RR este opţional.

- The CNAME RR: cu ajutorul acestor RR-uri definim aliasurile – cu un nume alias putem apela un alt host. Şi acest RR este opţional.

Mai există şi alte tipuri de Resource Records dar cele enumerate mai sus pot defini un fişier zonă complet funcţional.

Cam atât deocamdată…în următoarele articole related to DNS vom aprofunda toate aceste RR-uri şi vom mai încerca câteva exemple de configurare a unul fişier zonă.

Un sistem DNS include trei componente:

1. date ce descriu domeniile (zone files)

2. unul sau mai multe servere de DNS

3. un resolver

Un singur name server poate suporta unul sau mai multe domenii. Datele pentru fiecare domeniu, sau zonă, descriu proprietăţile globale ale unui domeniu şi hosturile (sau serviciile). Aceste date sunt sub formă de text – Resource Records (RRs) – şi sunt organizate în zone files.

Formatul acestor fişiere zonă şi a RRs-urilor este standardaizat, deci este folosit în orice aplicaţie de DNS. Ce face un software DNS? Păi să vedem:

- citeşte fişierele zonă (zone files)

- citeşte un fişier de configurare, primind tot felul de instrucţiuni de la acest fişier. Ex.: să facă cache sau nu.

- răspunde requesturilor (queries) de la clienţii locali sau cei remote.

Să ne întoarcem la componentele sistemului DNS şi să stabilim ce este un resolver. Chestia asta este o aplicaţie sau o librărie care este instalat(ă) pe fiecare host şi care este în stare “să traducă” requestul unui user. Ex. : requestul pentru www.alexbobica.com va fi “tradus” de către resolver într-un query spre serverul de DNS. Deşi acest resolver este ceva foarte complex, cele instalate pe sistemele Windows sau *nix sunt doar nişte “stub resolvers”, adică presupun o implementare mai simplă. Mai pe înţelesul tuturor, un web browser foloseşte o librărie de stub resolver pentru “a transforma” un URL într-o adresă IP.

Cele mai importante din acest material sunt fişierele zonă (zone files). Rolul lor este “să împartă” numele de domeniu în nişte entităţi operaţionale (hosturi, servere de mail, servicii). Un zone file descrie acea parte dintr-un domeniu care este utilizată de către aplicaţia de DNS.

Fişierele zonă conţin următoarele tipuri de Resource Records (RRs):

1. Start of Authority (SOA) Resource Record – o intrare obligatorie în orice zone file

2. Address (A) Resource Records – toate hosturile din acea zonă

3. MX Resource Records – serverele de mail din domeniu

4. NS Resource Records – name serverele autoritare pentru domeniul respectiv

Închei acest material cu un exemplu de zone file. În următoarele materiale despre DNS vom detalia fiecare linie din înşiruirea de mai jos…

$TTL 2d    # TTL-ul default pentru zonă

$ORIGIN alexbobica.com.

#SOA record – reprezintă caracteristicile principale ale zonei

@    IN    SOA    ns1.alexbobica.com.  hostmaster.alexbobica.com.  (

2008101001 ; sn = serial number

12h               ; refresh

15m              ; retry = update retry

3w                ; expiry

2h                ; min = minimum

)

; NS RRs pentru domeniu

IN    NS    ns1.alexbobica.com.

; mail server RRs pentru zonă

3w  IN    MX   10   mail.alexbobica.com.

;hosturi din domeniu (acestea sunt inclusiv serverele de mail sau DNS)

ns1    IN    A    192.168.100.1

mail   IN    A    192.168.100.2

alex   IN    A    192.168.100.3

Sper că aţi înţeles câte ceva din ce am încercat să dezvolt aici. Oricum pe parcursul viitoarelor materiale, lucrurile vor deveni din ce în ce mai clare şi mai logice.

Alex

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!