Remediați eroarea „Eroare temporară la rezolvarea DNS” în Debian 12 cu systemd-resolved

Eroarea Temporary failure in name resolutionînseamnă că o aplicație nu a putut transforma un nume de gazdă, cum ar fi deb.debian.orgo adresă IP. Pe Debian 12 (Bookworm), asta nu înseamnă automat systemd-resolvedcă este defect. Debian 12 nu se instalează systemd-resolvedîn mod implicit, iar DNS poate fi gestionat direct de NetworkManager, ifupdown, instrumente DHCP sau un alt resolver. Dacă ați activat în mod deliberat systemd-resolved, cea mai rapidă soluție este să identificați ce strat defectează înainte de a modifica configurația.

Această referință practică se concentrează pe sistemele care utilizează sau sunt destinate să utilizeze systemd-resolved. Documentația pachetului Bookworm de la Debian menționează instalarea systemd-resolvedswitch-urilor /etc/resolv.confla managementul rezolvat de systemd. Serviciul în sine oferă un stub DNS local 127.0.0.53și acceptă informații DNS în amonte din configurația globală, configurația rețelei per-link, DHCP resolvectlși serviciile de management al rețelei. Consultați pagina pachetului Debian systemd-resolved și manualul Debian systemd-resolved .

Listă de verificare pentru diagnosticare rapidă

1. Confirmați că problema este legată de DNS, nu de conectivitatea generală

Începeți prin a testa un nume de gazdă și apoi o adresă IP:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

Dacă căutarea numelui de gazdă eșuează, în timp ce testul IP direct reușește, DNS este domeniul probabil care a cauzat eroarea. Dacă ambele eșuează, inspectați mai întâi interfața, ruta, gateway-ul, VLAN-ul, asocierea Wi-Fi, firewall-ul sau rețeaua din amonte. O modificare DNS nu poate repara o rută implicită lipsă.

Pentru o verificare a rutării mai deterministă, executați și:

ip address
ip route

În mod normal, ar trebui să aveți o adresă pe interfața așteptată și o rută implicită. Numele exact al interfeței poate fi enp1s0, ens160, eth0, sau altceva.

2. Verificați dacă systemd-resolved este de fapt utilizat

Nu presupuneți că este prezent doar pentru că mașina folosește systemd. Verificați atât pachetul, cât și serviciul:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

Dacă pachetul lipsește și mașina dvs. are un alt design funcțional de gestionare DNS, instalarea systemd-resolvednu este automat soluția corectă. Dacă sistemul trebuie să îl utilizeze și serviciul este instalat, dar oprit, activați-l și porniți-l:

sudo systemctl enable --now systemd-resolved

Dacă acea comandă eșuează, verificați jurnalele înainte de a reporni serviciul în mod repetat:

journalctl -u systemd-resolved -b --no-pager

3. Inspectați fișierul /etc/resolv.conf înainte de a-l înlocui

Cea mai frecventă greșeală de configurare este tratarea fișierului /etc/resolv.confca pe un fișier izolat. Cu systemd-resolved, acesta poate funcționa în mai multe moduri acceptate. Modul stub recomandat de serverele din amonte face legătura /etc/resolv.confcătre /run/systemd/resolve/stub-resolv.conf, care indică clienții DNS tradiționali la 127.0.0.53. Un alt mod valid face legătura către /run/systemd/resolve/resolv.conf, care expune direct serverele din amonte cunoscute, dar pierde rutarea DNS per-link a funcției systemd-resolved pentru aplicațiile care citesc direct fișierul respectiv.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Un fișier obișnuit nu este automat greșit. NetworkManager sau un alt manager de rezolvare îl poate deține intenționat. Totuși, dacă această gazdă este proiectată să utilizeze modul stub rezolvat de systemd, un fișier obișnuit învechit, o legătură simbolică suspendată sau un fișier care indică servere de nume inaccesibile pot cauza erori de căutare.

Restaurați legătura stub recomandată atunci când este intenționat modul stub

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Este de așteptat să fie vizualizat nameserver 127.0.0.53în fișierul stub. Este vorba de listener-ul local, nu de serverul DNS din amonte. Folosește-l resolvectl statuspentru a vedea ce servere din amonte va contacta de fapt serverul systemd-resolved. Această distincție este documentată în manualul Bookworm pentru systemd-resolved .

4. Verificați dacă systemd-resolved are un server DNS utilizabil în amonte

Aleargă:

resolvectl status

Concentrați-vă pe legătura care transportă ruta implicită. O configurație sănătoasă ar trebui să afișeze în mod normal unul sau mai multe servere DNS pentru acea legătură sau servere DNS globale adecvate. Dacă nu este prezent niciun server DNS utilizabil, remedierea legăturii simbolice nu va ajuta: stub-ul local nu are nicăieri util pentru a trimite interogări.

Puteți testa direct rezolverul:

resolvectl query debian.org

Manualul Debian resolvectl documentează status, query, flush-caches, și comenzile DNS per legătură utilizate pentru inspecție și depanare.

5. Dacă NetworkManager deține interfața, remediați DNS-ul în profilul de conexiune

Pe instalările desktop și pe multe sisteme Debian de uz general, NetworkManager poate furniza informații DNS per link către systemd-resolved. Mai întâi identificați profilul activ și valorile DNS curente:

nmcli connection show --active
nmcli device show

Dacă DHCP furnizează un server DNS greșit, modificați profilul NetworkManager în loc să îl editați /etc/resolv.confdupă fiecare repornire. De exemplu, dacă politica de rețea permite rezolveri publici:

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

Înlocuiți numele profilului și serverele DNS cu valori corespunzătoare rețelei dvs. Rețelele corporative, VPN-urile, mediile Active Directory și configurațiile split-DNS necesită adesea rezolveri interni; DNS-ul public poate încălca numele de gazdă private. Referința oficială de configurare a NetworkManager documentează integrarea sa cu systemd-resolved.

6. Dacă systemd-networkd deține interfața, configurați DNS per link

Pentru serverele care utilizează systemd-networkd, plasați setările DNS în .networkfișierul corespunzător de sub /etc/systemd/network/. Un exemplu simplu bazat pe DHCP este:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=nocontează atunci când doriți să ignorați în mod specific serverele DNS furnizate de DHCP. Fără acesta, DNS-ul DHCP este utilizat în mod implicit. Domains=~.este un domeniu exclusiv de rutare pentru rădăcina DNS, ceea ce face ca această legătură să fie potrivită pentru interogări care nu corespund unui domeniu de rutare mai specific. Nu o adăugați orbește pe sisteme multi-homed sau VPN unde DNS-ul divizat este intenționat.

sudo systemctl restart systemd-networkd
resolvectl status ens160

Comportamentul DNS=, Domains=, și DHCP UseDNS=este documentat în manualul Debian Bookworm systemd.network .

7. Folosește fișierul global resolved.conf doar atunci când vrei cu adevărat DNS la nivel de sistem

/etc/systemd/resolved.confsau o opțiune drop-in sub /etc/systemd/resolved.conf.d/poate defini serverele DNS ale sistemului. Acest lucru este util pentru o politică la nivel de gazdă, dar este mai puțin precis decât configurația per link pe mașinile cu VPN-uri, interfețe multiple sau zone DNS private.

O editare locală este de obicei mai curată decât editarea fișierului principal în stil furnizor:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

Exemplu:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Apoi aplică-l:

sudo systemctl restart systemd-resolved
resolvectl status

Manualul Debian resolved.conf explică faptul că DNS=serverele DNS ale sistemului de alimentare și că accesul administrator direct /etc/systemd/resolved.conf.d/au prioritate față de configurația cu prioritate mai mică.

8. Goliți memoria cache numai după remedierea configurației subiacente

O memorie cache învechită poate crea confuzie în depanare, dar golirea memoriei cache nu înlocuiește repararea unui server upstream inaccesibil sau a unei configurații de link defecte. După ce efectuați o modificare reală a configurației, puteți rula:

sudo resolvectl flush-caches
resolvectl query debian.org

Documentația proprie a Systemd menționează că memoria cache este în mod normal golită automat atunci când configurația rețelei se modifică, așa că golirea manuală repetată nu ar trebui să fie soluția principală.

9. Citiți jurnalul rezolverului atunci când eroarea persistă

Dacă resolvectl statuspare rezonabil, dar interogările tot expiră, verificați jurnalul rezolverului local de bootare:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

Căutați expirari repetate ale serverului, modificări ale serverului de rezervă, erori de validare DNSSEC sau mesaje care indică funcții de protocol reduse. Un resolver poate rula normal în timp ce serverul său configurat în amonte este inaccesibil printr-un firewall, VPN, politică de rutare sau ACL de rețea.

10. Verificați calea completă de căutare

Nu opriți după o resolvectlinterogare reușită. Verificați calea utilizată de aplicațiile normale:

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getenteste util deoarece căutările numelor de gazdă glibc urmează hosts:linia din /etc/nsswitch.conf. Dacă resolvectl queryreușește, dar getenteșuează, inspectați configurația NSS. Manualul nss-resolve al Debian descrie modulul opțional libnss-resolveși o ordine recomandată care poate direcționa căutările numelor de gazdă glibc prin systemd-resolved, păstrând în același timp opțiunile de rezervă.

Simptome frecvente și cel mai probabil loc de căutare

Comandă de reparații recomandată

1. Confirmați că există conectivitate de rețea de bază și ruta implicită.
2. Confirmați dacă systemd-resolvedeste într-adevăr destinat gestionării DNS-ului pe această gazdă.
3. Verificați systemd-resolvedstarea serviciului și resolvectl status.
4. Verificați /etc/resolv.confproprietatea și modul de legătură simbolică înainte de a le schimba.
5. Dacă se intenționează utilizarea modului stub, restaurați stub-resolv.conflegătura.
6. Remediați DNS-ul upstream la proprietarul real: NetworkManager, systemd-networkd, DHCP, VPN sau configurație rezolvată global.
7. Goliți memoria cache numai după ce configurația este corectată.
8. Verificați cu resolvectl, getent, și aplicația care a eșuat inițial.

Principiul cheie este proprietatea: /etc/resolv.conf, rezolvat de systemd și managerul de rețea sunt părți ale unui singur lanț de resolvere. O soluție durabilă modifică DNS-ul la nivelul care o deține, în loc să înlocuiască în mod repetat fișierul generat final.