Setări esențiale DNS în cPanel pentru un website stabil

Setări esențiale DNS în cPanel pentru un website stabil, fiindcă jumătate din „site-ul nu merge” și „nu primim e-mailuri” pe care le primim de la clienți sunt înregistrări DNS lipsă, greșite sau modificate fără să știe nimeni. DNS-ul traduce numele domeniului în adrese de servere; o zonă corectă are câteva înregistrări obligatorii pentru site, câteva pentru e-mail și câteva pentru verificări și securitate. Ghidul le parcurge pe toate, cu valorile pe care le verificăm pe fiecare domeniu administrat.

Presupunem că domeniul folosește nameserverele găzduirii, deci zona se administrează din cPanel, Zone Editor; dacă DNS-ul este la registrar sau la Cloudflare, aceleași înregistrări se pun acolo, iar Zone Editor nu are efect, o confuzie frecventă pe care o lămurim la final.

Setări esențiale DNS în cPanel pentru un website stabil

Nameserverele: unde este zona

La registrar, domeniul are două-patru nameservere; ele decid cine răspunde pentru zonă. Dacă sunt ale găzduirii (ns1.furnizor.ro), zona este în cPanel. Verificați cu o interogare NS (dig NS exemplu.ro sau un serviciu online); dacă rezultatul arată alt furnizor, modificările din Zone Editor nu ajung nicăieri. Schimbarea nameserverelor se propagă în ore până la două zile; nu o faceți înainte ca zona de la destinație să conțină toate înregistrările.

Înregistrările pentru site

• A pentru exemplu.ro: adresa IPv4 a serverului. Obligatorie. Valoarea o vedeți în cPanel, în bara laterală (Shared IP Address sau Dedicated IP).
• A sau CNAME pentru www: fie aceeași adresă IP, fie CNAME spre exemplu.ro. Lipsa lui www este cauza clasică a „merge fără www, nu merge cu www”; AutoSSL nu poate emite certificat pentru un nume care nu există în DNS.
• AAAA: adresa IPv6, dacă serverul are; opțională, dar din ce în ce mai utilă. Nu puneți AAAA dacă serverul nu răspunde pe IPv6: unii vizitatori vor încerca IPv6 întâi și vor aștepta.
• A pentru subdomenii (blog, magazin, test): cPanel le creează automat la adăugarea subdomeniului din Domains; dacă le creați manual, cu aceeași adresă IP.
• Fără înregistrări wildcard (*) decât dacă aveți nevoie: orice nume greșit ar răspunde cu site-ul, iar Google poate indexa duplicate.

Înregistrările pentru e-mail

1. MX: serverul care primește e-mail pentru domeniu. Pentru e-mail pe cPanel, o înregistrare MX cu prioritate 0 spre mail.exemplu.ro (sau spre numele serverului), iar mail.exemplu.ro cu înregistrare A spre serverul de găzduire. Pentru Google Workspace sau Microsoft 365, înregistrările MX ale furnizorului, cu prioritățile lor, și rutarea e-mailului din cPanel (Email Routing) setată pe Remote, altfel serverul încearcă să livreze local mesajele trimise din site.
2. SPF (TXT pe exemplu.ro): cine are voie să trimită e-mail în numele domeniului; pentru cPanel, v=spf1 +mx +a include:… ~all, generat din Email Deliverability; adăugați serviciile externe care trimit pentru dumneavoastră (platforma de newsletter, magazinul, CRM-ul) cu include:. O singură înregistrare SPF pe domeniu; două înregistrări înseamnă SPF invalid.
3. DKIM (TXT pe default._domainkey sau selectorul furnizorului): semnătura mesajelor; cheia se generează din Email Deliverability în cPanel și se instalează cu un clic dacă zona e locală. Serviciile externe au propriul selector și propria cheie, de adăugat separat.
4. DMARC (TXT pe _dmarc): politica pentru mesajele care pică SPF și DKIM; începeți cu p=none și adresa de rapoarte (rua=mailto:…), analizați rapoartele câteva săptămâni, apoi p=quarantine și p=reject. Gmail și Yahoo cer DMARC pentru expeditorii în volum din 2024; fără el, mesajele ajung în spam sau sunt respinse. Am avut cazul unui magazin al cărui plic de expediere nu era aliniat cu domeniul: cu p=reject, Gmail respingea tot până la corectare.
5. Autodiscover și autoconfig (CNAME sau SRV): pentru configurarea automată a programelor de e-mail; cPanel le adaugă implicit.

Înregistrările pentru verificări și securitate

• TXT de verificare: Google Search Console (google-site-verification=…), Microsoft, Facebook, servicii de e-mail; se adaugă pe exemplu.ro și rămân, nu se șterg după verificare.
• CAA: ce autorități pot emite certificate pentru domeniu; cel puțin o înregistrare issue pentru autoritatea folosită de AutoSSL (letsencrypt.org sau sectigo.com) și una iodef cu un e-mail; fără issuewild dacă nu aveți certificate wildcard. Un CAA fără autoritatea potrivită oprește reînnoirea certificatelor, tăcut.
• MTA-STS și TLS-RPT (TXT pe _mta-sts și _smtp._tls, plus un fișier de politică pe mta-sts.exemplu.ro): obligă expeditorii mari să folosească TLS spre serverul de e-mail; util, dar depinde de un certificat valid pe numele MX; l-am pus pe domeniile noastre după verificarea certificatului.
• DNSSEC: semnarea zonei; se activează la registrar și în zona găzduirii împreună; protejează împotriva răspunsurilor falsificate, cu condiția să nu uitați de ea la mutarea domeniului (o zonă semnată mutată fără actualizarea cheilor la registrar dispare de pe internet).

TTL: cât de repede se propagă schimbările

Fiecare înregistrare are un TTL, în secunde, cât timp o păstrează rezolvatoarele în cache. Implicit în cPanel: 14400 (4 ore). Înainte de o migrare sau de o schimbare de server, reduceți TTL-ul înregistrărilor A la 300 cu cel puțin o zi înainte; după schimbare, readuceți-l la 3600-14400. TTL-ul mic permanent încarcă serverele DNS și nu aduce nimic.

Cum modificați fără întreruperi

1. Zone Editor, Manage pe domeniu; exportați sau notați zona actuală (copie de ecran sau export) înainte de orice modificare.
2. Adăugați înregistrarea nouă înainte de a o șterge pe cea veche, unde e posibil (de exemplu, noile MX înainte de a scoate vechile MX).
3. Verificați sintaxa: TXT-urile lungi (DKIM) se împart în bucăți de 255 de caractere, iar interfața o face automat; valorile CNAME nu pot coexista cu alte tipuri pe același nume.
4. Verificați răspunsul de la mai multe rezolvatoare (dig @8.8.8.8, dig @1.1.1.1 și serverul găzduirii) după propagare.
5. Notați schimbarea, cu data și motivul, într-un fișier al domeniului; peste un an, nimeni nu știe de ce există TXT-ul acela.

dig +short A exemplu.ro
dig +short MX exemplu.ro
dig +short TXT exemplu.ro
dig +short TXT _dmarc.exemplu.ro
dig +short CAA exemplu.ro
dig +short NS exemplu.ro

Utilizarea pas cu pas a interfeței este descrisă în ghidul despre Zone Editor pentru DNS, iar subdomeniile, în cel despre subdomenii și domenii suplimentare.

Când DNS-ul este la Cloudflare

Cu nameserverele Cloudflare, zona este în panoul Cloudflare, iar Zone Editor din cPanel devine o copie fără efect (cu excepția integrării cPanel-Cloudflare, care sincronizează). Regulile rămân aceleași, cu două particularități: înregistrările site-ului (A, CNAME www) proxyate (norul portocaliu) pentru protecție și cache, iar cele de e-mail (mail, MX) și de verificare neproxyate (norul gri), altfel e-mailul nu funcționează. Adresa IP reală a serverului trebuie să nu apară în nicio înregistrare neproxyată cu nume evident (mail.exemplu.ro o expune; este un compromis acceptat de majoritatea). Configurarea completă este în ghidul despre Cloudflare și cPanel.

DNS-ul și SEO-ul

DNS-ul nu este factor de clasare, dar erorile lui sunt: un domeniu care nu răspunde câteva ore apare în Search Console ca eroare de DNS și reduce accesarea; www și fără www răspunzând amândouă fără redirecționare creează duplicate; un subdomeniu de test lăsat în DNS și fără parolă ajunge indexat. Verificarea proprietății în Search Console prin înregistrare TXT (proprietatea de domeniu) acoperă toate variantele și subdomeniile deodată, cum descriem în ghidul complet pentru Search Console; erorile de accesare cauzate de DNS apar în raportul de statistici de accesare, la starea gazdei, și sunt explicate în articolul despre erorile de indexare frecvente.

Mutarea DNS-ului la alt furnizor

Când mutați zona (de la găzduire la Cloudflare sau la registrar), copiați întâi toate înregistrările în noua zonă (exportul din Zone Editor sau interogări pentru fiecare tip), verificați că noua zonă răspunde corect interogând direct nameserverele noi (dig @ns1.nou.ro exemplu.ro), abia apoi schimbați nameserverele la registrar. Dezactivați DNSSEC înainte de mutare și reactivați-l după, cu cheile noii zone; o zonă semnată mutată fără această ordine dispare pentru toți rezolvatoarele care validează. Păstrați vechea zonă neschimbată câteva zile, până când toate rezolvatoarele au preluat noile nameservere.

Greșelile pe care le găsim cel mai des

• www fără înregistrare, sau cu adresa IP a serverului vechi după o migrare.
• Două înregistrări SPF, sau SPF cu peste 10 interogări DNS (include-uri în lanț), invalid.
• MX spre serverul de găzduire, dar e-mailul mutat la Google, cu rutarea din cPanel pe Local: mesajele din formulare „dispar”.
• DKIM generat, dar înregistrarea neadăugată la registrar, fiindcă zona nu era în cPanel.
• CAA rămas de la vechea găzduire, care permitea doar autoritatea de acolo; AutoSSL eșuează.
• TTL de 86400 pe A cu o zi înainte de migrare: o zi de propagare.
• Înregistrări TXT de verificare șterse „că nu mai folosesc”, urmate de pierderea proprietății în Search Console.

Verificarea trimestrială

O interogare a fiecărui tip de mai sus, comparată cu lista așteptată, plus un test de livrare a e-mailului (un mesaj spre Gmail, cu verificarea antetelor SPF, DKIM și DMARC: toate pass), plus starea certificatelor în SSL/TLS Status. Zece minute, de patru ori pe an, previn cele mai frecvente pene. Scanerul nostru de securitate verifică automat CAA, DMARC, MTA-STS și DNSSEC pe orice domeniu, cu explicații pentru fiecare lipsă, la scanerul de securitate GOAI.

Surse

• Documentația cPanel, Zone Editor: tipurile de înregistrări acceptate și modificarea lor.
• Documentația cPanel: Email Deliverability, Email Routing și uneltele înrudite.