Salutare naţiuneee! Doarme cineva la ora asta? Hmmm? Aşa…nimeni nu doarme, exact cum credeam.
A venit timpul să continuăm seria dedicată serviciului de DNS cu încă un articol.

Î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.