Articol Gazduire

DNS pentru începători - A, MX, CNAME, TXT explicate

Glob stilizat în navy cu linii portocalii de conexiune radiante, reprezentând rezolvare DNS și tipuri de record
De Andrei Popescu - Editor Tehnologie 10 min de citit

DNS este tehnologia pe care toți o folosesc, puțini o înțeleg și toată lumea o înjură când ceva nu merge. Dacă tocmai ai cumpărat un domeniu .ro și te uiți în panou la 9 tipuri de record și 12 câmpuri obscure, articolul ăsta îți explică ce face fiecare record, când îl folosești și cum verifici că ai configurat corect.

În termeni simpli: DNS-ul nu este magie, este un sistem distribuit cu cache agresiv. Trei concepte de bază - rezolvare, record types, TTL - apoi totul e aplicare. Dacă nu ai încă domeniul, citește mai întâi cum înregistrezi un domeniu .ro.

Ce este DNS, în termeni simpli

DNS (Domain Name System) este agenda telefonică a internetului. Tu tastezi webghid.ro în browser. Browserul nu știe ce să facă cu un text - rețeaua funcționează pe adrese IP de tipul 185.46.156.42. Cineva trebuie să facă traducerea text -> IP. Acel cineva este DNS-ul.

Analogia este utilă pentru a înțelege și de ce e atât de fragil: ai schimbat numărul de telefon, dar agenda prietenilor tăi e cache-uită local pe device. Până nu se actualizează cache-ul fiecăruia (TTL expirat), unii te sună la numărul vechi.

Lanțul de rezolvare (resolver chain)

Când browserul cere IP-ul pentru webghid.ro, se întâmplă în spate următoarele, în ordine:

  1. Cache local - browser cache, apoi cache OS (systemd-resolved pe Linux, DNS Client pe Windows). Dacă găsește acolo IP-ul, oprește căutarea.
  2. Recursive resolver - de obicei DNS-ul ISP-ului tău (Digi, RCS, Vodafone) sau unul public (1.1.1.1 Cloudflare, 8.8.8.8 Google).
  3. Root servers (13 servere globale, .) - resolverul întreabă: "cine e responsabil de .ro?". Răspuns: serverele TLD .ro.
  4. TLD nameservers (.ro la RoTLD) - "cine e responsabil de webghid.ro?". Răspuns: nameserverele authoritative ale domeniului (ex: dns1.hostico.ro, dns2.hostico.ro).
  5. Authoritative nameserver - aici stau record-urile tale reale. Răspunde cu IP-ul. Resolverul cache-uiește răspunsul pe TTL secunde și-l returnează browserului.

Aici este partea importantă: modificările în panou ajung imediat pe nameserverele authoritative. Dar resolverii intermediari și cache-urile locale servesc valoarea veche până expiră TTL-ul.

TTL - cât timp se cache-uiește un record

TTL (Time To Live) se măsoară în secunde și spune resolverilor cât timp pot ține răspunsul în cache.

  • 300 s (5 min) - foarte mic, util înainte și în timpul unei migrări
  • 3600 s (1 oră) - default rezonabil pentru majoritatea record-urilor
  • 86400 s (24 ore) - mare, util pentru record-uri stabile (NS, MX) care nu se schimbă des

Trade-off: TTL mic = propagation rapidă la schimbări, dar mai multe query-uri (load pe nameserver). TTL mare = mai puține query-uri, dar dacă greșești ceva, ai 24h de durere.

Pro tip dev: cu 48 ore înainte de o migrare planificată, scade TTL-ul la 300 s pe toate record-urile critice. După migrare și verificare (24-48 ore stabil), urcă-l înapoi la 3600 sau 86400.

Propagation - mitul celor 48 de ore

"Propagation DNS" nu e o difuzie magică prin rețea. E doar așteptarea ca toate cache-urile resolverilor să expire. Realitatea: 80% din lume vede schimbarea în sub 1 oră, 95% în 4-6 ore, restul maxim 24 ore. Cele "48 ore" sunt un mit moștenit din anii 2000 când TTL-urile default erau o săptămână.

Tipurile de record DNS - ce face fiecare

Record Ce face Când îl folosești Exemplu valoare
A Mapează nume -> IPv4 Root domain, subdomenii pe IP 185.46.156.42
AAAA Mapează nume -> IPv6 Dual-stack modern 2a02:6b80::42
CNAME Alias către alt nume www, subdomenii SaaS webghid.ro
MX Server de email pentru domeniu Email pe domeniu propriu 10 aspmx.l.google.com
TXT Text arbitrar (SPF, DKIM, DMARC, verificări) Auth email, verificări proprietate v=spf1 include:_spf.google.com ~all
NS Nameservers authoritative Delegare subdomeniu sau întreg domeniu dns1.hostico.ro
SOA Start Of Authority, metadata zone Generat automat, rar îl editezi serial, refresh, retry, expire
SRV Servicii pe port specific XMPP, SIP, Microsoft Teams 0 5 5061 sipfed.contoso.com
CAA Cine poate emite certificate SSL Restricționezi la Let's Encrypt sau alt CA 0 issue "letsencrypt.org"

A record - inima DNS-ului

Cel mai folosit record. Mapează un nume direct la un IPv4.

webghid.ro.        3600  IN  A  185.46.156.42
mail.webghid.ro.   3600  IN  A  185.46.156.43

Pe root domain (apex, webghid.ro fără www) trebuie să folosești A sau AAAA, niciodată CNAME. Verifici cu:

dig +short A webghid.ro

AAAA record - IPv6

Identic cu A, dar pentru IPv6. Dacă hostingul oferă IPv6, configurează AAAA - costă zero și ajută cu latența pe mobile carriers.

webghid.ro.   3600  IN  AAAA  2a02:6b80:0:1::42

CNAME - aliasul utilizat și folosit greșit

CNAME (Canonical Name) spune: "acest nume este alias pentru alt nume". Resolverul ia CNAME-ul, apoi face un nou query pentru ținta.

www.webghid.ro.   3600  IN  CNAME  webghid.ro.
shop.webghid.ro.  3600  IN  CNAME  shops.shopify.com.

Cazuri clasice: www -> root, subdomenii SaaS (Shopify, Vercel, Netlify, GitHub Pages), status pages.

⚠️ Greșeala clasică: CNAME pe root domain. Conform RFC 1034, CNAME nu poate coexista cu alte record-uri pe același nume. Root are obligatoriu SOA și NS, deci nu poate avea CNAME. Pentru "CNAME pe apex" folosește ALIAS, ANAME sau CNAME flattening - feature oferit de Cloudflare, DNSimple, Route53.

MX record - unde ajung emailurile

MX (Mail Exchanger) spune lumii unde să livreze emailurile pentru @webghid.ro. Are prioritate (număr mai mic = prioritate mai mare).

Pentru Google Workspace:

webghid.ro.   3600  IN  MX  1   aspmx.l.google.com.
webghid.ro.   3600  IN  MX  5   alt1.aspmx.l.google.com.
webghid.ro.   3600  IN  MX  5   alt2.aspmx.l.google.com.
webghid.ro.   3600  IN  MX  10  alt3.aspmx.l.google.com.
webghid.ro.   3600  IN  MX  10  alt4.aspmx.l.google.com.

Pentru Microsoft 365:

webghid.ro.   3600  IN  MX  0  webghid-ro.mail.protection.outlook.com.

⚠️ Lipsa MX = emailurile dispar. Fie serverele eșuează cu "no MX record", fie (conform RFC 5321) cad pe A record - care nu rulează SMTP. Rezultat: emailuri pierdute fără eroare vizibilă la expeditor.

TXT record - cuțitul elvețian

TXT permite text arbitrar. În practică, e folosit pentru:

SPF (Sender Policy Framework) - listează cine are voie să trimită email în numele tău:

webghid.ro.   3600  IN  TXT  "v=spf1 include:_spf.google.com include:mailgun.org ~all"

DKIM (DomainKeys Identified Mail) - cheia publică folosită pentru semnarea criptografică a emailurilor:

google._domainkey.webghid.ro.   3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

DMARC - politica ce se întâmplă dacă SPF/DKIM eșuează:

_dmarc.webghid.ro.   3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@webghid.ro; pct=100"

Verificare proprietate - Google Search Console, Facebook Business, Microsoft 365 cer TXT cu șir random ca dovadă de owner: "google-site-verification=Xy7...".

💡 Pro tip dev: poți avea mai multe TXT records pe același nume - SPF, verificări Google, verificări Facebook coexistă fără probleme. NU poți avea două SPF separate - le combini într-un singur string cu include: multiple. Două v=spf1 = SPF invalid = email în spam.

NS record - delegare authoritative

NS spune "pentru această zonă, întreabă serverele astea". La nivel de domeniu se setează la registrar (RoTLD pentru .ro): ex dns1.hostico.ro, dns2.hostico.ro. Poți delega și un subdomeniu către alte nameservers (ex: cdn.webghid.ro gestionat de CDN cu DNS propriu).

SOA - metadata zonei

Generat automat. Conține: nameserver primary, emailul adminului (cu . în loc de @), serial number, refresh/retry/expire/minimum TTL. Rar îl editezi manual.

SRV - servicii cu port

Folosit pentru protocoale care anunță port + prioritate via DNS (Microsoft Teams, XMPP self-hosted). Format: 10 60 5060 sip.webghid.ro. = prioritate, weight, port, target. RTFM (citește docs oficiale): RFC 2782.

CAA - controlul certificatelor SSL

CAA (Certificate Authority Authorization) spune ce CA-uri au voie să emită certificate SSL pentru domeniul tău. Util ca strat suplimentar de securitate.

webghid.ro.   3600  IN  CAA  0 issue "letsencrypt.org"
webghid.ro.   3600  IN  CAA  0 issuewild "letsencrypt.org"
webghid.ro.   3600  IN  CAA  0 iodef "mailto:admin@webghid.ro"

Înseamnă: doar Let's Encrypt poate emite, alte CA refuză automat - blochezi certificate frauduloase.

Setup minim DNS pentru un domeniu .ro nou

Scenariu: ai cumpărat firma-mea.ro, hosting WordPress shared și Google Workspace pentru email. Setup minim:

  1. Nameservers la RoTLD către hosting provider (ex: dns1.hostico.ro, dns2.hostico.ro). Așteaptă 1-4 ore.
  2. A record pentru root + CNAME www: A @ -> IP server, CNAME www -> firma-mea.ro.
  3. MX records Google Workspace (5 record-uri, vezi exemplu mai sus), TTL 3600.
  4. SPF: TXT pe root: v=spf1 include:_spf.google.com ~all.
  5. DKIM Google: Admin Console -> Gmail -> Authenticate email -> generează cheie -> TXT pe google._domainkey.
  6. DMARC: după 1 săptămână cu SPF + DKIM stabile, TXT pe _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@firma-mea.ro. Începi cu p=none (raport), treci la p=quarantine peste 30 zile.
  7. CAA: TXT pe root: 0 issue "letsencrypt.org".

Pentru SSL după stabilizare DNS, vezi ghidul SSL pentru site mic. Pentru un strat de protecție și performanță, Cloudflare gratuit pentru site mic explică setup-ul în 15 minute.

Greșeli frecvente (și cum le eviți)

  • CNAME pe root domain - nu rezolvă. Folosește A record sau ALIAS/ANAME.
  • Lipsa MX - emailurile dispar silentios. Configurează MX înainte de a crea cutiile poștale.
  • TTL prea mare la migrare - scade TTL-ul la 300 cu 48h înainte de migrare.
  • Două record-uri v=spf1 - invalid. Combină într-unul singur cu include: multiple.
  • DKIM key cu spații copiate greșit - validatorul eșuează. Lipește cheia într-un singur rând lung.
  • DMARC p=reject din prima zi - îți rejectezi propriile emailuri legitime. Începe cu p=none o lună.
  • "Propagation panic" - browserul are cache. Verifică cu dig pe DNS public, nu pe localhost.
  • Schimbi NS fără să muți record-urile - domeniul devine "dark" instant.

Cum verifici DNS-ul - dig, nslookup, online tools

Toate comenzile rulează din terminal (macOS, Linux). Pe Windows folosești nslookup (built-in) sau dig din WSL.

dig - standard de fapt

# IP-ul root domain
dig +short A webghid.ro

# Toate record-urile (verbose)
dig webghid.ro ANY

# MX records
dig +short MX webghid.ro

# TXT records (vezi SPF, verificări)
dig +short TXT webghid.ro

# Verifici pe DNS public (nu cache local)
dig @1.1.1.1 +short A webghid.ro
dig @8.8.8.8 +short MX webghid.ro

# Trace complet (root -> TLD -> authoritative)
dig +trace webghid.ro

nslookup - alternativa portabilă

nslookup webghid.ro
nslookup -type=MX webghid.ro
nslookup -type=TXT webghid.ro 1.1.1.1

Online lookups (când nu ai terminal)

  • dnschecker.org - propagation pe ~20 locații globale
  • mxtoolbox.com - validare MX, SPF, DKIM, DMARC, blacklist
  • intodns.com - audit complet zone DNS
  • dig.dev - dig in browser pentru cei fără terminal
  • whatsmydns.net - propagation visual pe hartă mondială

Pro tip dev: dacă vrei să eviți cache-ul local complet în timpul troubleshootingului, rulează sudo dscacheutil -flushcache pe macOS sau sudo systemd-resolve --flush-caches pe Linux. Pe Windows: ipconfig /flushdns.

Întrebări frecvente

Cât durează propagation DNS real?

Realistic: 1-4 ore pentru 95% din lume, maxim 24 ore. Mitul "48 ore" e moștenit din anii 2000. Cu TTL 300 setat înainte, propagation efectivă e sub 30 minute pentru majoritatea utilizatorilor.

Ce TTL ar trebui să pun?

Default rezonabil: 3600 secunde (1 oră) pentru A, AAAA, CNAME, MX, TXT. 86400 (24h) pentru NS și SOA (nu se schimbă des). 300 (5 min) temporar, înainte de orice migrare planificată. După migrare și verificare, urci înapoi la 3600.

De ce nu funcționează emailul după ce am migrat hostingul?

Trei cauze probabile: (1) MX records nu au fost recreate la noul provider - ai mutat A record dar ai uitat MX. (2) SPF vechi listează doar IP-ul vechi - actualizează cu include: al noului provider. (3) DKIM key-ul nou nu a fost adăugat în DNS - regenerează la noul provider și adaugă TXT-ul.

Care e diferența între CNAME și redirect?

CNAME e la nivel DNS - resolverul rezolvă www.webghid.ro la webghid.ro și apoi continuă cu A record-ul rootului. Browserul nu vede schimbarea. Redirect (301/302) e la nivel HTTP - serverul răspunde cu Location: și browserul face nou request. CNAME = transparent, redirect = vizibil în bara de adrese.

De ce e DNS-ul atât de fragil?

Pentru că funcționează în mare parte pe cache eventual-consistent distribuit fără mecanism global de invalidare. Ai schimbat ceva, dar trebuie să aștepți TTL-uri să expire în mii de cache-uri independente. Nu există un buton "purge". Singura strategie e: TTL mic înainte de schimbare, verificare cu DNS public (nu cache local), răbdare 1-24h.

Cloudflare îmi rezolvă problemele de DNS?

Da, în mare parte. Folosirea Cloudflare ca DNS provider îți dă: propagation foarte rapidă (Anycast network), CNAME flattening (CNAME pe apex), DDoS protection inclus pe DNS, analytics. Pentru un site mic-mediu este alegerea optimă - vezi setup Cloudflare gratuit.

Concluzie

DNS pare complicat dar e simplu: nume + record + TTL. A pentru IP, MX pentru email, CNAME pentru aliasuri, TXT pentru auth. Restul sunt nuanțe.

Pe scurt: configurează A + MX + SPF + DKIM + DMARC + CAA din prima zi, TTL 3600, scade la 300 înainte de migrări, verifică cu dig @1.1.1.1. În 99% din cazuri, "DNS-ul nu merge" e cache local browser sau o greșeală tipografică în panou.

RTFM: RFC 1035, RFC 5321, RFC 7208, RFC 6376, RFC 7489.

Surse

  • https://datatracker.ietf.org/doc/html/rfc1035
  • https://datatracker.ietf.org/doc/html/rfc7208
  • https://datatracker.ietf.org/doc/html/rfc6376
  • https://datatracker.ietf.org/doc/html/rfc7489
  • https://developers.cloudflare.com/dns/
  • https://support.google.com/a/answer/140034
  • https://learn.microsoft.com/en-us/microsoft-365/admin/setup/add-domain