Il est 02:17, votre fenêtre de déploiement se referme, et apt refuse soudainement de récupérer quoi que ce soit. L’erreur est presque insultante par sa simplicité : Could not resolve host. Vous savez que la machine a un lien. Vous pouvez faire un ping vers une IP. Pourtant chaque nom d’hôte semble avoir été effacé de l’univers.
C’est là que les instincts orientés production comptent. Ne « testez pas des correctifs au hasard » et surtout ne redémarrez pas comme outil de diagnostic. Traitez la résolution de noms comme un incident de stockage : trouvez la frontière, prouvez où ça casse, et changez une chose à la fois.
Playbook de diagnostic rapide
Ceci est la voie « arrêter l’hémorragie ». Elle privilégie la vitesse, pas l’élégance. Vous essayez de répondre rapidement à trois questions :
- Est-ce que cette machine peut atteindre un résolveur du tout ?
- Le résolveur répond-il correctement ?
- L’application contourne-t-elle votre résolveur à cause d’un proxy, d’IPv6 ou d’oddities NSS ?
Première étape : prouver si le DNS est le problème ou juste le premier qui tombe
- Vérifiez la connectivité IP vers quelque chose de stable (passerelle, résolveur, IP publique connue si la politique le permet). Si la connectivité IP échoue, le débogage DNS est de la comédie.
- Résolvez en utilisant le chemin système (
getent) et un outil direct (digouresolvectl). S’ils sont en désaccord, vous avez trouvé la ligne de fracture.
Deuxième étape : localiser le résolveur en cours et son amont
- Lisez /etc/resolv.conf et vérifiez s’il s’agit d’un stub (127.0.0.53) ou de serveurs réels.
- Utilisez resolvectl pour voir quels serveurs DNS sont effectivement configurés par lien et si DNSSEC/DoT sont impliqués.
Troisième étape : vérifiez le routage « invisible » des applications : proxy et préférence IPv6
- Proxy : validez les variables d’environnement et les extraits de proxy APT. Un proxy peut faire paraître le DNS cassé parce que le proxy réalise la résolution (ou échoue à la réaliser).
- IPv6 : si votre hôte obtient des enregistrements AAAA mais ne sait pas router l’IPv6, vous verrez des temporisations et des échecs du type « could not resolve host » selon le client.
Si vous êtes pressé : commencez par les Tâches 1–6 ci‑dessous. Elles indiqueront généralement où creuser.
Ce que signifie vraiment « Could not resolve host »
La phrase apparaît dans plusieurs clients (curl, wget, git, parfois apt via sa pile HTTP). Ce n’est pas une unique erreur. C’est une famille d’échecs qui se terminent tous par le même haussement d’épaules : « J’ai essayé de transformer un nom en adresse, et je n’en ai pas reçu une. »
Dans Debian 13, les composants habituels sont :
- la résolution de noms glibc (NSS) via
/etc/nsswitch.conf - /etc/resolv.conf (soit un fichier réel soit un lien symbolique dans l’univers de systemd)
- systemd-resolved (si activé) et son écouteur stub
- NetworkManager ou systemd-networkd fournissant les serveurs DNS à resolved
- clients VPN faisant du split-DNS, parfois mal configuré
- configuration de proxy (variables d’environnement, config APT, fichiers PAC d’entreprise)
- préférence et politique IPv6 (Happy Eyeballs aide, mais n’annule pas un v6 cassé)
Un mantra fiable : « Could not resolve host » est le symptôme. Votre travail est d’identifier quelle couche ment. »
Blague #1 : le DNS est le seul système distribué où oublier un point peut ruiner votre journée et votre weekend.
Faits intéressants et contexte historique
Ce ne sont pas des anecdotes pour le plaisir. Chacun explique pourquoi la résolution de noms moderne sous Linux se comporte comme elle le fait, et pourquoi des « correctifs » simples peuvent être des pièges.
/etc/hostsprécède DNS. Les premiers systèmes ARPANET utilisaient un fichier HOSTS.TXT central distribué ; DNS a remplacé cette impasse de scalabilité par délégation.- La bibliothèque résolveuse n’est pas la même chose que « DNS ». Sur Linux, NSS de glibc décide s’il faut consulter files, DNS, mDNS, LDAP, SSSD, etc. DNS n’est qu’un module.
resolv.confa été conçu pour des réseaux statiques. Les portables, DHCP, le split DNS des VPN et les conteneurs ont fait de ce fichier un terrain de lutte où plusieurs démons se battent — poliment ou non.- systemd-resolved a introduit un stub local par défaut dans beaucoup de distributions. Cette entrée 127.0.0.53 n’est pas « incorrecte » ; c’est un forwarder local et un cache—jusqu’à ce que quelque chose d’autre casse autour.
- Le cache négatif existe. Les résolveurs peuvent mettre en cache les résultats « NXDOMAIN », donc une défaillance amont transitoire peut persister comme « cet hôte n’existe pas » pendant un moment.
- Les temporisations DNS peuvent ressembler à des échecs de résolution. Beaucoup de clients traduisent « temporisation en contactant le DNS » en erreurs génériques car ils ne se soucient que de ne pas avoir reçu d’adresse.
- DNSSEC et DoT sont des compromis de fiabilité. La validation et le chiffrement ajoutent des modes d’échec : dérive d’horloge, port 853 bloqué, ou des middleboxes qui gèrent mal EDNS0.
- IPv6 a cassé beaucoup d’hypothèses. Le dual-stack signifie que vous pouvez « résoudre avec succès » des AAAA mais échouer à vous connecter si le routage v6 est à moitié configuré.
- Les proxies d’entreprise résolvent parfois les noms pour vous. Votre client peut ne jamais faire de DNS ; il passe le nom d’hôte au proxy et attend. Ça change la voie de débogage.
L’arbre de décision : DNS vs proxy vs IPv6 vs routage
Voici le modèle mental qui vous évite d’éditer des fichiers au hasard. Votre objectif est de trouver la première couche qui dévie du comportement attendu.
1) Pouvez-vous atteindre quoi que ce soit par IP ?
Si vous ne pouvez pas pinguer votre passerelle par défaut ou atteindre une IP connue, arrêtez. Réparez le lien/routage/pare-feu. Le DNS n’est pas l’incident primaire, c’est du collatéral.
2) Le chemin résolveur système fonctionne-t-il ?
Utilisez getent ahosts car il exerce le même chemin que la plupart des applications (NSS). Si getent échoue, vous avez un problème résolveur système. Si getent fonctionne mais que curl échoue, vous regardez les paramètres proxy, les surcharges DNS au niveau application, ou le comportement de connexion IPv6.
3) Utilisez-vous systemd-resolved, et /etc/resolv.conf est-il honnête ?
Dans beaucoup de pannes, /etc/resolv.conf pointe vers un stub qui n’écoute pas (resolved est désactivé), ou vers des résolveurs fournis par DHCP et périmés que vous ne pouvez pas joindre (le VPN vous a déplacé). C’est ennuyeux, et courant.
4) Êtes-vous dans un régime de proxy ?
Les réseaux d’entreprise adorent les proxies. Certains utilisent des proxies explicites configurés via des variables d’environnement ; d’autres imposent des proxies transparents ou des PAC. Si APT a un proxy configuré mais que le proxy est injoignable, vous pouvez obtenir des erreurs trompeuses qui ressemblent à du DNS.
5) L’IPv6 crée-t-il une boucle « résolution réussie, connexion échouée » ?
Beaucoup d’outils résolvent AAAA et essaient IPv6 en premier. Si le DNS IPv6 marche mais que le routage IPv6 est cassé, vous verrez des échecs lents. Certains clients résument cela comme un échec de résolution. Votre travail est de séparer « j’ai obtenu une adresse » de « je peux atteindre l’adresse ».
Tâches pratiques : commandes, sorties et décisions
Ce sont des tâches réelles que vous pouvez exécuter sur Debian 13. Chacune inclut (a) la commande, (b) ce que signifie une sortie typique, et (c) la décision suivante. Exécutez-les dans l’ordre jusqu’à ce que vous atteigniez la divergence.
Task 1: Confirm the error surface (which tool, which hostname)
cr0x@server:~$ apt-get update
Ign:1 http://deb.debian.org/debian trixie InRelease
Err:1 http://deb.debian.org/debian trixie InRelease
Could not resolve 'deb.debian.org'
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease Could not resolve 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
Ce que ça signifie : APT ne peut pas résoudre le nom du dépôt. Ça peut être du DNS, une configuration de proxy, ou un décalage de résolveur.
Décision : N’éditez rien pour l’instant. Passez aux vérifications de connectivité IP et du résolveur système.
Task 2: Verify interface state and default route
cr0x@server:~$ ip -br addr
lo UNKNOWN 127.0.0.1/8 ::1/128
ens3 UP 10.10.20.15/24 2001:db8:20::15/64
cr0x@server:~$ ip route
default via 10.10.20.1 dev ens3
10.10.20.0/24 dev ens3 proto kernel scope link src 10.10.20.15
Ce que ça signifie : Vous avez une adresse IPv4 et une route par défaut. Sur le papier, la sortie devrait fonctionner.
Décision : Testez la reachabilité vers la passerelle puis vers une IP connue.
Task 3: Test raw IP connectivity (gateway, then a known IP)
cr0x@server:~$ ping -c 2 10.10.20.1
PING 10.10.20.1 (10.10.20.1) 56(84) bytes of data.
64 bytes from 10.10.20.1: icmp_seq=1 ttl=64 time=0.358 ms
64 bytes from 10.10.20.1: icmp_seq=2 ttl=64 time=0.311 ms
--- 10.10.20.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1020ms
rtt min/avg/max/mdev = 0.311/0.334/0.358/0.023 ms
cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=8.29 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=8.10 ms
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.100/8.195/8.290/0.095 ms
Ce que ça signifie : Le chemin réseau vers l’internet par IP fonctionne. Cela pointe fortement vers la résolution de noms ou le proxy.
Décision : Vérifiez le comportement du résolveur système avec getent ensuite.
Task 4: Test resolution through NSS (what most apps actually use)
cr0x@server:~$ getent ahosts deb.debian.org
Que signifie une sortie vide : NSS n’a pas pu produire d’enregistrements d’adresses. C’est un problème résolveur système, pas « APT bizarre ».
Décision : Inspectez /etc/nsswitch.conf et la configuration du résolveur (/etc/resolv.conf, resolvectl).
Task 5: Inspect NSS order (hosts resolution sources)
cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
Ce que ça signifie : Le système vérifie /etc/hosts, puis mDNS, puis DNS. C’est un défaut courant sur les postes ; sur des serveurs cela peut être un piège si mDNS se comporte mal.
Décision : Si la résolution est lente ou erratique, considérez si mDNS interfère. Mais ne changez rien tout de suite — confirmez d’abord si le DNS est atteignable.
Task 6: Check /etc/resolv.conf identity and contents
cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 29 01:40 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example
Ce que ça signifie : Vous utilisez le stub local de systemd à 127.0.0.53. C’est correct si systemd-resolved est en cours d’exécution et si les serveurs amont sont configurés correctement.
Décision : Vérifiez que resolved tourne et a des serveurs en amont. Si resolved est arrêté, ce stub devient un puits noir.
Task 7: Check systemd-resolved health and upstream DNS
cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-12-29 01:39:12 UTC; 52min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
Main PID: 512 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4662)
Memory: 6.2M
CPU: 620ms
CGroup: /system.slice/systemd-resolved.service
└─512 /lib/systemd/systemd-resolved
cr0x@server:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (ens3)
Current Scopes: DNS
Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
DNS Servers: 10.10.0.53 10.10.0.54
DNS Domain: corp.example
Ce que ça signifie : resolved est actif et relaie vers 10.10.0.53/54. Pas de DoT, DNSSEC non validant. Ça semble sain.
Décision : Testez maintenant des requêtes directement contre le serveur DNS configuré pour détecter des problèmes de pare‑feu/VPN/split DNS.
Task 8: Query the upstream DNS directly (bypass stub)
cr0x@server:~$ dig @10.10.0.53 deb.debian.org A +time=2 +tries=1
; <<>> DiG 9.18.33-1-Debian <<>> @10.10.0.53 deb.debian.org A +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Ce que ça signifie : Votre serveur DNS amont n’est pas joignable (timeout). Ça peut être le routage, le pare‑feu, ou vous êtes sur le mauvais réseau pour ce résolveur (classique échec de split DNS via VPN).
Décision : Vérifiez si vous pouvez atteindre 10.10.0.53 du tout (ICMP peut être bloqué ; essayez des tests TCP/UDP 53). Validez le VPN et le routage.
Task 9: Test reachability to DNS server on port 53 (TCP and UDP)
cr0x@server:~$ nc -vz -w 2 10.10.0.53 53
nc: connect to 10.10.0.53 port 53 (tcp) timed out: Operation now in progress
cr0x@server:~$ sudo timeout 2 bash -c 'cat < /dev/null > /dev/udp/10.10.0.53/53' && echo ok || echo failed
failed
Ce que ça signifie : Les tentatives TCP et UDP échouent. Ce n’est pas une question de « faute de frappe DNS » ; c’est la reachabilité réseau vers le résolveur.
Décision : Corrigez le routage/VPN/pare‑feu vers le résolveur, ou basculez temporairement vers des résolveurs joignables (si la politique le permet) pour rétablir le service.
Task 10: Identify who configured DNS (DHCP, NetworkManager, networkd, VPN)
cr0x@server:~$ systemctl is-active NetworkManager
inactive
cr0x@server:~$ systemctl is-active systemd-networkd
active
cr0x@server:~$ networkctl status ens3 --no-pager
● 2: ens3
Link File: /usr/lib/systemd/network/99-default.link
Network File: /etc/systemd/network/10-ens3.network
Type: ether
State: routable (configured)
Online state: online
Address: 10.10.20.15/24
2001:db8:20::15/64
Gateway: 10.10.20.1
DNS: 10.10.0.53
10.10.0.54
DNS Domain: corp.example
Ce que ça signifie : systemd-networkd fournit les serveurs DNS. Si ces serveurs ne sont pas joignables depuis ce segment réseau, vous devez ajuster la config networkd ou la portée DHCP.
Décision : Validez que les serveurs DNS sont corrects pour ce VLAN/VPN. Si vous avez récemment changé de réseau, c’est votre preuve accablante.
Task 11: Verify proxy settings (environment variables)
cr0x@server:~$ env | grep -iE '^(http|https|no)_proxy='
http_proxy=http://proxy.corp.example:3128
https_proxy=http://proxy.corp.example:3128
no_proxy=localhost,127.0.0.1,.corp.example
Ce que ça signifie : Votre shell est configuré pour utiliser un proxy. Des outils comme curl, wget, et parfois git respecteront cela.
Décision : Si le proxy est requis, testez sa reachabilité. Si le proxy n’est pas requis sur ce réseau, unsettez-le et retestez la résolution.
Task 12: Check APT’s proxy configuration (can override env)
cr0x@server:~$ grep -R --line-number -E 'Acquire::(http|https)::Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/30proxy:1:Acquire::http::Proxy "http://proxy.corp.example:3128";
/etc/apt/apt.conf.d/30proxy:2:Acquire::https::Proxy "http://proxy.corp.example:3128";
Ce que ça signifie : APT est verrouillé sur un proxy indépendamment de vos variables d’environnement. Si ce proxy est injoignable, APT casse même si le DNS est correct.
Décision : Validez la connectivité du proxy ; si vous êtes hors réseau d’entreprise, désactivez ou conditionnez cette configuration.
Task 13: Test proxy connectivity and name resolution path
cr0x@server:~$ nc -vz -w 2 proxy.corp.example 3128
nc: getaddrinfo for host "proxy.corp.example" port 3128: Temporary failure in name resolution
cr0x@server:~$ nc -vz -w 2 10.10.30.40 3128
Connection to 10.10.30.40 3128 port [tcp/*] succeeded!
Ce que ça signifie : Le DNS échoue pour le nom du proxy, mais l’IP du proxy est joignable. C’est une situation classique où « le DNS est en panne » est vraie, mais la mitigation la plus rapide est d’utiliser l’IP du proxy temporairement (si la politique le permet) ou de réparer le DNS.
Décision : Choisissez une mitigation : réparer le DNS en amont, ou utiliser une entrée proxy basée sur l’IP temporaire pour restaurer les installations de paquets pendant l’incident.
Task 14: Detect IPv6 preference problems (AAAA resolves, connect fails)
cr0x@server:~$ getent ahosts deb.debian.org | head
2a04:4e42:600::644 deb.debian.org
2a04:4e42:400::644 deb.debian.org
146.75.106.132 deb.debian.org
cr0x@server:~$ curl -I https://deb.debian.org --max-time 5
curl: (6) Could not resolve host: deb.debian.org
Ce que ça signifie : C’est un exemple de décalage : getent renvoie des adresses, mais curl prétend ne pas pouvoir résoudre. Dans des incidents réels, cela pointe souvent vers une configuration de proxy (curl utilise le proxy et échoue), ou vers une configuration DNS propre à curl (rare), ou une discordance NSS/plugin dans des environnements conteneurisés.
Décision : Lancez curl avec le proxy désactivé et forcez la famille d’adresses pour isoler.
Task 15: Force curl to bypass proxy and pin address family
cr0x@server:~$ curl -I https://deb.debian.org --noproxy '*' --max-time 5
HTTP/2 200
server: envoy
content-type: text/html
date: Mon, 29 Dec 2025 02:32:11 GMT
cr0x@server:~$ curl -I https://deb.debian.org -4 --max-time 5
HTTP/2 200
server: envoy
content-type: text/html
date: Mon, 29 Dec 2025 02:32:14 GMT
cr0x@server:~$ curl -I https://deb.debian.org -6 --max-time 5
curl: (28) Failed to connect to deb.debian.org port 443 after 5000 ms: Connection timed out
Ce que ça signifie : Le DNS va bien. IPv4 fonctionne. La connexion IPv6 temps‑out. Ce n’est pas de la « résolution », c’est du routage ou du pare‑feu pour IPv6.
Décision : Soit réparez correctement le routage IPv6, soit désactivez/infériorisez temporairement IPv6 pour le client/système affecté pendant la réparation réseau.
Task 16: Check IPv6 routes and RA status
cr0x@server:~$ ip -6 route
2001:db8:20::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
Ce que ça signifie : Vous n’avez pas de route par défaut IPv6. Vous pouvez résoudre AAAA, mais vous ne pouvez pas atteindre l’internet IPv6. C’est le pire genre de « presque configuré ».
Décision : Réparez RA/route par défaut, ou désactivez IPv6 sur cette interface (ou configurez du routage politique) selon l’intention de votre environnement.
Task 17: Check whether resolved is listening on the stub
cr0x@server:~$ ss -lntu | grep -E '127\.0\.0\.53:53|:53'
udp UNCONN 0 0 127.0.0.53:53 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53:53 0.0.0.0:*
Ce que ça signifie : L’écouteur stub est présent. Si vous ne voyez rien écouter sur 127.0.0.53:53 alors que /etc/resolv.conf y pointe, la résolution échouera pour presque tout.
Décision : Si rien n’écoute, démarrez/activez resolved ou repointez /etc/resolv.conf vers des résolveurs réels (avec prudence, et de préférence temporairement).
Task 18: Inspect resolved logs for upstream failures and DNSSEC/DoT issues
cr0x@server:~$ journalctl -u systemd-resolved --since "30 min ago" --no-pager | tail -n 30
Dec 29 02:10:21 server systemd-resolved[512]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.10.0.53.
Dec 29 02:10:23 server systemd-resolved[512]: DNS server 10.10.0.53:53 timed out.
Dec 29 02:10:23 server systemd-resolved[512]: Switching to DNS server 10.10.0.54:53.
Dec 29 02:10:25 server systemd-resolved[512]: DNS server 10.10.0.54:53 timed out.
Dec 29 02:10:25 server systemd-resolved[512]: All attempts to contact name servers or networks failed.
Ce que ça signifie : Les résolveurs amont ne répondent pas. C’est le moment d’arrêter de tripoter le client et de commencer à regarder les ACL réseau, l’état du VPN ou la santé du service DNS amont.
Décision : Escaladez vers les propriétaires réseau/DNS avec des preuves : IP du serveur, IP des résolveurs, plage horaire, et si UDP/TCP échouent.
Task 19: Validate the resolver config from the application’s perspective
cr0x@server:~$ strace -f -e trace=network,connect,sendto,recvfrom -s 128 getent hosts deb.debian.org 2>&1 | tail -n 15
sendto(3, "\250\310\1\0\0\1\0\0\0\0\0\0\3deb\6debian\3org\0\0\1\0\1", 32, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 32
recvfrom(3, 0x7ffd8c3c6b10, 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [16]) = -1 EAGAIN (Resource temporarily unavailable)
Ce que ça signifie : Il essaie réellement 127.0.0.53, et il ne reçoit pas de réponse à temps. C’est une forte confirmation d’un problème stub/resolved.
Décision : Réparez resolved/la reachabilité amont. Ne perdez pas de temps à réécrire /etc/hosts sauf si vous avez besoin d’un contournement chirurgical temporaire pour un seul nom.
Task 20: Quick temporary mitigation (only if policy allows)
Si vous avez besoin de paquets maintenant et que vous avez une IP de résolveur joignable, vous pouvez remplacer temporairement le stub par des serveurs de noms directs. C’est tactique, pas une « solution finale ».
cr0x@server:~$ sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak
cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\n" | sudo tee /etc/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8
cr0x@server:~$ getent ahosts deb.debian.org | head -n 3
2a04:4e42:600::644 deb.debian.org
2a04:4e42:400::644 deb.debian.org
146.75.106.132 deb.debian.org
Ce que ça signifie : Vous avez contourné le stub local et les résolveurs d’entreprise. Cela peut violer la politique d’entreprise ou casser la résolution interne. Utilisez-le seulement comme pont d’incident.
Décision : Après l’incident, restaurez et corrigez le vrai problème en amont. Les rustines permanentes deviennent des sources d’incidents plus tard.
Erreurs courantes (symptôme → cause → correction)
Cette section est volontairement spécifique. Ces schémas se répètent parce qu’ils sont faciles à créer et difficiles à repérer sous pression.
1) Symptom: /etc/resolv.conf shows 127.0.0.53, but nothing resolves
Cause racine : systemd-resolved est désactivé/arrêté, ou l’écouteur stub n’est pas lié à cause de conflits.
Correction : Activez/démarrez resolved et vérifiez qu’il écoute ; ou repointez /etc/resolv.conf vers un résolveur réel. Cherchez aussi un service DNS local concurrent (dnsmasq, unbound) qui lie le port 53.
2) Symptom: dig works but apt and curl fail with “could not resolve host”
Cause racine : Configuration de proxy. Votre test DNS CLI est direct, mais l’application utilise un proxy (config APT ou variables d’environnement) et échoue avant le DNS ou délègue la résolution au proxy.
Correction : Validez Acquire::http::Proxy et http_proxy/https_proxy. Testez avec proxy désactivé (--noproxy) pour confirmer.
3) Symptom: Resolution is slow, intermittent, and CPU idle; logs show timeouts
Cause racine : Le résolveur amont est inaccessible à cause de changements de route VPN, pare‑feu, ou DNS DHCP erroné. systemd-resolved alterne serveurs et réessaye.
Correction : Confirmez la reachabilité des résolveurs configurés avec des tests UDP/TCP 53. Corrigez la liste des serveurs DNS pour le réseau sur lequel vous êtes.
4) Symptom: AAAA records exist; connections hang; sometimes error says “could not resolve host”
Cause racine : IPv6 est activé suffisamment pour être préféré mais pas suffisamment pour fonctionner (pas de route par défaut v6, pare‑feu brisé, RA mal configurée).
Correction : Soit réparez le routage IPv6 correctement (préférable), soit forcez IPv4 temporairement pour le client en panne ou désactivez IPv6 sur l’interface si ce n’est pas supporté.
5) Symptom: Internal names fail, external names work (or vice versa)
Cause racine : Split DNS et domaines de recherche. Le VPN attend des résolveurs d’entreprise pour corp.example, mais vous utilisez des résolveurs publics ; ou votre domaine de recherche fait résoudre incorrectement des noms courts.
Correction : Utilisez une configuration DNS par lien et des domaines de routage avec systemd-resolved (~corp.example) ou corrigez les paramètres DNS fournis par le VPN.
6) Symptom: Only one host is “unresolvable” and everyone edits /etc/hosts
Cause racine : Cache négatif périmé, DNS autoritatif mal configuré, ou cutover récent qui n’a pas propagé. /etc/hosts « corrige » une seule machine et crée une dette de maintenance.
Correction : Vérifiez les TTLs et les réponses autoritatives. Videz les caches si approprié (resolvectl flush-caches) et corrigez les enregistrements DNS au lieu d’ajouter des exceptions dans hosts.
7) Symptom: Container can’t resolve, host can
Cause racine : Le runtime du conteneur écrit son propre resolv.conf ou utilise un serveur DNS différent, souvent bloqué par la politique réseau.
Correction : Inspectez le /etc/resolv.conf du conteneur et les paramètres DNS du runtime. Alignez avec les résolveurs joignables depuis l’hôte ou utilisez un résolveur interne dédié accessible depuis ce réseau.
8) Symptom: DNS works right after reboot, then fails later
Cause racine : Course/override entre services qui écrivent la configuration du résolveur : client DHCP vs NetworkManager vs networkd vs scripts VPN up/down.
Correction : Choisissez un propriétaire du réseau par hôte. Supprimez les services concurrents. Assurez-vous que la configuration du résolveur est gérée de façon cohérente et surveillée.
Blague #2 : Si vous « corrigez » le DNS en codant des IP dans /etc/hosts, félicitations — vous venez d’inventer la dérive de configuration avec étapes supplémentaires.
Trois mini-récits d’entreprise depuis le terrain
Mini-récit 1 : La panne causée par une mauvaise hypothèse
Ils avaient une image standard pour les serveurs Debian : networkd, resolved, et un profil de durcissement. Une équipe a lancé un nouvel environnement dans un segment de centre de données différent et a cloné la même image. Tout a démarré. Les agents de monitoring ont check-in. Puis les déploiements ont commencé à échouer sur « Could not resolve host ».
Le responsable de garde a supposé « le DNS doit être en panne » parce que c’est ce que disait l’erreur. Il a escaladé vers l’équipe DNS, qui a répondu (correctement) que leur service était sain et répondait aux requêtes. Pendant ce temps l’incident tournait parce que les mises à jour de paquets ne pouvaient pas se faire, les images de conteneurs ne pouvaient pas se tirer, et la pipeline de déploiement se relançait au point de provoquer un petit DDoS auto‑infligé.
Le vrai problème était ennuyeux : l’image avait des serveurs DNS épinglés aux IP des résolveurs de l’ancien segment. Ces IP de résolveur n’étaient joignables qu’à l’intérieur du VLAN original ; le nouveau segment ne pouvait pas y router par conception. L’hypothèse que « DNS est global » est vraie philosophiquement et fausse pratiquement. Le DNS d’entreprise est souvent par segment pour la latence, le contrôle et la politique.
Ils ont corrigé cela en récupérant les serveurs DNS via DHCP dans cet environnement au lieu de les coder en dur, et en ajoutant une validation au démarrage : si les serveurs DNS configurés ne sont pas joignables sur UDP/TCP 53, échouer la provision. Le lendemain, tout le monde se souvenait que « resolve host » est moitié nommage, moitié routage vers le résolveur.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une équipe plateforme voulait des builds plus rapides. Ils ont activé DNS over TLS sur une flotte parce que le DNS chiffré semblait un bénéfice gratuit : confidentialité, intégrité, et une touche moderne. C’était joli dans les revues de sécurité.
Deux semaines plus tard, ils ont commencé à voir des échecs sporadiques pendant les heures de pointe. Pas des pannes totales — pire. Certains hôtes mettaient 20–30 secondes à résoudre certains noms. Les jobs CI flippaient. Les développeurs ouvraient des tickets « le réseau est hanté ». Le service DNS lui‑même était sain, mais le chemin pour y parvenir ne l’était pas.
Le coupable était une politique de pare‑feu amont qui limitait le débit ou dropait de manière intermittente le port 853 quand un certain pattern de trafic apparaissait. UDP/53 était autorisé et stable ; TCP/853 était « autorisé » mais pas fiable. Les clients retombaient de façon désordonnée : certains réessayaient, d’autres bloquaient, d’autres mettaient en cache des réponses négatives. L’optimisation avait amélioré la posture sécurité mais ajouté une dépendance fragile à des middleboxes qui ne la supportaient pas sous charge.
La correction pragmatique fut de rendre DoT conditionnel : activé seulement sur des réseaux avec support vérifié, avec monitoring comparant latence et taux d’échec entre modes. Ils l’ont aussi documenté dans les profils d’image pour que les équipes futures n’héritent pas de « fonctionnalités de sécurité » qui diminuent silencieusement la fiabilité.
Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise
Un système lié aux finances (personne ne veut de downtime ni de changement) tournait Debian avec des règles egress strictes. Ils ne pouvaient parler qu’à un petit ensemble de services internes : un proxy, un DNS interne, et quelques dépôts miroirs internes.
L’équipe faisait une chose ennuyeuse exceptionnellement bien : ils gardaient un runbook avec des sorties connues‑bonnes pour l’état du résolveur. Pas de la théorie. Des instantanés réels d’un système sain : resolvectl status, ip route, getent hosts pour des domaines internes clés, plus quel service possède la configuration DNS sur cet hôte.
Quand « Could not resolve host » est survenu pendant une fenêtre de changement, ils n’ont pas débattu. Ils ont comparé les sorties actuelles aux instantanés sains. Le diff a été instantané : les serveurs DNS configurés avaient changé vers une liste générique fournie par DHCP après un redémarrage d’un service réseau. Cette liste était correcte pour des postes et erronée pour des serveurs verrouillés. Le runbook « ennuyeux » leur a évité de chasser le proxy, de blâmer le DNS amont, ou de perdre 45 minutes à argumenter sur IPv6.
Ils ont restauré la source de DNS, épinglé la propriété réseau à networkd, et ajouté une alerte : si les serveurs DNS configurés divergent de l’ensemble approuvé, pager tôt — avant que les erreurs applicatives n’apparaissent. Ce n’était pas glamour, mais ça a gardé l’incident sous contrôle.
Listes de contrôle / plan étape par étape
Ceci est le plan à suivre si vous voulez des résultats répétables, pas du débogage héroïque.
Checklist A: Fast triage (5–10 minutes)
- Capturez la commande qui échoue et le nom d’hôte. Dépôt APT ? Remote Git ? Nom du proxy ? Notez-le.
- Vérifiez l’adresse IP et la route par défaut.
ip -br addr,ip route. - Pinguez la passerelle et une IP connue. Si l’IP échoue, arrêtez et réparez le routage.
- Vérifiez le chemin de résolution système.
getent ahosts <host>. - Inspectez /etc/resolv.conf. Stub vs serveurs directs.
- Si stub, vérifiez resolved.
systemctl status systemd-resolved,resolvectl status,ss -lntu | grep :53. - Testez les résolveurs amont directement.
dig @server host A, puis tests de port si nécessaire. - Vérifiez les proxies.
env | grep -i proxyet entrées proxy dans/etc/apt/apt.conf.d. - Vérifiez la réalité IPv6.
ip -6 route; testezcurl -4vscurl -6.
Checklist B: Safe mitigations (choose one, don’t stack them blindly)
- Vider les caches (utile quand vous avez réparé l’amont mais que les clients échouent encore) :
cr0x@server:~$ sudo resolvectl flush-cachesDécision : Si la résolution revient après vidage du cache, investiguez les fluctuations amont ou le cache négatif.
- Redémarrer resolved (utile quand le stub est bloqué, pas quand l’amont est injoignable) :
cr0x@server:~$ sudo systemctl restart systemd-resolved cr0x@server:~$ resolvectl query deb.debian.org deb.debian.org: 146.75.106.132 -- link: ens3 2a04:4e42:600::644 -- link: ens3Décision : Si le redémarrage aide, vous devez toujours expliquer pourquoi il s’est bloqué. Regardez les logs et la reachabilité amont.
- Forcer temporairement IPv4 pour une opération critique (utile quand IPv6 est cassé et que vous avez besoin d’un pont) :
cr0x@server:~$ sudo apt-get -o Acquire::ForceIPv4=true update Hit:1 http://deb.debian.org/debian trixie InRelease Reading package lists... DoneDécision : Si cela marche, planifiez une remédiation IPv6 correcte ou configurez une politique si IPv6 n’est pas supporté.
- Contourner temporairement le proxy pour des endpoints connus (utile quand la config proxy est erronée) :
cr0x@server:~$ unset http_proxy https_proxy no_proxy cr0x@server:~$ curl -I https://deb.debian.org --max-time 5 HTTP/2 200 server: envoy content-type: text/html date: Mon, 29 Dec 2025 02:41:22 GMTDécision : Si le unset répare, traitez le proxy comme domaine incident. Reconfigurez correctement plutôt que de le laisser à moitié actif.
Checklist C: Make it stay fixed (post-incident hardening)
- Source unique de vérité pour la config DNS. Choisissez NetworkManager ou networkd. Supprimez l’autre si possible.
- Surveillez la reachabilité des résolveurs. Alertez quand les serveurs DNS configurés ne répondent pas sur UDP/TCP 53.
- Enregistrez des sorties connues‑bonnes. Gardez une base pour
resolvectl status, la cible de/etc/resolv.conf, et la config proxy. - Documentez la propriété du proxy. Est‑ce des vars d’environnement, la config APT, ou une politique système ? Rendez‑le explicite.
- Décidez ce qu’est IPv6. Entièrement supporté, ou explicitement désactivé. « À moitié fonctionnel » n’est pas une stratégie.
FAQ
1) Pourquoi ping vers une IP fonctionne mais les noms d’hôte échouent ?
Parce que le routage est correct mais la résolution de noms échoue. Vous avez prouvé la connectivité L3 ; isolez maintenant le chemin résolveur (getent, /etc/resolv.conf, resolvectl).
2) Pourquoi dig fonctionne mais getent échoue ?
dig interroge le DNS directement. getent utilise NSS, qui peut consulter files, mDNS, SSSD ou d’autres sources avant DNS. Vérifiez /etc/nsswitch.conf et si le module DNS est joignable via le résolveur configuré.
3) Est‑ce que 127.0.0.53 dans /etc/resolv.conf est un bug ?
Non. C’est le résolveur stub de systemd-resolved. C’est correct quand resolved tourne et est configuré. C’est incorrect quand resolved est arrêté ou que les serveurs amont sont injoignables et que personne ne le remarque.
4) Comment savoir si le proxy cause « Could not resolve host » ?
Désactivez le proxy pour un test. Pour curl : curl --noproxy '*'. Pour APT : commentez temporairement la config proxy dans /etc/apt/apt.conf.d (ou exécutez dans un environnement contrôlé). Si l’erreur disparaît, le chemin proxy est votre coupable.
5) Pourquoi forcer IPv4 règle le problème ?
Parce que la résolution DNS retourne à la fois A et AAAA, et le client peut préférer IPv6. Si le routage/firewall IPv6 est cassé, les connexions se bloquent. Forcer IPv4 évite cette voie. C’est une mitigation, pas une victoire morale.
6) Dois‑je coder en dur des serveurs DNS dans /etc/resolv.conf ?
Comme mitigation d’incident temporaire, parfois. À long terme, généralement non — car il sera écrasé par votre stack réseau et casse le split DNS et les noms internes. Corrigez la source de configuration réelle (DHCP, networkd, NetworkManager, client VPN).
7) Pourquoi les noms courts internes se résolvent différemment selon les hôtes ?
Domaines de recherche et split DNS. Un hôte peut avoir search corp.example, un autre non. Certains environnements s’appuient sur les noms courts ; d’autres ne devraient pas. Standardisez et préférez les FQDN pour l’automatisation.
8) Comment savoir quel composant « possède » la configuration DNS sur Debian 13 ?
Vérifiez quel service réseau est actif (NetworkManager vs systemd-networkd), puis utilisez resolvectl status et networkctl status. Inspectez aussi si /etc/resolv.conf est un lien symbolique vers le répertoire systemd resolve.
9) Quelle est la méthode la plus sûre pour déboguer sans casser la production ?
Privilégiez d’abord les commandes en lecture seule (ip, getent, resolvectl, dig, ss, logs). Quand vous changez quelque chose, touchez une seule option, enregistrez-la, et soyez prêt à revenir en arrière.
10) Quelle citation garder en tête pendant ces incidents ?
L’espérance n’est pas une stratégie.
— idée paraphrasée souvent répétée dans les cercles fiabilité et opérations.
Conclusion : prochaines étapes réalisables aujourd’hui
Si vous ne retenez qu’une chose : séparez la résolution de la reachabilité, et séparez le chemin résolveur système du comportement applicatif. Cela évite les éditions inutiles et vous conduit rapidement vers le bon propriétaire.
La prochaine fois que « Could not resolve host » apparaît sur Debian 13 :
- Prouvez la connectivité IP (
ip route, ping passerelle, ping IP connue). - Prouvez la résolution NSS (
getent ahosts) et comparez au DNS direct (dig). - Confirmez la propriété du résolveur (
/etc/resolv.confsymlink,resolvectl status). - Interrogez les proxies et IPv6, car ils se comportent comme des mensonges ressemblant à du DNS.
- Appliquez une mitigation unique, restaurez le service, puis corrigez la cause amont et retirez la mitigation.
Faites l’investissement ennuyeux : collectez des sorties de référence, surveillez la reachabilité des résolveurs, et prenez une décision claire sur le support IPv6. C’est ainsi que vous empêcherez « Could not resolve host » de devenir un personnage récurrent dans vos rapports d’incident.