Résolution de l'erreur « Échec temporaire de la résolution DNS » sous Debian 12 avec systemd-resolved

Cette erreur Temporary failure in name resolutionsignifie qu'une application n'a pas pu convertir un nom d'hôte deb.debian.orgen adresse IP. Sous Debian 12 (Bookworm), cela ne signifie pas automatiquement que le service DNS systemd-resolvedest défaillant. Debian 12 n'installe pas systemd-resolvedle DNS par défaut ; celui-ci peut être géré directement par NetworkManager, ifupdown, les outils DHCP ou un autre résolveur. Si vous avez activé le DNS de manière proactive systemd-resolved, la solution la plus rapide consiste à identifier la couche défaillante avant de modifier la configuration.

Ce guide pratique s'adresse aux systèmes qui utilisent, ou sont conçus pour utiliser, systemd-resolved systemd-resolved. La documentation du paquet Bookworm de Debian indique que son installation systemd-resolvedpermet de basculer /etc/resolv.confvers la gestion de la résolution DNS par systemd. Ce service fournit un stub DNS local 127.0.0.53et accepte les informations DNS en amont provenant de la configuration globale, de la configuration réseau par liaison, du DHCP resolvectlet des services de gestion de réseau. Consultez la page du paquet systemd-resolved de Debian et le manuel de systemd-resolved pour Debian .

Liste de contrôle pour un diagnostic rapide

1. Vérifiez que le problème provient bien du DNS et non d'un problème de connectivité générale.

Commencez par tester un nom d'hôte, puis une adresse IP :

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

Si la résolution du nom d'hôte échoue alors que le test d'adresse IP directe réussit, le DNS est probablement en cause. Si les deux échouent, vérifiez d'abord l'interface, la route, la passerelle, le VLAN, l'association Wi-Fi, le pare-feu ou le réseau en amont. Une modification du DNS ne peut pas résoudre le problème d'une route par défaut manquante.

Pour une vérification de routage plus déterministe, exécutez également :

ip address
ip route

Vous devriez normalement disposer d'une adresse sur l'interface attendue et d'une route par défaut. Le nom exact de l'interface peut être enp1s0, ens160, eth0, ou autre.

2. Vérifiez si systemd-resolved est effectivement utilisé.

Ne présumez pas de sa présence simplement parce que la machine utilise systemd. Vérifiez à la fois le paquet et le service :

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

Si le paquet est absent et que votre machine dispose d'une autre configuration DNS fonctionnelle, son installation systemd-resolvedne résout pas automatiquement le problème. Si le système est censé l'utiliser et que le service est installé mais arrêté, activez-le et démarrez-le :

sudo systemctl enable --now systemd-resolved

Si cette commande échoue, consultez les journaux avant de redémarrer le service à plusieurs reprises :

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

3. Vérifiez le fichier /etc/resolv.conf avant de le remplacer.

L'erreur de configuration la plus fréquente consiste à considérer /etc/resolv.confle fichier comme isolé. Avec systemd-resolved`systemd.config.py`, il peut fonctionner dans plusieurs modes pris en charge. Le mode stub recommandé par le serveur DNS en amont pointe /etc/resolv.confvers `systemd.config.py` /run/systemd/resolve/stub-resolv.conf, qui redirige les clients DNS traditionnels vers ` systemd.config.py` 127.0.0.53. Un autre mode valide pointe vers ` /run/systemd/resolve/resolv.confsystemd.config.py`, exposant directement les serveurs DNS en amont connus, mais désactive le routage DNS par lien de systemd-resolved pour les applications qui lisent directement ce fichier.

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

Un fichier ordinaire n'est pas forcément erroné. NetworkManager ou un autre gestionnaire de résolution peut en être intentionnellement propriétaire. Cependant, si cet hôte est configuré pour utiliser le mode stub de résolution systemd, un fichier ordinaire obsolète, un lien symbolique orphelin ou un fichier pointant vers des serveurs de noms inaccessibles peut entraîner des échecs de résolution.

Rétablissez le lien de stub recommandé lorsque le mode stub est prévu.

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

La présence nameserver 127.0.0.53de ce fichier dans le stub est normale. Il s'agit du serveur DNS local, et non du serveur DNS en amont. Utilisez la commande resolvectl status`systemd-resolved` pour savoir quels serveurs en amont systemd-resolved contactera réellement. Cette distinction est documentée dans le manuel Bookworm de systemd-resolved .

4. Vérifiez si systemd-resolved dispose d'un serveur DNS en amont utilisable.

Courir:

resolvectl status

Concentrez-vous sur le lien qui transporte la route par défaut. Une configuration correcte devrait normalement afficher un ou plusieurs serveurs DNS pour ce lien, ou des serveurs DNS globaux appropriés. Si aucun serveur DNS utilisable n'est présent, la correction du lien symbolique seul ne résoudra pas le problème : le stub local ne dispose d'aucun serveur DNS utile pour envoyer les requêtes.

Vous pouvez tester directement le résolveur :

resolvectl query debian.org

Le manuel de resolvectl de Debian documente status, query, flush-caches, et les commandes DNS par lien utilisées pour l'inspection et le dépannage.

5. Si NetworkManager est propriétaire de l'interface, corrigez le DNS dans le profil de connexion.

Sur les installations de bureau et de nombreux systèmes Debian à usage général, NetworkManager peut fournir des informations DNS par lien à systemd-resolved. Commencez par identifier le profil actif et les valeurs DNS actuelles :

nmcli connection show --active
nmcli device show

Si le serveur DHCP attribue un serveur DNS incorrect, modifiez le profil NetworkManager plutôt que de le faire /etc/resolv.confaprès chaque redémarrage. Par exemple, si votre politique réseau autorise les résolveurs publics :

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"

Remplacez le nom du profil et les serveurs DNS par des valeurs adaptées à votre réseau. Les réseaux d'entreprise, les VPN, les environnements Active Directory et les configurations DNS partagées nécessitent souvent des résolveurs internes ; un DNS public peut rendre incompatibles les noms d'hôtes privés. La documentation de référence officielle de NetworkManager décrit son intégration avec [nom du service/outil manquant systemd-resolved].

6. Si systemd-networkd gère l'interface, configurez le DNS par lien.

Pour les serveurs utilisant systemd-networkd, placez les paramètres DNS dans le .networkfichier correspondant sous /etc/systemd/network/. Voici un exemple simple basé sur DHCP :

[Match]
Name=ens160

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

[DHCPv4]
UseDNS=no

UseDNS=noCela a son importance lorsque vous souhaitez ignorer les serveurs DNS fournis par DHCP. Sans cela, le DNS DHCP est utilisé par défaut. Domains=~.est un domaine de routage uniquement pour la racine DNS, ce qui rend ce lien adapté aux requêtes ne correspondant pas à un domaine de routage plus spécifique. Ne l'ajoutez pas aveuglément sur les systèmes multihébergés ou VPN où le DNS fractionné est intentionnel.

sudo systemctl restart systemd-networkd
resolvectl status ens160

Le comportement de DNS=, Domains=, et DHCP UseDNS=est documenté dans le manuel systemd.network de Debian Bookworm .

7. N’utilisez le fichier resolved.conf global que si vous souhaitez réellement une configuration DNS à l’échelle du système.

/etc/systemd/resolved.confIl est également possible de définir les serveurs DNS système via une configuration spécifique /etc/systemd/resolved.conf.d/. Cette méthode est utile pour une politique globale, mais elle est moins précise qu'une configuration par liaison sur les machines disposant de VPN, de plusieurs interfaces ou de zones DNS privées.

Un fichier local est généralement plus propre que la modification du fichier principal fourni par le fournisseur :

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

Exemple:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Appliquez-le ensuite :

sudo systemctl restart systemd-resolved
resolvectl status

Le manuel de Debian resolved.conf explique que DNS=ce fichier fournit les serveurs DNS système et que les configurations d'administrateur /etc/systemd/resolved.conf.d/ont priorité sur les configurations de moindre priorité.

8. Videz les caches uniquement après avoir corrigé la configuration sous-jacente.

Un cache obsolète peut compliquer le dépannage, mais vider le cache ne remplace pas la réparation d'un serveur en amont inaccessible ou d'une configuration de lien défaillante. Après avoir effectué une modification de configuration réelle, vous pouvez exécuter :

sudo resolvectl flush-caches
resolvectl query debian.org

La documentation de Systemd indique que les caches sont normalement vidés automatiquement lorsque la configuration réseau change ; par conséquent, le vidage manuel répété ne devrait pas constituer votre solution principale.

9. Consultez le journal du résolveur si l'erreur persiste.

Si resolvectl statuscela semble raisonnable mais que les requêtes expirent toujours, consultez le journal du résolveur local au démarrage :

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

Surveillez les délais d'attente du serveur à répétition, les changements de serveur de secours, les échecs de validation DNSSEC ou les messages indiquant une réduction des fonctionnalités du protocole. Un résolveur peut fonctionner normalement alors que son serveur amont configuré est inaccessible via un pare-feu, un VPN, une politique de routage ou une liste de contrôle d'accès réseau.

10. Vérifiez le chemin de recherche complet

Ne vous arrêtez pas après une seule resolvectlrequête réussie. Vérifiez le chemin d'accès utilisé par les applications courantes :

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

getentCette commande est utile car les recherches de noms d'hôtes glibc suivent la hosts:ligne correspondante /etc/nsswitch.conf. Si resolvectl queryla première commande réussit mais getentque la seconde échoue, examinez la configuration NSS. Le manuel de nss-resolve de Debian décrit le module optionnel libnss-resolveet un ordre recommandé permettant d'acheminer les recherches de noms d'hôtes glibc via systemd-resolved tout en conservant des solutions de repli.

Symptômes courants et endroits les plus susceptibles de nécessiter une recherche

Ordre de réparation recommandé

1. Vérifiez que la connectivité réseau de base et la route par défaut existent.
2. Vérifiez si ce processus systemd-resolvedest effectivement destiné à gérer le DNS sur cet hôte.
3. Vérifier systemd-resolvedl'état du service et resolvectl status.
4. Vérifiez /etc/resolv.confle propriétaire et le mode du lien symbolique avant de le modifier.
5. Si le mode stub est souhaité, rétablissez la stub-resolv.confliaison.
6. Corrigez le DNS en amont au niveau du propriétaire réel : NetworkManager, systemd-networkd, DHCP, VPN ou configuration de résolution globale.
7. Ne videz le cache qu'une fois la configuration corrigée.
8. Vérifiez avec resolvectl, getent, et l'application qui a initialement échoué.

Le principe fondamental est celui de la propriété : /etc/resolv.confsystemd-resolved et le gestionnaire de réseau font partie d’une même chaîne de résolution. Une solution durable modifie le DNS au niveau de la couche qui en est propriétaire, au lieu de remplacer systématiquement le fichier final généré.