Un site poate parea cazut fara ca serverul web sa aiba vreo problema.
Pentru utilizator, diferenta nu exista. Scrie domeniul in browser, pagina nu se incarca, deci site-ul este cazut. Pentru admin, diferenta este enorma. Una este sa ai nginx/apache picat, aplicatia blocata sau serverul fara resurse. Alta este ca domeniul nu se mai rezolva corect.
Incidentul recent din zona .de a fost un exemplu foarte bun pentru genul asta de problema. Multe site-uri au parut indisponibile, desi serverele lor puteau fi perfect ok. Problema era in DNSSEC, la nivel de zona/TLD, unde semnaturi invalide au facut ca resolvere care valideaza DNSSEC sa trateze raspunsurile ca fiind gresite si sa intoarca SERVFAIL.
Partea ciudata, dar importanta, este ca nu trebuie neaparat ca domeniul tau sa aiba DNSSEC activ complet ca sa simti impactul. Daca problema este mai sus, in zona parinte, resolverul tot trebuie sa valideze lantul de incredere si delegarea. In anumite cazuri, chiar si lipsa unui DS trebuie dovedita criptografic. Daca acea dovada este stricata, resolverul poate refuza raspunsul.
De aici apar situatiile aparent ilogice:
dig @1.1.1.1 domeniu.example A
dig @8.8.8.8 domeniu.example A
dig @9.9.9.9 domeniu.example AUn resolver poate raspunde corect, altul poate da SERVFAIL, altul poate merge doar pentru ca are inca raspunsul in cache. Unele resolvere pot servi raspunsuri vechi pentru o perioada, altele pot fi mai stricte, iar unele pot aplica mitigari temporare cand problema este confirmata public.
Si aici apare ciudatenia in monitoring: acum merge, peste cateva minute nu mai merge, apoi iar merge.
Nu inseamna neaparat ca serverul web pica si isi revine. Poate insemna ca verificarea ajunge prin resolvere diferite, noduri diferite sau cache diferit. Un check poate primi un raspuns DNS valid, urmatorul poate primi SERVFAIL. Din afara arata ca un downtime intermitent. Din server logs poate sa nu se vada nimic, pentru ca requestul nici nu mai ajunge la server.
Asta este partea care consuma timp. Te uiti in load, nginx, apache, PHP, aplicatie, firewall, TLS, backend, loguri. Totul pare ok. Monitoring-ul insa continua sa trimita alerte: resolved, failed, resolved, failed. Si incepe sa para ca ai o problema fantoma in infrastructura ta, cand de fapt problema este in rezolvarea numelui.
De asta, cand un site pare indisponibil, primul test nu ar trebui sa fie restart la web server.
Cateva comenzi simple pot scurta mult investigatia:
dig domeniu.example A
dig @1.1.1.1 domeniu.example A
dig @8.8.8.8 domeniu.example A
dig @9.9.9.9 domeniu.example A
dig +trace domeniu.example
delv domeniu.example
curl -I https://domeniu.exampleCe urmaresti?
NXDOMAIN inseamna ca domeniul nu exista sau nu este delegat cum trebuie.
SERVFAIL este mai interesant. Poate indica o problema de DNSSEC, resolver, nameserver, delegare sau chain of trust.
Timeout-ul poate indica un nameserver care nu raspunde sau o problema de conectivitate.
Raspunsuri diferite intre resolvere pot indica cache, propagare incompleta, validare DNSSEC diferita sau o problema mai sus in lant.
delv este util mai ales cand suspectezi DNSSEC, pentru ca incearca sa arate mai clar unde se rupe validarea.
Abia dupa ce DNS-ul raspunde corect are sens sa continui cu:
curl -I https://domeniu.exampleDaca domeniul se rezolva si serverul raspunde HTTP, mergi mai departe spre aplicatie, TLS, reverse proxy sau backend. Dar daca domeniul nu se rezolva corect, restartul de nginx nu ajuta. Cel mult adauga zgomot peste o problema care era deja in alta parte.
Monitoring-ul poate raporta downtime perfect justificat din perspectiva lui: nu poate rezolva domeniul, deci nu poate verifica site-ul. Iar daca problema este intermitenta la nivel DNS, alertele pot parea haotice: un check trece, unul pica, apoi iar trece.
Lectia practica este simpla: cand un site pare cazut, verifica intai daca numele se rezolva corect.
Nu presupune direct ca e web serverul.
Uneori problema nu este in masina ta, nici in aplicatie, nici in firewall. Este in DNS. Si daca se rupe suficient de sus in lant, poate arata ca si cum jumatate de internet a uitat unde este site-ul tau.
DENIC – Analysis of the DNS outage on 5 May 2026
Cloudflare – When DNSSEC goes wrong: how we responded to the .de TLD outage
DENIC – Technical issue with .de domains resolved