Nu am vorbit cam demult despre aplicaţia de DNS. Aşa că era timpul să continuăm cu materialele dedicate acestui subiect.

Să zicem că avem mai multe name servere. Ar fi foarte ok pentru noi dacă o singură sursă ar putea “updata” toate aceste servere. La ce mă refer? La menţinerea acurateţii zonelor şi la transferul acestora de la un server master la unul slave.

Dacă pe la începuturi  zonele se transmiteau în full (AXFR) din cauză că şi “sedentarismul” Internetului permitea acest lucru, după ceva timp, această metodă de transfer a devenit nefiabilă. Astfel, s-au implementat IXFR-ul (incremental zone transfer) şi mesajele NOTIFY ajungându-se până la DDNS (dynamic update).

Poate pentru unii dintre voi a devenit acum mai clar conceptul de DNS poisoning despre care am vorbit în unele materiale related to IT security. Ce presupune această formăde atac? Un server de DNS slave este “bulit” , scuzată-mi fie expresia, de transferuri de zone de la un server master maliţios.

Să începem să vorbim despre transferul full de zone, şi anume AXFR.

Prin RFC-urile 1034 şi 1035 se stabileşte faptul că name serverele secundare pentru nişte zone vor “interoga” master serverele pentru transferul zonelor respective. Timpul după care secundarele întreabă “principalele” este setat de variabila refresh. Cum se procedează mai exact? Slave-urile trimit un querry către masterul unei anumite zone cerând SOA RR-ul. Dacă serial number-ul deţinut de către slave server este mai mic decât cel obţinut de pe master, atunci are loc un trasfer full de fişier zonă. De aceea, este foarte important ca după fiecare modificare făcută într-un fişier zonă să incrementăm şi acest serial number despre care am vorbit în materialele anterioare.

Mai este un lucru de spus despre acest tip de transfer, şi anume că AXFR-ul foloseşte portul TCP 53.

Incremental zone transfer (IXFR)

Transferul de zone întregi poate consuma multe resurse şi bandwidth şi este un pic cam nefolositor dacă de exemplu schimbăm doar o intrare de tip A într-o zonă. Din cauza acestui neajuns, s-a standardizat prin RFC-ul 1995 acest IXFR, care ce este de fapt? Este transferul înregistrării care se modifică într-un fişier zonă. În rest funcţionează cam la fel cu AXFR-ul. Slave-ul trimite un querry înspre master după un timp stabilit prin valoarea refresh-ului, iar dacă serial numberul de pe master este mai mare decât cel deţinut de către slave, transferul IXFR are loc, bineînţeles dacă ambele servere suportă acest feature. Dacă nu, este înlocuit de către transferul AXFR.

Modul de operare default al BIND-ului pe un slave name server este să ceară transfer IXFR, iar master slave-ul trimite IXFR by default numai în cazul zonelor dinamice.

Trebuie să mai precizăm că timpul de propagare al schimbărilor într-un fişier zonă rămâne neschimbat indiferent de modul de transfer utilizat. Singura diferenţă constă în volumul de date transferat între master şi slave.

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!

1. răspunsul la interogare însoţit de orice CNAME ce ar putea fi folositor, şi tot de aici vom afla dacă răspunsul este autoritar sau cached.
2. o eroare care ne spune că domeniul sau hostul nu există (NXDOMAIN). Şi acest răspuns poate conţine CNAME-uri înspre hostul inexistent.
3. o eroare temporară.
4. o trimitere la o listă de două sau mai multe name servere care sunt mai aproape de domeniul respectiv. Această trimitere (sau referral) este răspunsul tipic folosit de către root servere şi serverele TLD.

Se dă un query de genul “Ce IP are următoarea adresă web: www.alexbobica.com?” şi să presupunem că acest query merge înspre un name server care suportă interogările iterative şi nu este autoritar pentru alexbobica.com.

1. Gigel bagă repede în browser “www.alexbobica.com”.
2. Browser-ul trimite un request pentru IP-ul lui www.alexbobica.com pentru resolver.
3. Resolver-ul trimite mai departe query-ul înspre name serverul local.
4. DNS-ul local nu are cache-uit IP-ul pentru www.alexbobica.com dar trimite ca şi răspuns o listă (referral) cu root serverele.
5. Resolver-ul trimite interogarea spre un root server din lista repesctivă.
6. Root server-ul trimite înapoi la rândul lui o listă cu serverele care sunt autoritare pentru “.com”.
7. Resolver-ul alege un server şi trimite query-ul direct spre el, şi nu spre name server-ul local.
8. Server-ul trimite o listă cu serverele autoritare pentru SLD-ul (second level domain) alexbobica.com.
9. La fel ca la pasul 7, resolver-ul trimite direct înspre unul dintre serverele de la punctul 6 query-ul respectiv pentru www.alexbobica.com.
10. Şi cam gata…

Ne oprim aici că deja îmi cam pică dinţii în gură de somn.

Vă salut!

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…

Acest RR este standardizat prin RFC-ul 1035 şi defineşte name serverele autoritare (trebuie neapărat să fie două) pentru domeniu sau zonă. Sintaxa prin care adăugam RR-ul este:

name      ttl      class      rr      name

Extragem bucata referitoare la NS RR din exemplul pe care l-am introdus într-un material anterior.

;  NS RR pentru domeniu
IN      NS      ns1.alexbobica.com.
; al doilea name server este
; extern acestei zone (domeniu).
IN      NS      ns2.blogoperativa.com.

Atributul name, în cazul nostru, este lăsat gol. De ce? Pentru că substituie câmpul name din RR-ul SOA. Puteam de exemplu să scriem ceva de genul: alexbobica.com.      IN      NS      ns1.alexbobica.com.

TTL nu am definit, deci implicit avem valoarea default a zonei ($TTL) care este egalå cu 2d. Proprietatea class are valoarea IN, pe care am explicat-o în materialul trecut.
name defineşte name serverul care este autoritar pentru domeniu. În exemplul de mai sus am folosit formatul FQDN pentru numele serverului, dar puteam scrie doar ns1, fără “.” după, iar valoarea $ORIGIN era adăugată automat. Să fiţi atenti să adăugaţi la sfârşit acel “punct”, pentru că dacă, de exemplu, nu aţi adăuga “punct” după ns2.blogoperativa.com, ar rezulta ceva de genul ns2.blogoperativa.com.alexbobica.com. Şi nu cred că v-aţi fori aşa ceva.

MX Resource Record

RR-ul MX defineşte serverele de mail pentru domeniul sau zona respectivă. Sintaxa este următoarea:

name      ttl      class      rr      preference      name

Să extragem din nou porţiunea din exemplu care ne descrie acest tip de RR.

; RR-ul MX pentru zonă (domeniu)
3w      IN      MX      10      mail.alexbobica.com.
; al doilea server de mail
IN      MX      20      mail.blogoperativa.com.

Câmpurile despre care am mai vorbit, nu le mai dezvolt aici. În schimb vom detalia parametrul preference. Chestia asta este un fel de prioritizare a serverului de mail. Poate lua valori între 0 şi 65535. Cu cât este numărul mai mic, cu atât este mai “important” serverul de mai respectiv. Aţi înţeles ideea sper. După cum se vede din output-ul de mai sus, prioritar este serverul mail.alexbobica.com. .Cel cu preference-ul 20 este un mail server de backup. Adică în caz de failure, preia “frâiele”. Recomandabil este ca acest backup server să se afle într-o locaţie diferită faţă de primul, astfel asigurîndu-se un fel de redundanţă a serviciului de mail.

Continuăm next time cu ce trebuie. Salutare!

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!