Los het probleem "Tijdelijke fout bij het oplossen van DNS" op in Debian 12 met systemd-resolved.

De foutmelding Temporary failure in name resolutionbetekent dat een applicatie een hostnaam, zoals , niet kon omzetten deb.debian.orgnaar een IP-adres. Op Debian 12 (Bookworm) betekent dit niet automatisch systemd-resolveddat defect is. Debian 12 installeert niet systemd-resolvedstandaard en DNS kan in plaats daarvan rechtstreeks worden beheerd door NetworkManager, ifupdown, DHCP-tools of een andere resolver. Als u bewust hebt ingeschakeld systemd-resolved, is de snelste oplossing om te achterhalen welke laag faalt voordat u de configuratie wijzigt.

Deze praktische handleiding richt zich op systemen die gebruikmaken van, of bedoeld zijn om te gebruiken systemd-resolved. De documentatie van het Debian Bookworm-pakket beschrijft hoe de installatie systemd-resolvedoverschakelt /etc/resolv.confnaar beheer via systemd-resolved. De service zelf biedt een lokale DNS-stub op 127.0.0.53en accepteert upstream DNS-informatie van globale configuratie, netwerkconfiguratie per link, DHCP resolvectlen netwerkbeheerservices. Zie de Debian systemd-resolved pakketpagina en de Debian systemd-resolved handleiding .

Checklist voor snelle diagnose

1. Controleer of het probleem bij DNS ligt en niet bij de algemene connectiviteit.

Begin met het testen van een hostnaam en vervolgens een IP-adres:

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

Als de hostnaamcontrole mislukt terwijl de directe IP-test wel slaagt, ligt de fout waarschijnlijk bij DNS. Als beide controles mislukken, controleer dan eerst de interface, route, gateway, VLAN, wifi-verbinding, firewall of het upstream-netwerk. Een DNS-wijziging kan een ontbrekende standaardroute niet herstellen.

Voor een meer deterministische routecontrole kunt u ook het volgende uitvoeren:

ip address
ip route

Normaal gesproken zou je een IP-adres op de verwachte interface en een standaardroute moeten hebben. De exacte interfacenaam kan bijvoorbeeld enp1s0, ens160, eth0of iets anders zijn.

2. Controleer of systemd-resolved daadwerkelijk in gebruik is.

Ga er niet zomaar vanuit dat het aanwezig is omdat de machine systemd gebruikt. Controleer zowel het pakket als de service:

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

Als het pakket ontbreekt en uw computer een andere, werkende DNS-beheeroplossing heeft, systemd-resolvedis installeren niet automatisch de juiste oplossing. Als het systeem het pakket zou moeten gebruiken en de service wel is geïnstalleerd maar gestopt, schakel deze dan in en start deze.

sudo systemctl enable --now systemd-resolved

Als die opdracht mislukt, controleer dan de logbestanden voordat u de service herhaaldelijk opnieuw start:

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

3. Controleer /etc/resolv.conf voordat u het vervangt.

De meest voorkomende configuratiefout is het behandelen /etc/resolv.confvan als een geïsoleerd bestand. Met systemd-resolvedkan het in verschillende ondersteunde modi werken. De door upstream aanbevolen stub-modus linkt /etc/resolv.confnaar /run/systemd/resolve/stub-resolv.conf, die traditionele DNS-clients naar verwijst 127.0.0.53. Een andere geldige modus linkt naar /run/systemd/resolve/resolv.conf, die bekende upstream-servers direct beschikbaar stelt, maar de per-link DNS-routering van systemd-resolved verliest voor applicaties die dat bestand direct lezen.

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

Een regulier bestand is niet per definitie onjuist. NetworkManager of een andere resolvermanager kan het opzettelijk als eigenaar beheren. Als deze host echter is ontworpen om de systemd-resolved stub-modus te gebruiken, kan een verouderd regulier bestand, een ongeldige symbolische link of een bestand dat verwijst naar onbereikbare nameservers zoekfouten veroorzaken.

Herstel de aanbevolen stub-link wanneer de stub-modus is bedoeld.

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

Het is te verwachten dat je dit in het stub-bestand ziet nameserver 127.0.0.53. Het is de lokale listener, niet de upstream DNS-server. Gebruik dit resolvectl statusom te zien welke upstream-servers systemd-resolved daadwerkelijk zal benaderen. Dit onderscheid wordt beschreven in de Bookworm-handleiding van systemd-resolved .

4. Controleer of systemd-resolved een bruikbare upstream DNS-server heeft.

Loop:

resolvectl status

Focus op de link die de standaardroute bevat. Een goed functionerende configuratie zou normaal gesproken één of meer DNS-servers voor die link of geschikte globale DNS-servers moeten tonen. Als er geen bruikbare DNS-server aanwezig is, zal het repareren van de symbolische link alleen niet helpen: de lokale stub heeft geen nuttige bestemming voor query's.

Je kunt de resolver direct testen:

resolvectl query debian.org

De Debian resolvectl-handleiding beschrijft de statusDNS -opdrachten per link die worden gebruikt voor inspectie en probleemoplossing.queryflush-caches

5. Als NetworkManager de eigenaar is van de interface, corrigeer dan de DNS in het verbindingsprofiel.

Op desktopinstallaties en veel algemene Debian-systemen kan NetworkManager per link DNS-informatie aan systemd-resolved verstrekken. Identificeer eerst het actieve profiel en de huidige DNS-waarden:

nmcli connection show --active
nmcli device show

Als DHCP een onjuiste DNS-server levert, wijzig dan het NetworkManager-profiel in plaats van het /etc/resolv.confna elke herstart te bewerken. Als uw netwerkbeleid bijvoorbeeld openbare resolvers toestaat:

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"

Vervang de profielnaam en DNS-servers door waarden die geschikt zijn voor uw netwerk. Bedrijfsnetwerken, VPN's, Active Directory-omgevingen en split-DNS-configuraties vereisen vaak interne resolvers; openbare DNS kan problemen veroorzaken met privéhostnamen. De officiële configuratiehandleiding van NetworkManager beschrijft de integratie met systemd-resolved.

6. Als systemd-networkd de interface beheert, configureer dan DNS per link.

Voor servers die gebruikmaken van DHCP systemd-networkd, plaatst u de DNS-instellingen in het bijbehorende .networkbestand onder /etc/systemd/network/. Een eenvoudig DHCP-gebaseerd voorbeeld is:

[Match]
Name=ens160

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

[DHCPv4]
UseDNS=no

UseDNS=noDit is van belang wanneer u specifiek DNS-servers wilt negeren die door DHCP worden geleverd. Zonder deze instelling wordt standaard DHCP DNS gebruikt. Domains=~.is een domein dat alleen voor routering wordt gebruikt voor de DNS-root, waardoor die link geschikt is voor query's die niet overeenkomen met een specifiekere routeringsdomein. Voeg dit niet blindelings toe op systemen met meerdere netwerkinterfaces of VPN-systemen waar split DNS opzettelijk is.

sudo systemctl restart systemd-networkd
resolvectl status ens160

Het gedrag van DNS=, Domains=, en DHCP UseDNS=is gedocumenteerd in de Debian Bookworm systemd.network handleiding .

7. Gebruik global resolved.conf alleen als je echt systeemwijde DNS wilt.

/etc/systemd/resolved.confOf een drop-in onder /etc/systemd/resolved.conf.d/kan de systeem-DNS-servers definiëren. Dit is handig voor een hostbreed beleid, maar het is minder nauwkeurig dan configuratie per link op machines met VPN's, meerdere interfaces of privé-DNS-zones.

Een lokale drop-in is meestal een schonere oplossing dan het bewerken van het hoofdbestand in de standaardinstellingen van de leverancier:

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

Voorbeeld:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Pas het vervolgens toe:

sudo systemctl restart systemd-resolved
resolvectl status

De Debian resolved.conf-handleiding legt uit dat DNS=dit de DNS-servers van het systeem definieert en dat de door de beheerder ingestelde instellingen /etc/systemd/resolved.conf.d/voorrang hebben op configuraties met een lagere prioriteit.

8. Leeg de caches pas nadat de onderliggende configuratie is gecorrigeerd.

Een verouderde cache kan het oplossen van problemen bemoeilijken, maar het legen van de cache is geen vervanging voor het herstellen van een onbereikbare upstream-server of een verbroken linkconfiguratie. Nadat u een daadwerkelijke configuratiewijziging hebt aangebracht, kunt u het volgende uitvoeren:

sudo resolvectl flush-caches
resolvectl query debian.org

In de documentatie van Systemd zelf staat dat caches normaal gesproken automatisch worden geleegd wanneer de netwerkconfiguratie verandert. Herhaaldelijk handmatig legen zou daarom niet de belangrijkste oplossing moeten zijn.

9. Lees het resolver-logboek als de fout aanhoudt.

Als resolvectl statushet redelijk lijkt, maar de query's nog steeds een time-out geven, controleer dan het logbestand van de boot-local resolver:

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

Let op herhaalde servertime-outs, wijzigingen in de fallback-server, DNSSEC-validatiefouten of berichten die wijzen op beperkte protocolfunctionaliteit. Een resolver kan normaal functioneren, terwijl de geconfigureerde upstream-server onbereikbaar is via een firewall, VPN, routeringsbeleid of netwerk-ACL.

10. Controleer het volledige opzoekpad

Stop niet na één succesvolle resolvectlquery. Controleer het pad dat door normale applicaties wordt gebruikt:

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

getentDit is handig omdat glibc-hostnaamzoekacties de hosts:regel in volgen /etc/nsswitch.conf. Als resolvectl queryhet lukt maar getentmislukt, controleer dan die NSS-configuratie. De handleiding van Debian's nss-resolve beschrijft de optionele libnss-resolvemodule en een aanbevolen volgorde waarmee glibc-hostnaamzoekacties via systemd-resolved kunnen worden gerouteerd, terwijl fallback-opties behouden blijven.

Veelvoorkomende symptomen en de meest waarschijnlijke plek om te zoeken

Aanbevolen reparatievolgorde

1. Controleer of de basisnetwerkverbinding en de standaardroute aanwezig zijn.
2. Controleer of systemd-resolvedhet daadwerkelijk de bedoeling is om DNS op deze host te beheren.
3. Controleer systemd-resolvedde servicestatus en resolvectl status.
4. Controleer /etc/resolv.confhet eigenaarschap en de symlink-modus voordat u deze wijzigt.
5. Als de stub-modus bedoeld is, herstel dan de stub-resolv.conflink.
6. Corrigeer de upstream DNS-instellingen bij de daadwerkelijke eigenaar: NetworkManager, systemd-networkd, DHCP, VPN of de globaal opgeloste configuratie.
7. Leeg de cache pas nadat de configuratie is gecorrigeerd.
8. Controleer met resolvectl, getent, en de applicatie die oorspronkelijk de fout veroorzaakte.

Het kernprincipe is eigenaarschap: /etc/resolv.confsystemd-resolved en de netwerkmanager maken deel uit van één resolverketen. Een duurzame oplossing wijzigt DNS op het niveau dat er eigenaar van is, in plaats van het uiteindelijke gegenereerde bestand herhaaldelijk te vervangen.