Les noms ne se résolvent pas (DNS)

Le symptôme de cette panne est reconnaissable : ping 1.1.1.1 fonctionne, ping millida.net répond « Temporary failure in name resolution », apt update se bloque puis expire. Le réseau lui-même est intact — seule la conversion des noms en adresses est cassée.

Étape 1. Vérifier que le problème vient bien des noms

ping -c3 1.1.1.1
getent hosts millida.net
dig +short millida.net @1.1.1.1

Si dig avec un serveur explicite répond mais que getent échoue, le système ne sait pas quel résolveur contacter. Il s’agit d’un problème de configuration, pas de connectivité.

Étape 2. Vérifier ce qui gère la résolution

cat /etc/resolv.conf
systemctl status systemd-resolved
resolvectl status

Trois situations sont possibles :

• le fichier est vide ou ne contient aucune ligne nameserver — aucun résolveur n’est défini ;
• le fichier contient nameserver 127.0.0.53, mais systemd-resolved n’est pas démarré — les requêtes ne partent nulle part ;
• un serveur tiers est configuré mais injoignable depuis notre réseau.

Étape 3. Corriger

Récupération rapide pour rétablir apt et curl :

echo 'nameserver 1.1.1.1' > /etc/resolv.conf
echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

Cela fonctionne immédiatement, mais tient jusqu’au redémarrage ou à la prochaine reconfiguration réseau. La correction permanente dépend du système.

Debian et Ubuntu avec systemd-resolved :

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl dns ens18 1.1.1.1 8.8.8.8

AlmaLinux et CentOS Stream :

nmcli con mod "System ens18" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "System ens18"

Ne modifiez pas /etc/resolv.conf à la main s’il s’agit d’un lien symbolique vers /run. Un tel fichier est écrasé par le service, et votre modification disparaîtra au premier redémarrage — vous rencontrerez la même panne une semaine plus tard sans vous souvenir pourquoi.

Étape 4. Cas particuliers

Le résolveur fonctionne, mais un nom précis est introuvable. Vérifiez si l’enregistrement est publié tout court :

dig millida.net A @1.1.1.1
dig millida.net A @8.8.8.8

Des réponses différentes de deux serveurs signifient que la zone a changé récemment et qu’un ancien cache subsiste quelque part. Attendez la durée de vie (TTL) de l’enregistrement indiquée dans la réponse de dig.

L’enregistrement inverse de l’adresse de la machine (PTR) n’a rien à voir avec ce problème : il est nécessaire aux serveurs de messagerie, se configure dans l’onglet « Access » et n’affecte pas la façon dont la machine résout elle-même les noms.

Autre constat fréquent : un /etc/hosts contenant une ligne obsolète laissée après une migration. Le système le consulte avant le DNS et s’obstine à passer par l’ancienne adresse :

cat /etc/hosts

Supprimez les lignes en trop et conservez 127.0.0.1 localhost ainsi que la ligne portant le nom de la machine elle-même.

Si les noms ne se résolvent depuis aucun serveur

Le problème est alors plus large : vérifiez la connectivité de base à l’aide de l’article Perte de réseau sur la machine et assurez-vous que le port 53 sortant n’est pas bloqué par votre propre filtre de paquets.