Acasă
» Cum să
»
Erori de căutare DNS în Debian 12: Reparare eroare rezolvată de systemd
Erori de căutare DNS în Debian 12: Reparare eroare rezolvată de systemd
Dacă Debian 12 afișează „Eroare temporară în rezoluția numelui”, verificați serviciul de resolver, /etc/resolv.conflinkul și serverele DNS listate cu resolvectl— în această ordine. O repornire a serviciului ajută doar atunci când serviciul este oprit; un link defect sau un server upstream inaccesibil necesită o altă soluție.
Aceste instrucțiuni se aplică sistemelor Debian 12 (Bookworm) configurate să utilizeze systemd-resolved. Debian a împărțit acel resolver într-un pachet separat și nu l-a setat ca implicit, așa cum se explică în notele de lansare Debian 12 . Dacă instalarea dvs. utilizează un alt manager DNS, păstrați acel manager în control, în loc să îi impuneți aceste setări.
1. Identificați unde eșuează rezoluția numelui
Începeți cu ruta de rețea și o căutare a numelui de gazdă. Executați comenzile local sau într-un terminal care va rămâne deschis dacă rețeaua se modifică:
ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org
O rută implicită și o conexiune IP numerică funcțională sugerează că mașina poate ajunge la rețea fără DNS. Un ping nereușit în sine nu dovedește o rută întreruptă: rețelele pot bloca răspunsurile ICMP echo. Dacă interfeței îi lipsește o adresă sau o rută, corectați mai întâi conexiunea la rețea.
resolvectl statusafișează serverele DNS și domeniile atribuite global sau interfețelor individuale. resolvectl querytestează rezolvatorul systemd; getent ahoststestează calea de căutare a numelui de gazdă utilizată în mod obișnuit de aplicațiile Linux. Distincția ajută la izolarea erorii.
Observație
Următoarea verificare
Fără adresă sau rută implicită
Corectați configurația interfeței, gateway-ului sau DHCP înainte de DNS.
resolvectlnu se poate conecta la serviciul său
Verificați dacă systemd-resolvedeste instalat și rulează.
Inspectați adresele DNS din amonte, rutarea DNS și accesul la firewall.
O vizualizare terminal grupează ruta implicită de rețea, atribuirea serverului DNS și o căutare a numelui de gazdă la nivel de aplicație pentru diagnosticarea inițială.
2. Asigurați-vă că systemd-resolved este instalat și activ
Pe Debian 12, prezența systemd nu garantează că este instalat pachetul separat de resolver. Verificați pachetul și unitatea înainte de a modifica orice fișiere DNS:
dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager
Dacă pachetul este instalat, dar serviciul este inactiv, porniți-l și activați-l pentru porniri viitoare:
Comanda finală ar trebui să raporteze [numele erorii/errorului] active. Dacă unitatea se defectează, verificați mesajele de eroare reale în loc să o reporniți în mod repetat:
Dacă pachetul lipsește, instalați-l cu sudo apt install systemd-resolvednumai după ce aveți acces funcțional la depozitul de pachete. Instalarea acestuia modifică controlul asupra /etc/resolv.conf, așa că verificați mai întâi orice configurare NetworkManager, VPN sau DNS static. Debian documentează această modificare a pachetului în notele sale de actualizare Bookworm .
Afișajul stării de service ilustrează unde trebuie căutate unitatea încărcată, starea activă și mesajele de pornire.
3. Reparați legătura rezolverului numai dacă este greșită
Stub-ul standard systemd-resolvedascultă 127.0.0.53. Fișierul său de compatibilitate recomandat este /run/systemd/resolve/stub-resolv.conf, care poate fi legat de /etc/resolv.conf. Verificați mai întâi modul curent:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
O legătură către /run/systemd/resolve/resolv.confeste, de asemenea, un mod acceptat, dar programele care o utilizează contactează DNS-ul din amonte direct în loc de stub-ul local. Nu considerați că această legătură este întreruptă doar pentru că este diferită. Manualul de service Debian systemd-resolved explică modurile acceptate.
Dacă utilizați intenționat stub-ul local, serviciul rulează, ascultătorul de stub-uri este activat și cel existent /etc/resolv.conflipsește, este blocat sau indică un resolver învechit, restaurați link-ul recomandat. Mai întâi faceți o copie de rezervă a unui fișier sau a unui link existent; săriți peste copiere dacă nu există niciun fișier:
Nu rulați acea înlocuire pe o gazdă pe care un alt serviciu o gestionează intenționat /etc/resolv.conf. O intrare locală nameserver 127.0.0.53necesită, de asemenea, un ascultător de stub funcțional; simpla scriere a acelei adrese nu creează un serviciu DNS. Pe o mașină la distanță, păstrați o a doua metodă de acces înainte de a edita setările resolverului.
Verificarea legăturilor simbolice arată ținta așteptată atunci când Debian este configurat în mod deliberat să utilizeze stub-ul local rezolvat de systemd.
4. Corectați un server DNS în amonte absent sau inaccesibil
Când resolvectl statusnu se afișează niciun server DNS amonte adecvat sau un server configurat este inaccesibil, remediați sursa acelei atribuiri. Setările DNS dinamice pot proveni de la DHCP, NetworkManager, systemd-networkd sau o rețea VPN. Verificați ce interfață transportă ruta implicită și ce server DNS aparține acelei interfețe.
Pentru un scurt test de diagnosticare într-o rețea care permite DNS public, atribuiți rezolveri publici cunoscuți acelei interfețe. Înlocuiți ens33cu interfața reală de la ip -br address:
sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org
Aceste două adrese sunt documentate de Cloudflare ca adrese publice ale rezolverului DNS . resolvectl dnsModificarea este o configurație în timpul rulării; un administrator de rețea o poate înlocui atunci când legătura se reconectează. Dacă căutarea funcționează acum, remediați sursa DNS persistentă în loc să vă bazați pe această comandă temporară.
Cu NetworkManager, inspectați conexiunea activă utilizând nmcli connection show --activeși ajustați setările DNS sau comportamentul DHCP ale acelei conexiuni. Cu systemd-networkd, puneți DNS=setările dorite în fișierul corespunzător .networkși reîncărcați sau reconfigurați rețeaua la un moment sigur. Consultați manualul Debian systemd.network și manualul de configurare Debian NetworkManager . Reconectarea unei interfețe gestionate poate întrerupe o sesiune SSH.
Preferați serverele DNS ale organizației sau ale VPN-ului pentru numele interne. Nu se poate presupune că serverele DNS publice răspund la zonele private; forțarea tuturor interogărilor către acestea poate rupe DNS-ul divizat sau poate dezvălui nume de gazdă interne. DNS=Intrările globale din resolved.confpot funcționa alături de DNS-ul per link, în loc să îl înlocuiască automat; consultați manualul Bookworm resolved.conf .
5. Goliți memoria cache și confirmați că ambele căi de căutare funcționează
După corectarea serviciului, a legăturii resolver sau a configurației din amonte, ștergeți răspunsurile din cache și testați din nou:
Repararea este eficientă atunci când resolvectl queryadresele de returnare, getent ahostsînregistrările adreselor de returnare și serverele DNS vizate rămân vizibile după reconectarea rețelei. Cele două comenzi testează interfețe diferite, așadar nu considerați succesul uneia ca dovadă că fiecare aplicație este reparată. Manualul Debian resolvectl documentează interogarea, starea și golirea memoriei cache.
Vizualizarea finală a terminalului arată cele două verificări care ar trebui să returneze înregistrări de adresă după repararea configurației DNS.
Dacă resolvectl queryreușește, dar getentîncă eșuează, examinați grep "^hosts:" /etc/nsswitch.confși confirmați că un modul NSS corespunzător dnssau instalat resolvese află în calea de căutare. Dacă ambele eșuări continuă, verificați jurnalul rezolverului și orice restricții ale firewall-ului asupra traficului DNS, apoi testați folosind adresa DNS reală a companiei, a routerului sau a furnizorului. O căutare reușită izolată nu este suficientă: repetați verificările după reconectare și după repornire pentru a verifica remedierea persistentă.