Server DNS Nu Răspunde: Ghid Complet de Depanare

O eroare de tip „DNS server not responding” înseamnă că sistemul de operare a trimis o interogare de rezoluție către un resolver DNS și nu a primit niciun răspuns în intervalul de timeout — astfel că browserul nu a obținut niciodată adresa IP necesară pentru a deschide o conexiune TCP. Rezultatul este o pagină care nu se încarcă, chiar și atunci când conexiunea fizică la rețea funcționează perfect. Cauza principală poate fi oriunde în lanțul de rezoluție: stub resolver-ul local, resolver-ul recursiv al furnizorului de servicii de internet, un server autoritar din amonte sau un dispozitiv de rețea configurat greșit între dvs. și oricare dintre acestea.

Acest ghid parcurge fiecare nivel al acelui lanț — de la o repornire a routerului în 30 de secunde până la înlocuirea driver-ului la nivel scăzut — cu comenzi exacte pentru Windows, macOS și Linux, plus o comparație a resolverelor publice și o matrice de decizie pentru a vă ajuta să izolați rapid defecțiunea.

Ce se întâmplă de fapt în timpul rezoluției DNS

Înainte de a remedia eroarea, înțelegerea căii de rezoluție previne efortul irosit. Când tastați example.com într-un browser:

1. Sistemul de operare verifică cache-ul DNS local (și fișierul hosts).
2. Dacă nu există nicio înregistrare în cache, stub resolver-ul transmite interogarea către resolver-ul recursiv configurat pe interfața de rețea (de obicei routerul dvs. sau un server atribuit de ISP).
3. Resolver-ul recursiv parcurge ierarhia DNS — servere root, servere de nume TLD, servere de nume autoritare — și returnează înregistrarea finală A sau AAAA.
4. Sistemul de operare stochează rezultatul în cache pentru durata TTL-ului înregistrării și transmite IP-ul browserului.

O eroare „not responding” apare de obicei la pasul 2 sau 3. Stub resolver-ul a trimis un pachet UDP pe portul 53 și a primit tăcere. Acea tăcere are un număr surprinzător de mare de cauze.

Cauzele principale ale erorii DNS Server Not Responding

Defecțiuni la nivelul resolver-ului DNS

• Resolver-ul recursiv configurat este temporar supraîncărcat sau offline.
• Infrastructura DNS a ISP-ului dvs. este sub un atac DDoS sau se află în mentenanță.
• Adresa IP a resolver-ului s-a schimbat, dar dispozitivul dvs. păstrează în continuare valoarea veche.

Probleme de rețea locală și hardware

• Bug-uri în firmware-ul routerului care corup releu-ul DNS (frecvente la dispozitivele de consum după perioade lungi de funcționare).
• Un lease DHCP care a transmis o adresă de server DNS învechită sau invalidă.
• Un cablu Ethernet defect sau un semnal Wi-Fi degradat care cauzează pierderi de pachete specifice pe portul UDP 53.

Configurări greșite la nivel de gazdă

• Un cache DNS local corupt sau otrăvit care conține răspunsuri negative învechite.
• O adresă DNS introdusă manual care este greșită sau nu mai este accesibilă.
• O intrare în fișierul hosts care intră în conflict cu răspunsul DNS așteptat.

Interferența software-ului de securitate

• Firewall-uri sau instrumente de securitate endpoint care blochează portul UDP/TCP 53 de ieșire sau interceptează interogările DNS pentru inspecție și apoi le elimină.
• Clienți VPN care redirecționează traficul DNS printr-un endpoint de tunel care este momentan inaccesibil.
• Software de control parental care acționează ca un proxy DNS local și se blochează silențios.

Probleme de driver și la nivel de sistem de operare

• Un driver NIC învechit sau corupt care gestionează greșit datagramele UDP.
• Serviciul Windows DNS Client (Dnscache) într-o stare blocată.
• Un proces macOS mDNSResponder care a consumat memorie excesivă și a încetat să răspundă.

Remedieri pas cu pas: Ordonate după efort și probabilitate

Parcurgeți-le în ordine. Fiecare pas durează mai puțin de cinci minute și elimină un nivel specific al problemei.

Pasul 1: Verificați mai întâi domeniul de aplicare al problemei

Înainte de a modifica orice setări, rulați un diagnostic rapid pentru a confirma că DNS este de fapt punctul de defecțiune și nu conectivitatea generală:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Dacă ping 8.8.8.8 reușește, dar nslookup example.com eșuează, rezoluția DNS este definitiv problema. Dacă ping 8.8.8.8 eșuează de asemenea, problema este mai profundă — probabil rutare sau conectivitate fizică — iar DNS este un simptom, nu cauza.

Pasul 2: Reporniți routerul și modemul

O repornire completă șterge cache-ul intern al releului DNS al routerului, resetează lease-urile DHCP și restabilește conexiunea WAN cu atribuiri proaspete de servere DNS de la ISP-ul dvs.

1. Deconectați cablul de alimentare atât de la modem, cât și de la router.
2. Așteptați un minut întreg de 30 de secunde (condensatoarele au nevoie de timp pentru a se descărca).
3. Porniți mai întâi modemul; așteptați să se sincronizeze complet (lumina WAN stabilă).
4. Porniți routerul al doilea; așteptați să finalizeze secvența de pornire.
5. Reconectați dispozitivul și rulați din nou testul nslookup din Pasul 1.

Caz limită: Dacă routerul dvs. funcționează de săptămâni fără repornire, releul său DNS (dnsmasq sau similar) poate avea un cache plin sau o scurgere de memorie. Unele routere furnizate de ISP au bug-uri cunoscute prin care releul DNS oprește transmiterea interogărilor după un anumit prag de funcționare. O repornire este cea mai rapidă remediere.

Pasul 3: Goliți cache-ul DNS local

Intrările din cache învechite sau corupte determină sistemul de operare să returneze rezultate greșite sau să genereze eșecuri de căutare înainte ca o interogare să părăsească măcar mașina.

Windows:

ipconfig /flushdns

Ar trebui să vedeți: Successfully flushed the DNS Resolver Cache.

macOS (specific versiunii — utilizați comanda corectă pentru sistemul dvs. de operare):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Pasul 4: Schimbați la un resolver DNS public fiabil

Dacă resolver-ul DNS al ISP-ului dvs. este problema, trecerea la un resolver public bine întreținut este cea mai rapidă soluție de avarie. Tabelul de mai jos compară cele mai utilizate opțiuni:

Cloudflare 1.1.1.1 măsoară în mod constant cea mai mică latență medie globală a interogărilor în benchmark-uri independente. Quad9 este alegerea mai bună dacă doriți blocare pasivă a domeniilor malware fără a gestiona un filtru DNS separat.

Schimbarea DNS pe Windows 10/11:

1. Deschideți Setări > Rețea și Internet > Modificare opțiuni adaptor.
2. Faceți clic dreapta pe adaptorul activ și selectați Proprietăți.
3. Selectați Internet Protocol Version 4 (TCP/IPv4) și faceți clic pe Proprietăți.
4. Selectați Utilizați următoarele adrese de server DNS.
5. Introduceți IP-urile resolver-ului primar și secundar ales.
6. Faceți clic pe OK, apoi rulați ipconfig /flushdns pentru a șterge intrările din cache învechite.

Pentru rețelele IPv6, repetați procesul pentru Internet Protocol Version 6 (TCP/IPv6) folosind adresele IPv6 ale resolver-ului (de ex., Cloudflare: 2606:4700:4700::1111 și 2606:4700:4700::1001).

Schimbarea DNS pe macOS:

1. Deschideți Setări sistem > Rețea.
2. Selectați conexiunea activă și faceți clic pe Detalii.
3. Accesați fila DNS.
4. Eliminați intrările existente cu butonul –, apoi adăugați IP-urile resolver-ului ales cu +.
5. Faceți clic pe OK și Aplicați.

Schimbarea DNS pe Linux (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Pasul 5: Reporniți serviciul DNS Client (Windows)

Serviciul Windows DNS Client (Dnscache) stochează în cache numele rezolvate și gestionează stub resolver-ul. Dacă intră într-o stare blocată, toate interogările DNS eșuează silențios.

net stop dnscache
net start dnscache

Alternativ, prin consola Servicii: apăsați Win + R, tastați services.msc, localizați DNS Client, faceți clic dreapta și selectați Repornire. Rețineți că pe unele versiuni de Windows 11 opțiunea de repornire este inactivă în interfața grafică — utilizați în schimb metoda din linia de comandă.

Pasul 6: Dezactivați temporar firewall-ul sau software-ul de securitate

Firewall-urile terțe și suitele de protecție endpoint interceptează uneori traficul DNS pentru inspecție și, din cauza unui conflict de reguli sau a unui bug al motorului, elimină complet pachetele.

Windows Defender Firewall (doar test temporar):

netsh advfirewall set allprofiles state off

Reactivați imediat după testare:

netsh advfirewall set allprofiles state on

macOS:

Navigați la Setări sistem > Confidențialitate și securitate > Firewall și dezactivați-l în scopuri de testare.

Dacă dezactivarea firewall-ului rezolvă problema, nu îl lăsați dezactivat. În schimb, deschideți editorul de reguli al firewall-ului și căutați reguli care blochează traficul de ieșire pe portul UDP 53 și portul TCP 53. Adăugați reguli de permisiune explicite pentru IP-urile resolver-ului DNS ales.

Clienții VPN merită o atenție specială aici. Multe aplicații VPN instalează un proxy DNS local pe 127.0.0.1:53 și redirecționează toate interogările prin tunel. Dacă serverul VPN este inaccesibil, fiecare interogare DNS eșuează. Deconectați VPN-ul, testați DNS, apoi reconectați și verificați setările de scurgere DNS ale clientului VPN.

Pasul 7: Încercați un alt browser

Anumite extensii de browser — în special blocante de reclame, instrumente de confidențialitate și plugin-uri de securitate — interceptează interogările DNS-over-HTTPS (DoH) sau modifică comportamentul resolver-ului de sistem. Dacă DNS funcționează într-un browser, dar nu în altul, problema este la nivel de extensie, nu la nivel de sistem de operare.

Testați mai întâi într-o fereastră privată/incognito (extensiile sunt de obicei dezactivate). Dacă aceasta rezolvă problema, dezactivați extensiile una câte una pentru a identifica vinovatul. Dacă problema persistă în toate browserele, defecțiunea se află la nivelul sistemului de operare sau al rețelei.

Pasul 8: Actualizați sau reveniți la versiunea anterioară a driver-elor de rețea

Un driver NIC corupt poate cauza gestionarea eratică a pachetelor UDP, care se manifestă ca eșecuri intermitente DNS chiar și atunci când conexiunile TCP funcționează.

Windows — actualizare prin Device Manager:

1. Apăsați Win + X și selectați Device Manager.
2. Extindeți Adaptoare de rețea.
3. Faceți clic dreapta pe adaptorul dvs. și selectați Actualizare driver > Căutare automată de drivere.
4. Reporniți după instalare.

Windows — revenire la un driver actualizat recent:

Dacă eroarea DNS a apărut imediat după o actualizare Windows, noul driver poate fi regresia. În Device Manager, faceți clic dreapta pe adaptor, selectați Proprietăți > Driver > Revenire driver.

macOS: Driver-ele NIC sunt incluse în macOS. Aplicați toate actualizările de sistem în așteptare prin Setări sistem > General > Actualizare software.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Pasul 9: Verificați conexiunile fizice de rețea

Dacă utilizați o conexiune prin cablu, un cablu Ethernet degradat cauzează pierderi intermitente de pachete care afectează disproporționat protocoalele bazate pe UDP, cum ar fi DNS (care nu are retransmisie încorporată la nivelul aplicației).

• Reintroduceți ambele capete ale cablului Ethernet.
• Înlocuiți cablul cu unul cunoscut ca funcțional.
• Testați un alt port pe router sau switch.
• Verificați LED-urile indicatoare de legătură ale NIC-ului — o lumină verde sau chihlimbar stabilă confirmă legătura fizică; o lumină care clipește sau absentă indică o problemă de nivel 1.

Pasul 10: Rulați instrumentul de depanare a rețelei Windows

Windows include un diagnostic automatizat care poate detecta și remedia configurările greșite DNS comune, inclusiv resetarea clientului DNS și ștergerea cache-ului.

Navigați la Setări > Sistem > Depanare > Alte instrumente de depanare > Conexiuni la Internet și rulați expertul. Acesta va încerca reparații automate și va raporta ce a găsit. Deși nu surprinde fiecare scenariu, este o verificare utilă de bun simț care durează mai puțin de un minut.

Pasul 11: Verificați și editați fișierul Hosts

Un fișier hosts corupt sau modificat malițios poate suprascrie DNS pentru domenii specifice, cauzând eșecuri de rezoluție care arată identic cu o eroare de server DNS.

Windows — deschideți cu privilegii ridicate:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Căutați intrări care redirecționează domenii comune către 0.0.0.0 sau 127.0.0.1. Software-ul de securitate, blocantele de reclame și malware-ul modifică toate acest fișier. Eliminați orice intrări suspecte, salvați și goliți cache-ul DNS.

Pasul 12: Resetați stiva TCP/IP și Winsock (Windows)

Dacă mai multe componente de rețea sunt configurate greșit, o resetare completă a stivei este mai rapidă decât căutarea setărilor individuale:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Reporniți mașina după rularea tuturor celor cinci comenzi. Aceasta resetează parametrii de registry TCP/IP și catalogul Winsock la starea lor implicită fără a afecta driver-ele adaptorului de rețea.

Pasul 13: Resetați routerul la setările din fabrică

Utilizați aceasta ca ultimă soluție înainte de a contacta ISP-ul. O resetare la setările din fabrică șterge toată configurația personalizată — SSID-uri Wi-Fi, parole, reguli de redirecționare a porturilor și orice setări DNS personalizate — și restaurează routerul la starea sa inițială.

Majoritatea routerelor au un buton de resetare încastrat. Țineți-l apăsat cu un ac timp de 10–15 secunde până când LED-urile de stare ciclează. După repornirea routerului, reconfigurați rețeaua de la zero. Dacă DNS funcționează imediat după resetare, o setare de router configurată greșit a fost cauza.

Pasul 14: Contactați ISP-ul dvs.

Dacă fiecare pas de mai sus eșuează și problema afectează toate dispozitivele din rețeaua dvs., problema se află aproape sigur în amontele routerului dvs. — fie la infrastructura de resolver recursiv a ISP-ului, fie pe legătura WAN în sine. Contactați suportul tehnic al ISP-ului dvs. cu următoarele informații pregătite:

• Rezultatele nslookup example.com folosind atât DNS-ul ISP-ului dvs., cât și un resolver public precum 8.8.8.8.
• Dacă problema este intermitentă sau constantă.
• Dacă trecerea la un hotspot mobil (ocolind complet ISP-ul dvs.) rezolvă problema.

Ultimul test este verificarea definitivă de izolare a ISP-ului.

Configurarea DNS pentru administratorii de servere

Dacă gestionați un mediu de VPS Hosting sau un Server Dedicat, erorile DNS capătă dimensiuni suplimentare. Un resolver configurat greșit pe un server afectează fiecare aplicație care rulează pe acesta — serverele web, livrarea de e-mail, managerii de pachete și agenții de monitorizare depind toți de rezoluția fiabilă a numelor.

Verificați configurația resolver-ului pe serverele Linux:

cat /etc/resolv.conf

Un fișier sănătos ar trebui să conțină cel puțin două linii nameserver care indică spre resolver-e fiabile:

nameserver 1.1.1.1
nameserver 8.8.8.8

Pe sistemele care utilizează systemd-resolved, /etc/resolv.conf este un symlink. Editarea sa directă nu are niciun efect. Utilizați în schimb resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Testați latența rezoluției de pe un server:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Dacă timpii de interogare depășesc constant 200ms, resolver-ul este geografic îndepărtat sau sub sarcină. Treceți la un resolver cu un punct de prezență mai aproape de centrul de date al serverului dvs.

Pentru serverele care rulează medii cPanel VPS, configurarea DNS este gestionată și prin pagina Basic cPanel & WHM Setup din WHM. Asigurați-vă că resolver-ele listate acolo corespund cu cele din /etc/resolv.conf pentru a evita problemele de rezoluție split-brain.

DNS și înregistrarea domeniilor: Conexiunea din amonte

O eroare „DNS server not responding” pe propriul dvs. domeniu — mai degrabă decât al altcuiva — urmărește adesea configurarea serverului de nume la nivelul registrarului. Dacă ați înregistrat recent un domeniu sau ați schimbat serverele de nume prin Înregistrare Domeniu, propagarea durează până la 48 de ore. În acea fereastră, unele resolver-e din lume păstrează în continuare înregistrările NS vechi.

Utilizați un verificator de propagare sau interogați direct mai multe resolver-e distribuite geografic:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Discrepanțele dintre răspunsurile resolver-elor în timpul propagării sunt normale. Dacă răspunsurile sunt în continuare inconsistente după 48 de ore, înregistrările NS la registrar sunt probabil configurate greșit.

Securizarea DNS: DNSSEC și DNS-over-HTTPS

Interogările DNS standard călătoresc în text simplu pe portul UDP 53, făcându-le vulnerabile la atacuri de DNS spoofing și cache poisoning. Două tehnologii complementare abordează această problemă:

DNSSEC adaugă semnături criptografice la înregistrările DNS, permițând resolver-elor să verifice că un răspuns este autentic și nu a fost alterat. Protejează integritatea datelor, dar nu criptează interogarea în sine.

DNS-over-HTTPS (DoH) și DNS-over-TLS (DoT) criptează întreaga interogare DNS, prevenind interceptarea și manipularea pe cale. Browserele moderne suportă DoH nativ. Pentru a-l activa la nivel de sistem pe Windows 11, navigați la Setări > Rețea și Internet > [adaptorul dvs.] > Atribuire server DNS > Editare și setați criptarea la Numai criptat (DNS over HTTPS).

Pentru servere, configurați systemd-resolved să utilizeze DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Dacă rulați Găzduire Email sau gestionați propriul server de e-mail, configurarea corectă DNS — în special înregistrările SPF, DKIM și DMARC — este critică pentru livrabilitate. Eșecurile DNS pe un server de e-mail nu doar că întrerup navigarea de ieșire; ele cauzează e-mail-uri amânate sau respinse și validare eșuată a certificatelor TLS.

Certificate SSL și dependența de DNS

Emiterea și reînnoirea certificatelor TLS depind în întregime de DNS. Autoritățile de certificare care efectuează validarea domeniului (DV) prin provocarea DNS-01 ACME trebuie să rezolve înregistrarea TXT _acme-challenge a domeniului dvs. Dacă DNS este defect la momentul reînnoirii, instrumentele automatizate precum Certbot vor eșua silențios, iar Certificatele SSL vor expira — ducând HTTPS-ul cu ele.

Configurați monitorizarea atât pentru rezoluția DNS, cât și pentru expirarea certificatelor. O verificare simplă bazată pe cron:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Matrice de decizie: Izolarea nivelului de defecțiune DNS

Utilizați această matrice pentru a identifica nivelul de defecțiune înainte de a petrece timp pe remedieri care nu se vor aplica situației dvs.

Listă de verificare a punctelor cheie tehnice

• Rulați mai întâi ping 8.8.8.8. Dacă eșuează, DNS nu este problema dvs. principală — remediați mai întâi rutarea sau conectivitatea fizică.
• Goliți întotdeauna cache-ul DNS local după schimbarea setărilor resolver-ului; intrările învechite vor masca dacă remedierea a funcționat.
• Treceți la Cloudflare 1.1.1.1 sau Quad9 9.9.9.9 ca primă schimbare de resolver — ambele sunt mai rapide și mai fiabile decât majoritatea resolver-elor ISP.
• Pe Windows, dacă interfața grafică a Serviciilor grizează opțiunea de repornire a DNS Client, utilizați net stop dnscache && net start dnscache dintr-un prompt de comandă ridicat.
• Pe serverele Linux, nu editați niciodată direct /etc/resolv.conf pe sistemele systemd-resolved — modificările sunt suprascrise la repornirea rețelei. Utilizați resolvectl sau nmcli.
• Clienții VPN sunt un vinovat silențios frecvent. Testați întotdeauna cu VPN-ul deconectat înainte de a escalada.
• Pentru propriile dvs. domenii, dig +trace ocolește toate cache-urile și arată exact ce returnează serverele autoritare — utilizați-l înainte de a presupune o problemă de resolver.
• Activați validarea DNSSEC și DNS-over-TLS/HTTPS pe serverele de producție pentru a elimina o întreagă clasă de eșecuri DNS bazate pe spoofing.
• Pe servere, monitorizați împreună atât sănătatea rezoluției DNS, cât și expirarea certificatelor SSL — o defecțiune DNS va cauza silențios eșecul reînnoirii certificatelor zile mai târziu.

Întrebări frecvente

De ce eșuează DNS chiar dacă am o conexiune la internet funcțională?

Rezoluția DNS utilizează pachete UDP pe portul 53, care este separat de conexiunile TCP pe care browserul dvs. le utilizează pentru a încărca pagini. O regulă de firewall, un releu DNS blocat pe routerul dvs. sau un resolver oprit pot bloca portul 53 în mod specific, lăsând tot celălalt trafic neafectat. Rulați ping 8.8.8.8 pentru a confirma conectivitatea IP, apoi nslookup example.com pentru a confirma că DNS este eșecul izolat.

Este sigur să utilizați permanent Google sau Cloudflare DNS în loc de resolver-ul ISP-ului meu?

Da, pentru majoritatea utilizatorilor și cazurilor de utilizare. Atât Google Public DNS, cât și Cloudflare 1.1.1.1 suportă validarea DNSSEC și oferă SLA-uri de disponibilitate mai ridicate decât resolver-ele ISP tipice. Compromisul este că interogările dvs. DNS sunt procesate de un furnizor de infrastructură terț, mai degrabă decât de ISP-ul dvs. Cloudflare publică o politică strictă de neinregistrare a interogărilor; Google păstrează jurnale anonimizate timp de până la 48 de ore.

Care este diferența dintre golirea cache-ului DNS și schimbarea serverului DNS?

Golirea cache-ului șterge rezultatele de rezoluție stocate local, forțând sistemul de operare să trimită interogări proaspete către resolver-ul configurat. Schimbarea serverului DNS redirecționează unde sunt trimise acele interogări. Dacă cache-ul dvs. conține o intrare otrăvită sau învechită, golirea o remediază fără a schimba resolver-ul. Dacă resolver-ul în sine este oprit sau lent, schimbarea adresei serverului o remediază fără a atinge cache-ul. În practică, efectuarea ambelor împreună după o defecțiune DNS este abordarea cea mai curată.

De ce reușește nslookup, dar browserul afișează în continuare o eroare DNS?

Browserele utilizează din ce în ce mai mult propria implementare DNS-over-HTTPS, care ocolește complet resolver-ul sistemului de operare. Dacă endpoint-ul DoH configurat al browserului este inaccesibil, acesta poate eșua chiar și atunci când resolver-ul de sistem funcționează bine. Verificați setările de confidențialitate sau securitate ale browserului pentru o opțiune „DNS securizat” sau „DNS over HTTPS” și fie dezactivați-o, fie îndreptați-o spre un furnizor DoH accesibil.

Cum diagnostichez problemele DNS pe un VPS Linux fără interfață grafică?

Utilizați dig, nslookup și resolvectl din linia de comandă. Rulați dig @1.1.1.1 example.com pentru a testa direct un resolver specific, ocolind complet configurația locală. Rulați resolvectl status pentru a vedea ce resolver utilizează în prezent sistemul și dacă DNSSEC este activ. Verificați /etc/resolv.conf pentru a confirma serverele de nume configurate și verificați că fișierul nu este un symlink defect cu ls -la /etc/resolv.conf.