Ce Face DNS și Cum Funcționează?

DNS (Domain Name System) este infrastructura distribuită de denumire a internetului care traduce numele de domenii lizibile de oameni — cum ar fi example.com — în adrese IP lizibile de mașini, precum 93.184.216.34. Fără DNS, fiecare cerere de browser, apel API și livrare de e-mail ar necesita ca utilizatorii și aplicațiile să cunoască adresa numerică exactă a fiecărui host la distanță, făcând internetul modern imposibil de operat la scară.

La baza sa, DNS este o bază de date distribuită global și ierarhică. Nu este un server unic sau un registru centralizat — este un arbore de delegare care cuprinde sute de mii de servere de nume autoritare din întreaga lume, coordonate printr-un set mic de servere rădăcină și guvernate de standarde definite în RFC 1034 și RFC 1035.

De ce DNS este mai mult decât o simplă „Carte de telefon”

Analogia cu cartea de telefon este utilă pentru începători, dar subestimează dramatic ceea ce face DNS în realitate. DNS este un sistem de căutare în timp real, tolerant la erori, replicat global, care gestionează și:

• Rutarea e-mailurilor prin înregistrările MX, direcționând e-mailurile către serverele de e-mail corecte
• Descoperirea serviciilor prin înregistrările SRV, utilizate de protocoale precum SIP, XMPP și rețelele interne Kubernetes
• Verificarea proprietății domeniului prin înregistrările TXT, utilizate pentru SPF, DKIM, DMARC și Google Search Console
• Denumirea canonică prin înregistrările CNAME, permițând integrarea CDN și echilibrarea sarcinii
• Adresarea IPv6 prin înregistrările AAAA
• Căutările inverse prin înregistrările PTR în zona in-addr.arpa, esențiale pentru reputația serverului de e-mail și auditul de securitate
• Validarea DNSSEC, care adaugă semnături criptografice la răspunsurile DNS pentru a preveni otrăvirea cache-ului

De fiecare dată când trimiteți un e-mail, vă conectați la un VPN sau încărcați o aplicație web, DNS rezolvă mai multe tipuri de înregistrări în fundal — adesea zeci de interogări per încărcare de pagină.

Ierarhia DNS: Cum este structurat spațiul de nume

DNS este organizat ca un arbore inversat. Înțelegerea acestei structuri este esențială pentru a înțelege de ce rezoluția funcționează în modul în care o face.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Zona rădăcină (.): Gestionată de IANA. Există 13 adrese logice de servere rădăcină (de la A la M), operate de organizații precum Verisign, NASA și ICANN. În practică, acestea sunt deservite de sute de mașini fizice prin rutare anycast.
• Domenii de nivel superior (TLD-uri): TLD-uri generice precum .com, .net, .org, și TLD-uri cu cod de țară precum .uk, .de, .md. Fiecare TLD are propriul set de servere de nume autoritare.
• Domenii de nivel secundar (SLD-uri): Domeniul pe care îl înregistrați — example.com. DNS-ul autoritar pentru această zonă este controlat de cel care a înregistrat domeniul.
• Subdomenii: www, mail, api, staging — acestea sunt înregistrări în zona SLD, controlate integral de proprietarul domeniului.

Pas cu pas: Cum este rezolvată o interogare DNS

O rezoluție DNS recursivă completă implică până la șapte schimburi de rețea distincte. Iată secvența precisă:

Pasul 1 — Verificarea cache-ului browserului

Când tastați www.example.com în browserul dvs., sistemul de operare verifică mai întâi cache-ul DNS local. Pe Linux, acesta poate fi gestionat de systemd-resolved; pe Windows, de serviciul DNS Client. Dacă există o înregistrare validă în cache și TTL (Time to Live) nu a expirat, rezoluția se oprește aici.

Puteți inspecta cache-ul DNS local pe Linux cu:

resolvectl statistics

Sau îl puteți goli cu:

sudo resolvectl flush-caches

Pe Windows:

ipconfig /displaydns
ipconfig /flushdns

Pasul 2 — Interogarea rezolverului recursiv

Dacă nu există niciun răspuns în cache, sistemul de operare transmite interogarea către rezolverul recursiv configurat (numit și server DNS recursiv sau rezolver cu servicii complete). Acesta este de obicei:

• Rezolverul ISP-ului dvs. (atribuit prin DHCP)
• Un rezolver public: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Un rezolver auto-găzduit precum Unbound sau BIND pe propria infrastructură VPS Hosting

Rezolverul recursiv face munca grea. Va traversa ierarhia DNS în numele dvs. și va stoca în cache rezultatele pentru a servi mai rapid interogările viitoare.

Pasul 3 — Referința serverului rădăcină

Rezolverul recursiv interoghează unul dintre cele 13 clustere de servere rădăcină. Serverul rădăcină nu cunoaște adresa IP a www.example.com. În schimb, returnează o referință — o listă de servere de nume autoritare pentru zona TLD .com, împreună cu adresele lor IP (numite înregistrări glue).

Pasul 4 — Interogarea serverului de nume TLD

Rezolverul interoghează serverele de nume TLD .com (operate de Verisign). Aceste servere nu dețin nici ele răspunsul final. Returnează o altă referință — serverele de nume autoritare pentru example.com în mod specific (de ex., ns1.example.com, ns2.example.com).

Pasul 5 — Interogarea serverului de nume autoritar

Rezolverul interoghează serverul de nume autoritar pentru example.com. Acest server deține fișierul de zonă actual și returnează răspunsul definitiv — înregistrarea A care conține adresa IPv4 (sau AAAA pentru IPv6).

Pasul 6 — Stocarea în cache a răspunsului și livrarea

Rezolverul recursiv stochează în cache răspunsul conform valorii TTL a înregistrării (de ex., 300 secunde = 5 minute, 86400 secunde = 24 de ore). Apoi returnează adresa IP sistemului de operare al clientului, care o transmite browserului.

Pasul 7 — Conexiunea TCP/IP

Browserul folosește adresa IP rezolvată pentru a deschide o conexiune TCP (de obicei pe portul 443 pentru HTTPS). Sarcina DNS este acum completă. Serverul web răspunde și pagina se încarcă.

Întregul proces — pașii 2 până la 6 — se finalizează de obicei în 20–120 milisecunde pe un cache de rezolver cald și sub 500 de milisecunde pentru o rezoluție complet rece, fără cache, care traversează toate nivelurile ierarhiei.

Tipuri de înregistrări DNS: O referință tehnică

Înregistrările CAA merită o mențiune specială: acestea instruiesc Autoritățile de Certificare care organizații au permisiunea de a emite Certificate SSL pentru domeniul dvs. — un control de securitate critic care este frecvent ignorat.

Tipuri de interogări DNS: Recursive vs. Iterative vs. Non-recursive

Majoritatea dispozitivelor utilizatorilor finali trimit interogări recursive către rezolverul configurat. Rezolverul însuși folosește interogări iterative atunci când traversează ierarhia.

TTL: Cel mai neînțeles parametru DNS

TTL (Time to Live) reprezintă numărul de secunde în care o înregistrare DNS poate fi stocată în cache de rezolvere și clienți. Este setat de proprietarul domeniului în fișierul de zonă.

• TTL scăzut (60–300 secunde): Propagare mai rapidă a modificărilor. Esențial înainte de migrări planificate, schimbări de IP sau evenimente de failover. Crește sarcina de interogare pe serverele autoritare.
• TTL ridicat (3600–86400 secunde): Reduce sarcina rezolverului și accelerează interogările repetate. Modificările durează mai mult să se propage global.

Informație operațională critică: Când planificați o migrare de server sau o schimbare de IP, reduceți TTL-ul la 300 secunde cu cel puțin 48 de ore înainte de modificare. Aceasta asigură că, în momentul în care actualizați înregistrarea A, niciun rezolver nu stochează în cache valoarea veche pentru mai mult de 5 minute. Nerespectarea acestui lucru este una dintre cele mai frecvente cauze ale timpilor de nefuncționare extinși în timpul migrărilor.

Când înregistrați un domeniu prin Înregistrare Domeniu și îl direcționați către un server nou, fereastra de propagare este guvernată direct de valoarea TTL anterioară — nu de o regulă arbitrară de „24–48 de ore” care este adesea citată incorect.

Protocoale de transport DNS: UDP, TCP, DoH și DoT

DNS tradițional operează prin UDP portul 53 pentru interogări sub 512 octeți. Răspunsurile care depășesc această dimensiune declanșează o revenire la TCP portul 53. Răspunsurile DNSSEC, transferurile de zonă (AXFR) și înregistrările mari TXT necesită frecvent TCP.

Protocoalele moderne de confidențialitate DNS au schimbat semnificativ acest peisaj:

DoH vs. DoT — diferența operațională reală: DoH tunelizează DNS în traficul HTTPS pe portul 443, făcându-l indistinguibil de traficul web obișnuit. Acest lucru este util pentru confidențialitate, dar face monitorizarea și filtrarea rețelei enterprise semnificativ mai dificile. DoT folosește un port dedicat (853), pe care administratorii de rețea îl pot monitoriza, bloca sau inspecta independent. Pentru infrastructura auto-gestionată pe un Server Dedicat, rularea unui rezolver DoT sau DoH local vă oferă atât confidențialitate, cât și control complet asupra politicii de rezoluție.

DNSSEC: Integritate criptografică pentru DNS

DNSSEC (DNS Security Extensions) adaugă un lanț de semnături criptografice la răspunsurile DNS, permițând rezolverelor să verifice că un răspuns este autentic și nu a fost alterat în tranzit. Protejează împotriva otrăvirii cache-ului DNS (atacul Kaminsky) și falsificării DNS prin atacuri man-in-the-middle.

DNSSEC nu criptează traficul DNS — îl semnează doar. Lanțul de semnături funcționează astfel:

1. Proprietarul zonei generează o Cheie de Semnare a Zonei (ZSK) și o Cheie de Semnare a Cheii (KSK)
2. Fiecare set de înregistrări DNS este semnat cu ZSK, producând înregistrări RRSIG
3. KSK semnează setul de înregistrări DNSKEY
4. O înregistrare DS (Delegation Signer) este publicată în zona părinte (de ex., .com), creând lanțul de încredere înapoi la rădăcină

Activarea DNSSEC este puternic recomandată pentru orice domeniu care gestionează tranzacții financiare, autentificare sau e-mail. DNSSEC configurat greșit — în special o semnătură expirată sau o înregistrare DS nepotrivită — va cauza eșecul complet al rezoluției pentru rezolverele de validare, ceea ce este un mod de eșec mai grav decât absența DNSSEC.

Eșecuri DNS comune și cum să le diagnosticați

NXDOMAIN — Domeniu inexistent

Serverul autoritar a confirmat că domeniul nu există. Cauze frecvente: greșeală de tastare în numele domeniului, înregistrare de domeniu expirată, înregistrare DNS ștearsă.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Eșec de server

Rezolverul nu a putut finaliza interogarea. Cauze frecvente: eșec de validare DNSSEC, server autoritar inaccesibil, fișier de zonă configurat greșit.

dig +dnssec example.com
# Look for: status: SERVFAIL

Pentru a ocoli validarea DNSSEC și a izola problema:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Cache expirat / Întârziere de propagare

După actualizarea unei înregistrări DNS, valorile vechi persistă în cache-urile rezolverelor până la expirarea TTL-ului. Pentru a interoga direct serverul autoritar și a ocoli cache-ul rezolverului:

dig @ns1.example.com www.example.com

Verificarea propagării DNS la nivel global

Utilizați dig cu rezolvere publice specifice pentru a verifica starea propagării:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS în mediile de hosting: Configurații practice

Când implementați un site web sau o aplicație pe un VPS cu cPanel, gestionarea DNS este de obicei realizată prin clusterul DNS al WHM sau prin Zone Editor din cPanel. Înțelegerea structurii de bază a fișierului de zonă vă permite să faceți modificări pe care interfața grafică nu le expune.

Un fișier de zonă minimal pentru example.com arată astfel:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Pentru ca Hosting E-mail să funcționeze corect, înregistrarea MX trebuie să indice spre un nume de host (nu direct spre o adresă IP), iar acel nume de host trebuie să se rezolve el însuși printr-o înregistrare A. O configurare greșită frecventă este direcționarea MX direct spre un IP — aceasta încalcă RFC 2821 și cauzează eșecuri de livrare cu serverele de e-mail stricte.

Performanța DNS: Ce afectează cu adevărat viteza de rezoluție

• Proximitatea rezolverului: Un rezolver geografic aproape de client (sau în aceeași rețea) reduce dramatic timpul de dus-întors.
• Rata de accesare a cache-ului: Domeniile cu trafic ridicat și TTL-uri rezonabile sunt aproape întotdeauna servite din cache. Rezoluția cu cache rece este de 5–20 ori mai lentă.
• Rutarea anycast: Serverele rădăcină și rezolverele publice majore folosesc anycast, direcționând automat interogările către cel mai apropiat nod fizic.
• Numărul de căutări DNS per pagină: O singură pagină web poate declanșa 20–50 de interogări DNS (active CDN, analiză, fonturi, rețele publicitare). Browserele le paralelizează, dar fiecare nume de host unic necesită propria căutare.
• Prefetch DNS: Browserele moderne suportă <link rel="dns-prefetch" href="//cdn.example.com"> pentru a rezolva numele de host ale terților înainte ca acestea să fie necesare, reducând latența percepută.

DNS vs. Mecanisme alternative de rezoluție

Fișierul /etc/hosts este evaluat înaintea DNS pe aproape orice sistem de operare. Acest lucru îl face de neprețuit pentru dezvoltarea locală — puteți mapa myapp.local la 127.0.0.1 fără a atinge nicio infrastructură DNS.

Concluzii cheie și listă de verificare

Utilizați această listă de verificare când configurați sau depanați DNS pentru orice mediu de producție:

• Înainte de orice migrare de server: Reduceți TTL-ul la 300 secunde cu cel puțin 48 de ore în avans
• Pentru livrabilitatea e-mailurilor: Verificați că înregistrările MX, SPF (TXT), DKIM (TXT), DMARC (TXT) și PTR sunt toate configurate corect
• Pentru securitate: Activați DNSSEC pe domeniul dvs. și adăugați înregistrări CAA pentru a restricționa emiterea certificatelor
• Pentru confidențialitate: Utilizați DoT sau DoH pe dispozitivele client și servere; evitați trimiterea DNS în text clar prin rețele nesigure
• Pentru performanță: Setați TTL la 3600–86400 pentru înregistrările stabile; utilizați 300 doar pentru înregistrările care se modifică frecvent
• Pentru diagnosticare: Interogați întotdeauna direct serverul autoritar cu dig @ns1.yourdomain.com pentru a distinge întârzierea de propagare de o configurare greșită reală
• Pentru gestionarea zonelor: Incrementați numărul de serie SOA de fiecare dată când modificați un fișier de zonă — rezolverele îl folosesc pentru a detecta modificările
• Pentru hosting: Confirmați că delegarea nameserver-ului registrarului dvs. corespunde înregistrărilor NS din fișierul dvs. de zonă — o nepotrivire este cea mai frecventă cauză a „DNS-ului care nu funcționează” după un transfer de domeniu

Întrebări frecvente

Care este diferența dintre un rezolver DNS și un server DNS autoritar?

Un rezolver recursiv (de ex., 8.8.8.8) este un intermediar care interoghează ierarhia DNS în numele dispozitivului dvs. și stochează în cache rezultatele. Un server de nume autoritar deține înregistrările de zonă actuale pentru un domeniu specific și furnizează răspunsuri definitive. Rezolverul dvs. interoghează mai multe servere autoritare; serverul autoritar al domeniului dvs. răspunde doar pentru zonele pe care le găzduiește.

De ce propagarea DNS durează timp după ce actualizez o înregistrare?

Întârzierea de propagare este cauzată de stocarea în cache bazată pe TTL. Fiecare rezolver care a stocat anterior în cache înregistrarea dvs. veche va continua să o servească până la expirarea TTL-ului. Dacă TTL-ul dvs. era 86400 (24 de ore), rezolverele pot servi înregistrarea veche până la 24 de ore după actualizarea dvs. Aceasta nu este o eroare — este mecanismul de stocare în cache intenționat care face DNS-ul scalabil.

Ce este o scurgere DNS și de ce contează?

O scurgere DNS apare atunci când dispozitivul dvs. trimite interogări DNS în afara rezolverului intenționat — de obicei rezolverul ISP-ului dvs. — chiar și atunci când utilizați un VPN sau un instrument de confidențialitate. Aceasta expune activitatea dvs. de navigare ISP-ului dvs. Puteți testa scurgerile la dnsleaktest.com și le puteți remedia configurând clientul VPN să impună rutarea DNS prin propriul rezolver.

Poate DNS fi folosit ca vector de atac?

Da. Atacurile comune bazate pe DNS includ otrăvirea cache-ului (injectarea de înregistrări false în cache-ul unui rezolver), amplificarea DNS DDoS (utilizarea rezolverelor deschise pentru a inunda o țintă cu răspunsuri DNS mari), deturnarea DNS (redirecționarea interogărilor către servere malițioase) și tunelizarea DNS (exfiltrarea datelor prin codificarea lor în șiruri de interogări DNS). DNSSEC atenuează otrăvirea cache-ului; limitarea ratei și limitarea ratei de răspuns (RRL) pe serverele autoritare atenuează amplificarea.

Cum găsesc serverele de nume autoritare pentru orice domeniu?

Utilizați dig cu tipul de înregistrare NS și indicatorul +short pentru o ieșire curată:

dig NS example.com +short

Pentru a urmări calea completă de delegare de la rădăcină la autoritar, utilizați:

dig +trace example.com

Aceasta arată fiecare hop de referință — rădăcină → TLD → autoritar — ceea ce reprezintă cea mai fiabilă modalitate de a diagnostica configurările greșite de delegare.