Modulul 8 · 8.4
Greșeli frecvente
Modulul 8: Securitate și rezolvarea problemelor · Timp de citire: 10 minute
Obiectiv de învățare: După această lecție veți recunoaște cele mai frecvente zece greșeli DNS după simptomul lor și veți ști cum să le rezolvați.
Concepte-cheie: punctul de la final, domeniu dublat, modificare în locul greșit, două înregistrări SPF, CNAME pe domeniul rădăcină, AAAA uitat, MX fără adresă, proxy pentru e-mail, DS vechi după transfer, cache
Cum să utilizați această lecție
Greșelile de mai jos nu provin dintr-un manual, ci din întrebările pe care furnizorii de hosting le primesc în fiecare săptămână. Pentru fiecare greșeală vedeți: ce observă utilizatorul, cum demonstrați problema cu o singură întrebare și care este soluția. La o problemă, începeți întotdeauna cu aceleași două întrebări: ce servere de nume are domeniul (dig +short NS example.com) și ce răspunde serverul de nume autoritar (dig @<nameserver> <naam> <type>). Astfel rezolvați deja jumătate dintre cazuri.
1. Uitarea punctului de la final
Simptom: o înregistrare CNAME, MX sau NS nu funcționează; un serviciu spune „înregistrare negăsită”.
Demonstrare: dig +short CNAME shop.example.com returnează shops.platform.example.example.com.
Cauză: într-o zonă, un nume fără punct la final este relativ: panoul adaugă propriul dumneavoastră domeniu la final (lecția 2.2).
Soluție: scrieți numele țintă ca nume complet cu punct (shops.platform.example.). Unele panouri adaugă punctul automat; verificați după salvare ce este înregistrat efectiv.
2. Domeniul dublat în nume
Simptom: o verificare sau un control DKIM la un serviciu eșuează, deși înregistrarea „există”.
Demonstrare: dig +short TXT k2._domainkey.example.com nu returnează nimic, dar dig +short TXT k2._domainkey.example.com.example.com returnează ceva.
Cauză: serviciul indică numele complet (k2._domainkey.example.com), iar panoul dumneavoastră adaugă din nou domeniul la final.
Soluție: completați în câmpul de nume doar partea dinaintea domeniului: k2._domainkey. Panoul afișează de obicei sub câmp numele complet: verificați-l.
3. Modificare în locul greșit
Simptom: modificați o înregistrare, dar nu se schimbă nimic, nici după o zi.
Demonstrare: dig +short NS example.com returnează servere de nume ale unui alt furnizor decât cel la care ați făcut modificarea (de exemplu un constructor de site-uri sau Cloudflare).
Cauză: doar furnizorul serverelor de nume determină DNS-ul (lecția 2.1). Înregistrările de pe altă parte nu au niciun efect.
Soluție: modificați înregistrarea la furnizorul serverelor de nume sau readuceți serverele de nume la locul inițial. Un exemplu real: cineva a setat serverele de nume către o platformă de construcție a site-urilor pentru website, dar înregistrarea A pentru mail nu exista acolo. Rezultat: trimiterea funcționa, primirea nu, deoarece MX indica spre mail.example.com, iar acel nume nu mai exista.
4. Două înregistrări SPF
Simptom: e-mailurile ajung mai des în spam sau sunt respinse, de când ați conectat un serviciu nou.
Demonstrare: dig +short TXT example.com returnează două linii care încep cu v=spf1.
Cauză: noul serviciu a spus „adăugați această înregistrare SPF”, iar acest lucru a fost făcut literal. Cu două înregistrări SPF, SPF devine nevalid (permerror, RFC 7208), ceea ce este mai grav decât lipsa SPF.
Soluție: combinați-le într-o singură înregistrare: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Atenție la limita de zece căutări (lecția 4.3).
5. O înregistrare CNAME pe domeniul rădăcină
Simptom: panoul respinge înregistrarea sau, după salvare, e-mailul nu mai funcționează.
Demonstrare: serviciul solicită „creați o înregistrare CNAME pentru @”.
Cauză: o înregistrare CNAME nu poate coexista cu alte înregistrări, iar pe domeniul rădăcină există întotdeauna înregistrări SOA și NS (și adesea MX și TXT). Consultați lecția 3.2.
Soluție: utilizați pe @ înregistrarea A (și eventual AAAA) indicată de serviciu, iar CNAME doar pentru www sau un subdomeniu. Unii furnizori DNS au o opțiune ALIAS sau „CNAME flattening” pentru acest caz.
6. Uitarea înregistrării AAAA la un transfer
Simptom: după un transfer, o parte dintre vizitatori (adesea cei de pe mobil) văd în continuare site-ul vechi sau primesc o eroare de certificat.
Demonstrare: dig +short A example.com returnează noua adresă, dig +short AAAA example.com returnează încă o adresă a vechiului server.
Cauză: dispozitivele cu IPv6 folosesc de preferință înregistrarea AAAA. A fost modificată doar înregistrarea A.
Soluție: actualizați și înregistrarea AAAA sau eliminați-o dacă noul server nu are IPv6. Un exemplu real: la conectarea unei platforme de magazin online, pe lângă noua înregistrare A, trebuia eliminată și vechea înregistrare AAAA, altfel magazinul rămânea inaccesibil pentru o parte dintre vizitatori.
7. O înregistrare MX care nu indică spre nimic
Simptom: nu primiți e-mailuri; expeditorii primesc înapoi un mesaj de eroare.
Demonstrare: dig +short MX example.com returnează 10 mail.example.com., dar dig +short A mail.example.com nu returnează nimic (NXDOMAIN).
Cauză: o înregistrare MX indică spre un nume, iar acel nume trebuie să aibă o înregistrare A sau AAAA. Adesea, înregistrarea A pentru mail a dispărut la un transfer de servere de nume. O înregistrare MX nu poate indica nici spre o adresă IP, nici spre o înregistrare CNAME (RFC 2181).
Soluție: creați o înregistrare A pentru numele serverului de e-mail sau faceți ca MX să indice spre un nume care are o adresă.
8. E-mailul este în altă parte, dar vechiul server crede că trebuie să livreze el mesajele
Simptom: e-mailul din exterior ajunge corect la noul dumneavoastră furnizor, dar mesajele de pe propriul website (formular de contact, magazin online) nu ajung niciodată. Uneori primiți 550 Unknown user.
Demonstrare: MX indică spre noul furnizor, dar pe serverul web livrarea locală a e-mailului este încă activă.
Cauză: aceasta nu este o greșeală DNS, dar așa pare. Un server web care crede că deține el însuși căsuțele poștale nu verifică MX-ul.
Soluție: dezactivați livrarea locală în panoul de hosting (în DirectAdmin: căsuța de validare „Use this server to handle my e-mail”). Alte panouri au o setare similară, adesea numită „Remote mail exchanger” sau „e-mail extern”.
9. Proxy activat pentru e-mail
Simptom: la un furnizor DNS cu funcție de proxy (precum norul portocaliu de la Cloudflare), site-ul funcționează, dar programul de e-mail nu se poate conecta sau certificatul site-ului nu se reînnoiește.
Demonstrare: dig +short A mail.example.com returnează o adresă a proxy-ului, nu a serverului dumneavoastră de e-mail.
Cauză: un proxy web redirecționează doar traficul web, nu și e-mailul.
Soluție: dezactivați proxy-ul (norul gri, „DNS only”) pentru mail și toate numele folosite de programul dumneavoastră de e-mail. Pentru certificate: dezactivați temporar proxy-ul până la obținerea certificatului sau folosiți modul SSL corect la proxy.
10. DS vechi după un transfer
Simptom: după un transfer de servere de nume, domeniul dumneavoastră este inaccesibil pentru o parte din lume; alte persoane nu au nicio problemă.
Demonstrare: dig example.com @1.1.1.1 returnează SERVFAIL, dar dig +cd example.com @1.1.1.1 returnează totuși un răspuns. DNSViz (https://dnsviz.net/, lecția 8.1) colorează DS-ul cu roșu și desenează dedesubt o cheie gri, punctată, care nu mai există în zona dumneavoastră. Zonemaster și Verisign DNSSEC Debugger raportează același lucru în cuvinte.
Cauză: la registru există încă DS-ul vechiului furnizor (lecția 8.1). Doar resolverele care validează eșuează, de aceea nu toată lumea observă problema.
Soluție: actualizați DS-ul cu cheia noului furnizor sau eliminați-l și reactivați apoi DNSSEC.
Și „greșeala” care nu este o greșeală: cache-ul
Foarte des totul este corect, dar dumneavoastră încă vedeți răspunsul vechi. Recunoașteți situația astfel: dig @<nameserver> returnează noul răspuns, un instrument online de verificare din alte țări la fel, doar computerul dumneavoastră nu. Soluție: fereastră privată, telefon prin 4G/5G sau golirea cache-ului (lecția 8.2). Și o linie uitată în fișierul hosts al computerului dumneavoastră (dintr-un test anterior unui transfer) produce acest efect: eliminați acea linie.
O capcană înrudită: interogarea unui nume nou înainte de a-l fi creat. Resolverul reține atunci „nu există” (cache negativ), iar noul nume funcționează abia după mai mult timp (lecția 6.2).
În practică: cum arată într-un panou
Multe panouri previn o parte dintre aceste greșeli. De exemplu, Contul meu WebOké avertizează dacă lipsește punctul de la final și afișează sub câmpul de nume numele complet; DirectAdmin refuză înregistrările care nu sunt valide, cu mesajul „Error Writing Records”. Cloudflare și alți furnizori au avertismente similare. Înainte de modificări majore, faceți o copie de siguranță sau un export al zonei dumneavoastră, astfel încât să vă puteți întoarce oricând la starea anterioară.
Rezumat
- Începeți întotdeauna cu: ce servere de nume are domeniul și ce spune serverul de nume autoritar.
- Majoritatea greșelilor se află în nume (punct, domeniu dublat) sau în locul greșit (furnizorul greșit).
- O singură înregistrare SPF, fără CNAME pe @, transferați și AAAA, MX spre un nume cu adresă.
- SERVFAIL după un transfer este de obicei un DS vechi.
- Dacă doar dumneavoastră vedeți răspunsul vechi, este vorba de cache-ul sau fișierul hosts propriu.
Quiz
Exercițiu
Exercițiul Z8.4: Recunoașterea greșelilor. Primiți cinci cazuri scurte, însoțite de rezultatul comenzii dig (în mediul cursului). Alegeți pentru fiecare caz care dintre cele zece greșeli este. Apoi o investigație reală: aflați cu dig sau un instrument online care înregistrare este greșită pentru dnssec-failed.org (starea și ce returnează +cd) și dacă wikipedia.org are exact o singură înregistrare SPF.
Lectură suplimentară
Aceste articole descriu soluțiile în panourile WebOké; la alți furnizori, butoanele au denumiri diferite.
- Site-ul web sau e-mailul nu funcționează după o mutare sau o modificare DNS: verificați-vă domeniul
- Cât durează o modificare de nameserver sau DNS și ce se întâmplă dacă nu o vedeți?
- Manual DirectAdmin 18.7: Domeniul meu nu funcționează încă după o transferare sau modificare
- Manual DirectAdmin 18.9: Nu mai primesc e-mailuri
- Manual DirectAdmin 5.4: Înregistrările CNAME și punctul de la final
- Trimiterea e-mailurilor prin PHP nu funcționează, înregistrările MX trimit în altă parte
- Utilizați nameservere proprii sau externe (precum Cloudflare) pentru domeniul dumneavoastră