Proxmox « impossible de résoudre l’hôte » : procédure rapide d’identification (DNS/IPv6/proxy)

janvier 19, 2026 • février 3, 2026 • Lecture : 31 min • Views: 6

Cet article vous a aidé ?

Rien ne rend un nœud Proxmox plus « en production » que le moment où vous lancez apt update et qu’il répond : « impossible de résoudre l’hôte ». Soudain votre fenêtre de maintenance est prise en otage, votre cluster HA est « correct-mais-pas-vraiment », et vous êtes face à un problème DNS qui peut en réalité venir d’IPv6, du routage ou d’un proxy qui n’existe que dans la présentation de quelqu’un.

Voici un workflow rapide et orienté pour les SRE et les opérateurs qui ont besoin que le nœud se mette à jour tout de suite, mais qui veulent aussi corriger la vraie cause pour éviter une suite catastrophique lors de la prochaine fenêtre de maintenance.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand le temps presse, ne « tentez pas des trucs ». Prouvez où se situe la panne. Ce playbook est ordonné pour maximiser le signal en un minimum de temps.

Premier : est-ce du DNS ou une problème de connectivité basique ?

Vérifiez si le nœud peut joindre une IP sur Internet (sans DNS). S’il ne le peut pas, arrêtez d’accuser le DNS. Corrigez d’abord le routage/le pare-feu.
Vérifiez si le nœud peut résoudre un nom en utilisant son résolveur configuré. Si non, c’est la configuration DNS, l’accessibilité du serveur DNS, ou un problème de service résolveur.
Vérifiez si le nœud peut se connecter à l’hôte du dépôt après résolution. Si le DNS fonctionne mais TCP échoue, c’est proxy/pare-feu/MTU/TLS.

Deuxième : déterminez si IPv6 est dans l’aire d’effet

Vérifiez si la résolution retourne des enregistrements AAAA et si le système les privilégie.
Testez le routage IPv6. Une route par défaut IPv6 cassée peut provoquer des timeouts du résolveur et des symptômes « impossible de résoudre l’hôte », selon le client.
Forcer temporairement IPv4 pour un contournement opérationnel rapide (puis corriger IPv6 correctement).

Troisième : proxies (explicites, auto-config, « transparents ») et spécificités APT

Vérifiez les variables d’environnement et la configuration proxy d’APT. APT peut être proxifié même si votre shell ne l’est pas.
Testez l’egress direct vs via proxy. Faites une requête explicite avec et sans proxy et comparez.
Confirmez le comportement DNS du proxy. Certains proxies résolvent à votre place ; d’autres attendent que votre nœud résolve.

Si vous suivez cet ordre, vous trouverez généralement le goulot d’étranglement en moins de dix minutes. Sinon, vous passerez une heure à « réparer le DNS » en cassant IPv6 et en apprenant au proxy à mentir.

Modèle mental : ce que signifie vraiment « impossible de résoudre l’hôte » sur Proxmox

Sur Proxmox (basé sur Debian), « impossible de résoudre l’hôte » provient typiquement d’une des trois couches :

Couche résolveur : la pile de résolveur libc ne peut pas convertir un nom d’hôte en IP. Cela peut venir du fait que le serveur DNS configuré est inaccessible, que le service résolveur est mal câblé, ou que le nœud utilise un résolveur inattendu (systemd-resolved vs resolv.conf classique).
Couche transport déguisée en DNS : certains outils signalent une erreur de résolution quand ils expirent lors d’une tentative de résolution dépendant de la connectivité réseau (particulièrement avec préférence IPv6 ou itinéraires cassés).
Couche proxy : le client pense devoir parler à un proxy, le proxy est indisponible, exige une authentification, ou le comportement DNS du proxy ne correspond pas à votre architecture réseau.

Proxmox complique un peu les choses parce que votre nœud est aussi un appareil réseau. Il a des bridges, des VLAN, parfois des bonds, parfois plusieurs uplinks, parfois des réseaux de gestion avec DNS spécifiques. Et il exécute des services critiques (corosync, pvedaemon, pveproxy) que vous ne voulez pas perturber en « testant une correction ».

Règle un : ne modifiez pas sauvagement /etc/resolv.conf en espérant le meilleur. Prouvez le chemin. Puis changez le minimum.

Blague n°1 : Le DNS est le seul système où « ça marche sur mon laptop » devient un modèle de menace.

Faits intéressants et contexte historique (oui, c’est important)

resolv.conf précède la plupart de vos outils. Le format du fichier vient des anciennes conventions Unix pour le résolveur et ancre encore beaucoup de configurations modernes, même quand c’est un lien symbolique géré par autre chose.
systemd-resolved a changé les modes de défaillance par défaut. Au lieu d’un /etc/resolv.conf statique avec des résolveurs en amont, beaucoup de systèmes pointent maintenant vers un stub local (souvent 127.0.0.53) et le démon gère la remontée vers les serveurs en amont.
APT a sa propre personnalité réseau. Il ne se comporte pas exactement comme curl ou wget en ce qui concerne le proxy, la préférence IPv6 ou le rapport d’erreurs. Tester avec apt est important.
Le déploiement partiel d’IPv6 est pire que l’absence d’IPv6. Un réseau qui annonce IPv6 mais ne peut pas le router de manière fiable créera des problèmes intermittents difficiles à déboguer pour la résolution et la connectivité.
Happy Eyeballs existe parce qu’IPv6 a compliqué la vie. Les clients modernes essaient IPv6 et IPv4 en parallèle pour réduire la latence perçue. Mais tous les outils ne l’implémentent pas de la même façon, et certains restent bloqués.
Le DNS à horizon partagé est courant en entreprise. Un DNS interne renvoie des réponses différentes du DNS public. Les nœuds Proxmox se trouvent souvent dans des segments « semi-internes » où le mauvais résolveur donne de mauvaises réponses.
Le comportement du résolveur glibc est conservateur. Il peut interroger les serveurs dans l’ordre, appliquer des timeouts et réessayer. Un seul serveur mort en tête de liste peut ajouter des retards importants qui semblent indiquer « le DNS est en panne ».
Les clusters Proxmox dépendent de la résolution de noms plus que vous ne le pensez. Vous pouvez fonctionner par IP, mais beaucoup de scripts opérationnels, métriques, intégrations de sauvegarde et configurations de dépôts supposent que les noms d’hôtes fonctionnent de façon cohérente.
PAC/WPAD (auto-configuration de proxy) est ancien et provoque encore des pannes. Un client qui récupère un paramètre de proxy qu’il ne devrait pas utiliser est un piège classique « ça marchait hier, ça casse aujourd’hui ».

Tâches pratiques : commandes, sorties attendues et décisions (12+)

Voici des actions concrètes d’opérateur. Chacune comporte : la commande, ce que signifie la sortie, et la décision suivante. Exécutez-les sur le nœud Proxmox (pve), pas sur votre laptop, parce que votre laptop ment toujours.

Tâche 1 : Confirmez que l’erreur est bien une résolution de nom

cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Err:2 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  Could not resolve 'enterprise.proxmox.com'
Reading package lists... Done
W: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  Could not resolve 'enterprise.proxmox.com'

Sens : APT signale que la résolution DNS a échoué pour un hôte précis. Cela peut toutefois encore être une mauvaise configuration de proxy ou une reachabilité IPv6 provoquant un timeout du résolveur.

Décision : Passez à des tests de résolution directs (getent, resolvectl, dig) avant d’éditer quoi que ce soit.

Tâche 2 : Vérifiez les résolveurs que le système pense avoir (chemin systemd-resolved)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Sens : L’hôte utilise systemd-resolved en mode stub, avec des serveurs DNS en amont listés. Bien : vous avez une source d’autorité.

Décision : Si les serveurs DNS ne sont pas ceux attendus, corrigez la configuration réseau (interfaces) ou la configuration de systemd-resolved ; ne durcissez pas /etc/resolv.conf sauf si vous contournez volontairement resolved.

Tâche 3 : Si resolvectl n’est pas disponible ou semble vide, inspectez /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Nov 21 10:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Sens : C’est un lien symbolique vers le stub de systemd-resolved. L’éditer directement est une perte de temps ; il sera écrasé.

Décision : Utilisez resolvectl, la config de systemd-resolved, ou ajustez les paramètres DNS de l’interface plutôt que des modifications manuelles.

Tâche 4 : Tester la résolution via libc (c’est ce que la plupart des applications utilisent)

cr0x@server:~$ getent ahosts enterprise.proxmox.com
51.91.38.34    STREAM enterprise.proxmox.com
51.91.38.34    DGRAM
51.91.38.34    RAW

Sens : libc peut résoudre le nom d’hôte. Si APT échoue toujours, suspectez le proxy, l’interception TLS ou des timeouts DNS intermittents plutôt qu’une panne DNS totale.

Décision : Si getent réussit, passez aux tests de connectivité. S’il échoue, focalisez-vous sur la configuration du résolveur et l’accessibilité du serveur DNS.

Tâche 5 : Tester le DNS brut vers un serveur de noms spécifique (bypasser la logique résolveur locale)

cr0x@server:~$ dig @10.10.0.53 enterprise.proxmox.com +time=2 +tries=1

; <<>> DiG 9.18.24-1 <<>> @10.10.0.53 enterprise.proxmox.com +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19041
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
enterprise.proxmox.com. 300 IN A 51.91.38.34

;; Query time: 21 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Dec 26 10:12:11 UTC 2025
;; MSG SIZE  rcvd: 64

Sens : Le serveur DNS est joignable et répond. Si d’autres noms échouent, ce n’est pas « le DNS est en panne », c’est « le DNS est sélectivement cassé ». Problème différent.

Décision : Si la requête expire, testez le routage vers le serveur DNS et vérifiez les règles de pare-feu entre le nœud et le résolveur.

Tâche 6 : Vérifiez que vous pouvez joindre le serveur DNS du tout (routage + ACL)

cr0x@server:~$ ping -c 2 10.10.0.53
PING 10.10.0.53 (10.10.0.53) 56(84) bytes of data.
64 bytes from 10.10.0.53: icmp_seq=1 ttl=63 time=0.612 ms
64 bytes from 10.10.0.53: icmp_seq=2 ttl=63 time=0.590 ms

--- 10.10.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.590/0.601/0.612/0.011 ms

Sens : Au moins ICMP fonctionne. Ce n’est pas la preuve que UDP/53 fonctionne, mais cela exclut la théorie « pas de route ».

Décision : Si le ping échoue, vérifiez la route par défaut, le marquage VLAN, la configuration du bridge et les politiques de pare-feu.

Tâche 7 : Confirmez les routes par défaut (IPv4 et IPv6) pour exclure « DNS par le chemin vers nulle part »

cr0x@server:~$ ip route
default via 10.10.0.1 dev vmbr0 proto kernel
10.10.0.0/24 dev vmbr0 proto kernel scope link src 10.10.0.20

cr0x@server:~$ ip -6 route
default via fe80::1 dev vmbr0 proto ra metric 1024 expires 1532sec
2001:db8:10:10::/64 dev vmbr0 proto kernel metric 256

Sens : Vous avez des routes par défaut pour les deux piles. Si la route IPv6 existe mais que l’amont est cassé, certains clients essaieront IPv6 en premier et bloqueront.

Décision : Si IPv6 semble suspect (route présente mais amont non fonctionnel), testez explicitement la reachabilité IPv6 et décidez si désactiver IPv6 temporairement ou réparer RA/route.

Tâche 8 : Tester la connectivité sans DNS (prouver l’egress)

cr0x@server:~$ curl -I --connect-timeout 3 https://1.1.1.1
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Tue, 26 Dec 2025 10:13:01 GMT
Content-Type: text/html
Content-Length: 155
Connection: close

Sens : Vous pouvez atteindre Internet et effectuer une handshake TLS vers une IP connue. Le 400 est normal ; le chemin réseau fonctionne.

Décision : Si cela échoue, stoppez : vous avez un problème d’egress/routage/pare-feu, pas un problème DNS.

Tâche 9 : Tester DNS + TCP vers l’hôte du dépôt (vérification de bout en bout)

cr0x@server:~$ curl -I --connect-timeout 5 https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease
HTTP/2 200
date: Tue, 26 Dec 2025 10:13:33 GMT
content-type: application/octet-stream
content-length: 1880

Sens : DNS et HTTPS fonctionnent de bout en bout. Si APT échoue encore, c’est probablement la config proxy d’APT, APT utilisant IPv6 différemment, ou un timeout résolveur transitoire.

Décision : Si curl fonctionne mais pas APT, comparez les réglages proxy et forcez IPv4 dans APT comme test.

Tâche 10 : Vérifier la configuration proxy qui affecte APT (courant en entreprise)

cr0x@server:~$ grep -R "Acquire::http::Proxy" -n /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/80proxy:1:Acquire::http::Proxy "http://proxy.corp.example:3128";
/etc/apt/apt.conf.d/80proxy:2:Acquire::https::Proxy "http://proxy.corp.example:3128/";

Sens : APT est forcé via un proxy, même si votre shell ne l’est pas. Si ce proxy est down ou malveillant, APT peut afficher des erreurs trompeuses.

Décision : Validez la connectivité du proxy, l’authentification et le comportement DNS. Si l’environnement ne devrait pas utiliser de proxy, retirez cette config délibérément (ne faites pas juste un commentaire temporaire).

Tâche 11 : Vérifier les variables d’environnement proxy du shell (elles peuvent saboter curl/wget aussi)

cr0x@server:~$ env | grep -i proxy
http_proxy=http://proxy.corp.example:3128
https_proxy=http://proxy.corp.example:3128
no_proxy=localhost,127.0.0.1,10.0.0.0/8

Sens : Votre shell est proxifié. Certains outils respectent ces variables, d’autres non. Le comportement mixte crée des tests contradictoires.

Décision : Pour des tests propres, lancez les commandes avec le proxy désactivé/activé explicitement.

Tâche 12 : Prouvez la connectivité du proxy et si le proxy résout le DNS pour vous

cr0x@server:~$ curl -I --proxy http://proxy.corp.example:3128 --connect-timeout 5 https://enterprise.proxmox.com/
HTTP/1.1 200 Connection established

HTTP/2 200
date: Tue, 26 Dec 2025 10:14:11 GMT
content-type: text/html; charset=utf-8

Sens : Le proxy est joignable et peut établir un tunnel HTTPS. Si le proxy renvoie lui-même des erreurs « impossible de résoudre l’hôte », alors le DNS du proxy est en panne, pas celui de votre nœud.

Décision : Si le proxy fonctionne mais que l’accès direct échoue, votre réseau exige un egress via proxy. Si l’accès direct fonctionne mais que le proxy échoue, supprimez la dépendance au proxy pour les nœuds si la politique le permet.

Tâche 13 : Forcer IPv4 pour un test isolé afin d’isoler les problèmes de préférence IPv6

cr0x@server:~$ curl -4 -I --connect-timeout 5 https://enterprise.proxmox.com/
HTTP/2 200
date: Tue, 26 Dec 2025 10:14:40 GMT
content-type: text/html; charset=utf-8

Sens : Le chemin IPv4 est bon. Si le curl sans -4 bloque ou échoue, IPv6 est probablement cassé ou filtré.

Décision : Réparez le routage IPv6 ou désactivez IPv6 sur le nœud/réseau de gestion jusqu’à ce qu’il soit supporté de bout en bout.

Tâche 14 : Inspecter la configuration NSS (rare, mais létale lorsqu’elle est erronée)

cr0x@server:~$ grep -E "^(hosts:)" /etc/nsswitch.conf
hosts:          files dns

Sens : La résolution d’hôtes utilise /etc/hosts puis DNS. Si cette ligne est étrange (manque dns, ou inclut des modules cassés), vous obtenez des pannes bizarres.

Décision : Gardez files dns sauf si vous avez une raison très valable d’être plus malin.

Tâche 15 : Vérifiez /etc/hosts pour les erreurs auto-infligées

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
10.10.0.20 pve01.corp.example pve01

Sens : C’est sain : localhost pointe vers 127.0.0.1 seulement ; l’IP de gestion du nœud pointe vers son nom. Si vous mappez des noms externes ici, vous méritez la panne que vous obtenez.

Décision : Ne fixez que ce qui est nécessaire (généralement le nom propre du nœud). Utilisez le DNS pour le reste.

Tâche 16 : Capturer les paquets DNS (quand vous avez besoin de preuves, pas d’opinions)

cr0x@server:~$ tcpdump -ni vmbr0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:15:11.123456 IP 10.10.0.20.41788 > 10.10.0.53.53: 1234+ A? enterprise.proxmox.com. (39)
10:15:11.144321 IP 10.10.0.53.53 > 10.10.0.20.41788: 1234 1/0/1 A 51.91.38.34 (55)
10:15:11.145001 IP 10.10.0.20.35321 > 10.10.0.53.53: 5678+ AAAA? enterprise.proxmox.com. (39)
10:15:11.165210 IP 10.10.0.53.53 > 10.10.0.20.35321: 5678 0/1/1 (94)
5 packets captured

Sens : Vous pouvez voir les requêtes et réponses. Ici : l’enregistrement A revient, AAAA ne retourne rien (peut-être NODATA). Ce n’est pas forcément incorrect.

Décision : Si vous voyez des requêtes partir sans réponses, c’est un problème de chemin/ACL. Si vous voyez des réponses mais que les applications échouent encore, regardez la sélection de résolveur, le cache ou le comportement du proxy.

Tâche 17 : Vérifiez la santé et les logs de systemd-resolved

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 Tue 2025-12-26 09:55:02 UTC; 20min ago
       Docs: man:systemd-resolved.service(8)
   Main PID: 612 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38351)
     Memory: 7.2M
        CPU: 1.104s
     CGroup: /system.slice/systemd-resolved.service
             └─612 /lib/systemd/systemd-resolved

cr0x@server:~$ journalctl -u systemd-resolved -n 20 --no-pager
Dec 26 10:02:11 server systemd-resolved[612]: Using DNS server 10.10.0.53 for interface vmbr0.
Dec 26 10:07:44 server systemd-resolved[612]: Switching to DNS server 10.10.0.54 for interface vmbr0.
Dec 26 10:08:10 server systemd-resolved[612]: Using degraded feature set UDP instead of TCP for DNS server 10.10.0.54.

Sens : Resolved bascule entre serveurs ou dégrade le transport. C’est un indice fort que vos serveurs DNS sont instables ou bloqués pour TCP/53/EDNS0.

Décision : Escaladez vers l’infrastructure DNS ou ajustez les résolveurs utilisés par le nœud (privilégiez des résolveurs locaux stables).

Tâche 18 : Validez la configuration des dépôts Proxmox (parce que « impossible de résoudre l’hôte » signifie parfois « mauvais hôte »)

cr0x@server:~$ grep -R "proxmox" -n /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Sens : L’hôte du dépôt est exactement ce que APT tente de résoudre. Si vous avez copié une config depuis un wiki ou une ancienne build, vous pourriez pointer vers un nom d’hôte bloqué, retiré ou atteignable uniquement via proxy.

Décision : Confirmez que vous utilisez le dépôt correct selon votre statut d’abonnement et la politique réseau. Ne « corrigez pas le DNS » pour atteindre un dépôt que vous n’êtes pas autorisé à utiliser.

Pile DNS sur Proxmox : resolv.conf, systemd-resolved et pièges habituels

La plupart des déploiements Proxmox sont essentiellement Debian avec des préconisations. Debian vous donne des choix pour la résolution de noms : resolv.conf classique, ou systemd-resolved comme résolveur stub local. Les nœuds Proxmox sont souvent configurés via /etc/network/interfaces (ifupdown2) et héritent parfois du DNS via DHCP, parfois via une configuration statique.

Sachez quel chemin de résolveur vous utilisez

Le moyen le plus rapide : que contient /etc/resolv.conf ?

Si cela pointe vers 127.0.0.53 (stub), vous êtes sur systemd-resolved et les DNS en amont sont contrôlés ailleurs.
Si cela contient des entrées nameserver 10.x.x.x directement, vous êtes probablement sur gestion classique de resolv.conf (ou resolved est en mode « foreign »).
Si ce fichier est réécrit à chaque reboot, vous avez probablement un client DHCP, NetworkManager, ou des hooks ifupdown qui le gèrent.

Les opérateurs se font piéger parce qu’ils « réparent » le DNS en éditant resolv.conf, ça marche 20 minutes, puis la pile réseau l’écrase. La fenêtre de patch suivante devient un festival de déjà-vu.

Privilégiez des sources de résolveur stables pour les nœuds

En environnement entreprise, les meilleurs serveurs DNS pour les nœuds Proxmox sont généralement :

Des résolveurs récursifs locaux conçus pour l’infrastructure (souvent internes), avec supervision et redondance.
Des résolveurs accessibles sur le VLAN de gestion avec des règles de pare-feu explicites.

Les pires serveurs DNS pour les nœuds Proxmox sont généralement :

Des résolveurs grand public accessibles « certaines fois » via des chemins NAT.
Des serveurs DNS de succursales qui disparaissent lors d’événements WAN.
Tout ce qui dépend de portails captifs, contrôles d’intégrité de poste ou authentification web « utile ».

Comportement des timeouts : un serveur mort peut gâcher la journée

Le résolveur libc essaie typiquement les serveurs dans l’ordre, avec timeouts et réessais. Si votre premier serveur est mort et que le second est sain, la résolution reste lente et peut sembler échouer sous charge.

Si vous observez de longues pauses sur apt update avant l’échec, suspectez des timeouts plutôt qu’un NXDOMAIN propre. C’est du routage, du pare-feu, ou un résolveur mort, pas une faute de frappe.

Règle de bon sens

L’espoir n’est pas une stratégie. — souvent cité dans la culture opérationnelle (idée paraphrasée)

Modes de défaillance IPv6 qui se déguisent en DNS

IPv6 n’est pas le vilain. Le vilain, c’est le demi-IPv6 : quand le nœud reçoit une adresse IPv6 et une route par défaut (via RA), mais que le routage amont, le pare-feu ou le proxy ne supportent pas réellement l’egress IPv6.

Voici comment cela devient un problème « impossible de résoudre l’hôte » :

Votre résolveur retourne à la fois des enregistrements A et AAAA.
Le client privilégie AAAA (IPv6) ou l’essaie en premier.
La tentative de connexion bloque ou échoue.
L’application rapporte une erreur générique. Certaines appli blâment le DNS parce que la résolution était impliquée.

Signes qui crient « IPv6 vous ment »

getent ahosts retourne des entrées IPv6 (AAAA) et IPv4, mais seules les connexions IPv4 fonctionnent.
curl -4 fonctionne ; le curl sans option est lent ou échoue.
Vous avez une route par défaut IPv6 mais pas de connectivité upstream IPv6 stable.

Que faire

Dans un monde idéal, vous réparez IPv6 correctement : RA correct, routage correct, pare-feu correct, DNS correct. Dans le monde réel, vous aurez aussi besoin d’un contournement opérationnel sûr. Deux approches pragmatiques :

Forcer IPv4 pour APT pendant une fenêtre d’incident (solution court terme).
Désactiver IPv6 sur l’interface de gestion si votre organisation ne le supporte pas encore (nettoyage moyen terme).

Restez disciplinés : si vous désactivez IPv6, documentez-le et suivez le travail pour le réactiver lorsque le réseau sera prêt. « Temporaire » est la manière la plus sûre d’accumuler une configuration legacy jusqu’en 2035 et une équipe qui croit qu’IPv6 est hanté.

Blague n°2 : IPv6 est génial — jusqu’à ce que quelqu’un le déploie « en concept » plutôt qu’en réseau.

Proxy d’entreprise et modes de défaillance de proxy « transparent »

Les nœuds Proxmox sont des serveurs. Mais ils vivent souvent dans des réseaux conçus pour des postes clients. C’est comme ça qu’on se retrouve avec des proxies. Parfois explicites. Parfois « transparents ». Parfois décidés par un fichier PAC qu’aucun serveur ne devrait consommer, mais surprise : quelqu’un a exporté des variables d’environnement dans /etc/environment et maintenant APT négocie avec un squid qui croit être un navigateur.

Modes de défaillance de proxy qui ressemblent à du DNS

Proxy en panne : le client ne peut pas se connecter, l’erreur remonte comme « impossible de résoudre l’hôte » selon l’outil et la configuration.
Proxy exige une authentification : APT peut échouer tôt. curl peut montrer un 407. Certains outils rapportent des erreurs génériques de résolution après réessais.
Le proxy résout le DNS lui-même : votre nœud ne résout jamais les noms externes ; le proxy le fait. Si le DNS du proxy casse, tous les nœuds ont « des problèmes DNS » simultanément.
Le proxy ne résout pas le DNS : il attend que le client résolve puis fasse un CONNECT par IP ou par nom. Si le DNS client est mauvais, le proxy est hors sujet.
Interception TLS : moins lié à la résolution, plus à « APT ne peut pas récupérer », mais on le diagnostique pareil parce qu’on se focalise sur la première ligne d’erreur.

Règles de gestion du proxy que j’applique sur les nœuds Proxmox

Soyez explicite. Si un nœud doit utiliser un proxy, configurez-le dans les fichiers de configuration APT, pas dans des profils shell aléatoires.
Limitez la portée. Utilisez no_proxy pour les sous-réseaux de cluster, les réseaux de stockage et les plages de gestion afin que le trafic interne ne passe pas par le proxy.
Testez les deux chemins. Ayez un test standard « direct » et un test standard « via proxy » pour isoler immédiatement le domaine de panne.

Erreurs courantes : symptôme → cause racine → correction

Voici la section où vous reconnaîtrez votre dernière panne.

1) Symbole : `apt update` dit « impossible de résoudre l’hôte », mais `dig` fonctionne

Cause racine : APT utilise un proxy (configuration APT), et le proxy échoue à résoudre ou à se connecter. Vos tests directs ont contourné le proxy.
Correction : Inspectez /etc/apt/apt.conf.d pour des directives proxy ; testez le proxy avec curl en utilisant --proxy. Réparez le proxy ou retirez la config proxy.

2) Symbole : le DNS fonctionne pour certains noms, échoue pour d’autres

Cause racine : DNS à horizon partagé, forward conditionnel mal configuré, ou résolveur qui bloque certains domaines/catégories.
Correction : Interrogez le même nom contre plusieurs résolveurs (dig @server), comparez les réponses, choisissez le bon résolveur pour le rôle réseau du nœud.

3) Symbole : tout est lent ; parfois ça marche après 30–60 secondes

Cause racine : le premier serveur de noms est mort/filtré, le second est sain ; les timeouts du résolveur gaspillent du temps avant basculement.
Correction : Supprimez ou dépriorisez les résolveurs morts ; assurez-vous que le pare-feu autorise UDP/53 et TCP/53 vers vos résolveurs.

4) Symbole : `curl -4` fonctionne ; `curl` sans option bloque ou échoue ; APT est instable

Cause racine : route IPv6 cassée ou filtrage IPv6 amont. Le client tente IPv6 en premier.
Correction : Réparez IPv6 proprement (routage/RA/pare-feu) ou désactivez IPv6 sur l’interface de gestion jusqu’au support complet. En contournement, forcez IPv4 pour APT.

5) Symbole : éditer `/etc/resolv.conf` « répare » jusqu’au reboot

Cause racine : resolv.conf est géré (systemd-resolved, client DHCP, hooks ifupdown). Votre modification manuelle est écrasée.
Correction : Configurez le DNS à l’intérieur de la couche correcte : config d’interface, paramètres systemd-resolved, ou options DHCP. Cessez de lutter contre l’automatisation.

6) Symbole : le nœud résout les noms internes correctement, les noms externes échouent

Cause racine : le résolveur interne n’a pas de récursion vers Internet, ou le pare-feu bloque le DNS sortant de ce segment, en attendant un proxy.
Correction : Utilisez des résolveurs qui fournissent la récursion pour les nœuds ayant besoin de mises à jour, ou fournissez un chemin d’egress contrôlé (proxy ou forwarder DNS) explicitement.

7) Symbole : seuls les nœuds Proxmox échouent, les VM vont bien

Cause racine : le réseau hôte diffère du réseau VM : ACL VLAN de gestion, vmbr0 mal tagué, règles de pare-feu hôte, ou mauvaise passerelle sur l’hôte.
Correction : Comparez le routage/DNS hôte et VM, vérifiez la config bridge/VLAN, validez la route par défaut et la reachabilité des serveurs DNS sur les interfaces vmbr.

8) Symbole : l’erreur apparaît après des changements de « durcissement »

Cause racine : règles de pare-feu bloquant UDP/53 sortant ou TCP/53, ou blocage d’ICMPv6 requis (ce qui casse PMTUD et la découverte de voisins, causant des comportements étranges).
Correction : Autorisez le trafic DNS nécessaire vers les résolveurs ; autorisez les types ICMP/ICMPv6 requis ; vérifiez avec tcpdump et des tests explicites.

Checklists / plan pas à pas

Checklist A : Plan de 10 minutes pour « obtenir les mises à jour »

Prouver l’egress par IP : curl -I https://1.1.1.1. Si cassé, réparez routage/pare-feu avant le DNS.
Prouver la résolution via libc : getent ahosts enterprise.proxmox.com. Si cassé, focalisez-vous sur la config du résolveur.
Prouver la reachabilité du serveur DNS : dig @<dns> enterprise.proxmox.com. Si timeouts, corrigez ACLs/routes vers le DNS.
Vérifier la source de vérité du résolveur : resolvectl status et ls -l /etc/resolv.conf. N’éditez pas la mauvaise couche.
Vérifier les paramètres proxy : grep -R Acquire:: /etc/apt/apt.conf.d et env | grep -i proxy.
Essayer de forcer IPv4 comme diagnostic : curl -4 -I https://enterprise.proxmox.com/.
Relancer apt-get update : confirmez que la correction tient, ce n’est pas un placebo.

Checklist B : Plan « faire tenir la correction » (après l’incident)

Choisir le modèle de propriété DNS correct : systemd-resolved + DNS d’interface, ou gestion classique de resolv.conf. Documentez-le.
Rendre explicites les serveurs DNS pour les réseaux de gestion statiques. Compter sur DHCP en datacenter est acceptable jusqu’à ce que ça casse.
Valider la posture IPv6 : soit la supporter bout en bout, soit la désactiver intentionnellement sur ce segment. Pas de demi-mesures.
Standardiser la config proxy : fichier proxy APT géré par la CM ; garder l’environnement shell propre pour les opérateurs.
Ajouter un contrôle santé nœud léger : vérifications périodiques DNS + reachabilité dépôt avec alertes claires sur la couche en échec.

Checklist C : Collecte de preuves pour escalade (quand ce n’est pas de votre faute)

Capturer la config résolveur : resolvectl status, /etc/resolv.conf, /etc/nsswitch.conf.
Capturer la preuve de requêtes DNS : sorties dig @dns host et extraits tcpdump.
Capturer les tables de routage : ip route, ip -6 route.
Capturer la config proxy : fichier proxy APT, variables d’environnement, et un test curl --proxy.
Noter les horodatages. Les équipes DNS aiment les horodatages parce que les logs existent. Les impressions n’en ont pas.

Trois mini-récits du monde de l’entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe a repris un petit cluster Proxmox avec un mélange de réseaux de gestion et d’invités sur quelques VLANs. Tout semblait propre : vmbr0 pour la gestion, vmbr1 pour les invités. Les mises à jour étaient « parfois instables », que tout le monde interprétait comme « Internet fait ce qu’il veut ». Personne n’aimait ça, mais personne n’en était propriétaire.

Pendant une montée de version planifiée, apt update a commencé à échouer avec « impossible de résoudre l’hôte » pour plusieurs dépôts. Un ingénieur a fait ce qu’on fait souvent : il a remplacé /etc/resolv.conf par des résolveurs publics et a poursuivi. Ça a marché. Pendant quelques heures. Puis l’automatisation de maintenance a redémarré les nœuds un par un et le problème est revenu à chaque reboot. Panique.

La mauvaise hypothèse était simple : ils pensaient que resolv.conf était la source d’autorité. Elle ne l’était pas. Le système utilisait systemd-resolved, et le DHCP sur vmbr0 injectait des serveurs DNS d’un relais de succursale qui perdait parfois son upstream. La « réparation » a été écrasée précisément quand la fiabilité comptait : pendant les reboots.

Une fois qu’ils ont cartographié la chaîne de résolveurs, la vraie correction était ennuyeuse : définir des résolveurs récursifs internes stables pour l’interface de gestion et arrêter de consommer le DNS fourni par DHCP sur ce VLAN. Puis documenter le modèle de propriété du résolveur dans le standard de build. La prochaine montée s’est passée en silence, ce qui est le plus grand compliment qu’on puisse faire à un SRE.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un projet sécurité a décidé « d’optimiser le DNS » en forçant toutes les requêtes serveur via un résolveur central filtrant pour standardiser la journalisation et bloquer des catégories. C’était présenté comme réduisant le risque et simplifiant les audits. Techniquement, c’était vrai.

Mais les nœuds Proxmox se sont retrouvés derrière un résolveur qui limitait le débit des rafales et appliquait des timeouts agressifs sous charge. Les nœuds PVE sont bavards pendant les fenêtres de maintenance : ils frappent les miroirs Debian, les dépôts Proxmox, parfois Ceph, plus les intégrations de monitoring et de sauvegarde. Le nouveau résolveur tenait en heures normales puis s’effondrait lors des vagues de patchs.

Le premier symptôme était « impossible de résoudre l’hôte » dans APT. Le second était pire : lenteurs UI sur pveproxy quand il tentait de résoudre des endpoints externes. Les ingénieurs « ont corrigé » en ajoutant un autre serveur de noms (public) comme fallback. Cela a créé une violation de politique et, surtout, de la nondéterminisme : parfois on utilisait le DNS interne, parfois on fuyait des requêtes à l’extérieur.

La correction finale n’était pas héroïque. Ils ont créé une couche de résolveurs dédiée pour les nœuds d’infrastructure, avec plus de capacité et des paramètres de timeout/retry ajustés, et ils ont attaché les réseaux de gestion à cette couche. Le résolveur filtrant est resté pour les postes utilisateurs. La leçon était douloureusement corporate : l’optimisation n’est pas gratuite ; elle déplace juste la facture vers un autre centre de coût.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre société avait une habitude presque démodée : chaque build de nœud Proxmox incluait un petit test « contrat de connectivité ». Il tournait après le provisionnement et quotidiennement. Il vérifiait trois choses : résoudre un nom connu avec le résolveur configuré, se connecter à une IP connue directement, et télécharger un petit fichier depuis l’origine du dépôt utilisée par cet environnement. Les résultats allaient vers le monitoring avec des étiquettes explicites : DNS, routage, ou repo/proxy.

Un mardi matin, plusieurs équipes ont commencé à se plaindre que leurs systèmes ne pouvaient plus atteindre des services externes. Le cluster Proxmox semblait sain. Les VM tournaient. Personne ne voulait toucher aux hyperviseurs.

Puis l’alerte a sonné : « Échec DNS sur le chemin résolveur VLAN de gestion ». Pas « apt cassé ». Pas « Proxmox ne peut pas mettre à jour ». Une défaillance DNS claire, sur plusieurs nœuds, avec horodatages et données last-known-good. L’équipe ops est allée au réseau (figurativement), a fourni des captures de paquets montrant des requêtes UDP/53 sans réponses, et le service DNS a été rétabli rapidement.

La pratique ennuyeuse n’a pas empêché la panne. Elle a empêché la deuxième panne : cinq ingénieurs passant une demi-journée à modifier des configs aléatoires sur des hyperviseurs de production parce qu’ils ne savaient pas quelle couche échouait.

FAQ

1) Pourquoi Proxmox affiche « impossible de résoudre l’hôte » lors de `apt update` ?

Parce qu’APT ne peut pas traduire le nom du dépôt en adresse IP via le chemin résolveur du nœud. Cela peut être une vraie panne DNS, des serveurs DNS inaccessibles, une préférence IPv6 cassée, ou une confusion liée au proxy.

2) Si `ping 8.8.8.8` fonctionne, cela prouve-t-il que le DNS est la source du problème ?

Non. Cela prouve l’egress IPv4 basique et le routage ICMP vers cette adresse. Le DNS peut toujours être cassé, bloqué ou mal configuré. De plus, ICMP fonctionnel ne prouve pas que TCP/443 fonctionne.

3) Si `dig` fonctionne mais APT échoue, que dois-je suspecter en premier ?

La configuration du proxy et les différences de préférence IPv6. Vérifiez /etc/apt/apt.conf.d pour des directives Acquire:: proxy, puis testez curl -4 vs le comportement par défaut.

4) Dois-je simplement éditer `/etc/resolv.conf` ?

Seulement si vous avez confirmé que ce fichier n’est pas géré par systemd-resolved ou des hooks DHCP. Si c’est un lien symbolique vers systemd-resolved, l’éditer est une illusion temporaire. Réparez le DNS dans la couche propriétaire correcte.

5) Comment IPv6 peut-il casser la résolution DNS ?

IPv6 en soi ne casse pas le DNS. Mais si votre réseau annonce IPv6 et que les clients le privilégient, les tentatives de connexion peuvent échouer ou bloquer, et des outils peuvent rapporter des erreurs confuses qui ressemblent à des problèmes de résolution.

6) Quel est le moyen le plus rapide de prouver que c’est un problème IPv6 ?

Relancez le même test en forçant IPv4 : curl -4 -I https://host. Si IPv4 forcé fonctionne de façon fiable mais que le réglage par défaut ne fonctionne pas, le routage ou le filtrage IPv6 est suspect.

7) Le clustering Proxmox (corosync) peut-il être affecté par des problèmes DNS ?

Corosync fonctionne généralement par configuration IP, mais les outils opérationnels, l’accès aux dépôts, les métriques, les sauvegardes et certaines intégrations dépendent d’une résolution de noms stable. Les problèmes DNS ne casseront pas toujours le clustering, mais ils casseront la maintenance, c’est-à-dire au pire moment.

8) Je suis derrière un proxy d’entreprise. Les nœuds Proxmox doivent-ils l’utiliser ?

Si la politique l’exige, oui — de manière explicite et cohérente. Configurez le proxy APT dans un fichier géré, maintenez no_proxy correct pour les réseaux de cluster et stockage, et testez la reachabilité du proxy dans le contrôle santé du nœud.

9) Pourquoi cela n’arrive-t-il qu’après un reboot ?

Parce que les paramètres DNS sont souvent injectés au boot par DHCP ou des services gérés. Votre modification manuelle est écrasée. Vérifiez la propriété via ls -l /etc/resolv.conf et resolvectl status.

10) Quand dois-je escalader vers l’équipe DNS/réseau ?

Quand vous pouvez démontrer : des requêtes quittent le nœud, le serveur DNS est injoignable ou ne répond pas, ou les logs de resolved montrent des basculements/comportement dégradé. Apportez des captures de paquets et des horodatages, pas des ressentis.

Conclusion : prochaines étapes pratiques

« Impossible de résoudre l’hôte » sur un nœud Proxmox est rarement un mystère. C’est un problème de workflow. Si vous prouvez le domaine de panne dans l’ordre — egress par IP, résolution libc, reachabilité du serveur DNS, préférence IPv6, puis comportement proxy — vous cesserez de traiter le DNS comme une croyance.

Prochaines étapes qui rapportent vraiment :

Standardisez la propriété du résolveur (systemd-resolved ou pas) et documentez-la dans le build du nœud.
Épinglez des serveurs DNS stables pour le réseau de gestion et assurez-vous que UDP/53 et TCP/53 sont explicitement autorisés.
Décidez de l’IPv6 de manière intentionnelle : le supporter bout en bout ou le désactiver sur le segment. Le demi-IPv6 est une dette opérationnelle qui porte intérêt.
Rendez l’usage du proxy explicite et testable. La config proxy APT ne doit pas être un jeu de piste.
Ajoutez un petit test de contrat de connectivité planifié pour détecter la dérive DNS/proxy/routage avant la nuit de patch.