Proxmox “no se pudo resolver el host”: flujo rápido de diagnóstico raíz para DNS/IPv6/proxy

enero 19, 2026 • febrero 3, 2026 • Lectura: 28 min • Views: 6

¿Te fue útil?

Nada hace que un nodo Proxmox se sienta más “producción” que el momento en que ejecutas apt update y responde: “no se pudo resolver el host”. De repente tu ventana de parches es una situación de rehenes, tu clúster HA está bien-pero-no-tanto, y estás frente a un problema de DNS que en realidad podría ser IPv6, enrutamiento o un proxy que solo existe en la presentación de alguien.

Este es un flujo de trabajo rápido y opinado para SREs y operadores que necesitan que el nodo se actualice ahora, pero que también quieren arreglar la causa real para que no vuelva en la próxima ventana de mantenimiento como una mala secuela.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando estás contra el reloj, no “pruebes cosas” al azar. Prueba dónde está el fallo. Esta guía está ordenada para maximizar la señal en tiempo mínimo.

Primero: ¿es DNS o es conectividad básica?

Comprueba si el nodo puede alcanzar una IP en Internet (sin DNS). Si no puede, deja de culpar al DNS. Arregla ruteo/firewall primero.
Comprueba si el nodo puede resolver un nombre usando su resolvedor configurado. Si no, es configuración de DNS, accesibilidad al servidor DNS o un problema del servicio resolvedor.
Comprueba si el nodo puede conectar al host del repositorio después de la resolución. Si el DNS funciona pero TCP falla, es proxy/firewall/MTU/TLS.

Segundo: Decide si IPv6 está en el radio de impacto

Revisa si la resolución de nombres devuelve registros AAAA y si el sistema los prefiere.
Prueba el ruteo IPv6. Una ruta por defecto IPv6 rota puede producir timeouts de resolvedor y síntomas de “no se pudo resolver el host”, según el cliente.
Forza temporalmente IPv4 como solución operativa rápida (luego arregla IPv6 correctamente).

Tercero: Proxies (explícitos, auto-config, “transparentes”) y particularidades de APT

Revisa variables de entorno y la configuración de proxy de APT. APT puede usar proxy aunque tu shell no lo haga.
Prueba salida directa vs a través del proxy. Haz una petición explícita con y sin proxy y compara.
Confirma el comportamiento DNS del proxy. Algunos proxies resuelven por ti; otros esperan que tu nodo resuelva.

Si sigues ese orden, normalmente encontrarás el cuello de botella en menos de diez minutos. Si no, pasarás una hora “arreglando DNS” rompiendo IPv6 y enseñándole al proxy a mentir.

Modelo mental: qué significa realmente “no se pudo resolver el host” en Proxmox

En Proxmox (basado en Debian), “no se pudo resolver el host” suele provenir de una de tres capas:

Capa de resolvedor: la pila de resolvedor de libc no puede convertir un nombre en una IP. Puede ser porque el servidor DNS configurado es inaccesible, el servicio resolvedor está mal configurado, o el nodo usa un resolvedor inesperado (systemd-resolved vs resolv.conf clásico).
Capa de transporte disfrazada de DNS: algunas herramientas informan un error de resolución cuando hacen timeout durante un intento de resolución que depende de la conectividad de red (especialmente con preferencia por IPv6 o rutas rotas).
Capa de proxy: el cliente cree que debe hablar con un proxy, el proxy está caído, requiere autenticación, o el comportamiento DNS del proxy no coincide con el diseño de la red.

Proxmox lo complica porque tu nodo también es un aparato de red. Tiene bridges, VLANs, a veces bonds, a veces múltiples uplinks, a veces redes de gestión con DNS especiales. Y ejecuta servicios críticos (corosync, pvedaemon, pveproxy) que no quieres interrumpir mientras “intentas un arreglo”.

Regla uno: no edites /etc/resolv.conf a lo loco y esperes que funcione. Prueba la ruta. Luego cambia lo mínimo.

Broma #1: DNS es el único sistema donde “funciona en mi portátil” es un modelo de amenaza.

Hechos interesantes y contexto histórico (sí, importa)

resolv.conf es anterior a la mayoría de tus herramientas. El formato del archivo viene de antiguas convenciones del resolvedor Unix y aún ancla muchas configuraciones modernas, incluso cuando es un enlace simbólico gestionado por otra cosa.
systemd-resolved cambió los modos de fallo por defecto. En lugar de un /etc/resolv.conf estático con resolvedores ascendentes directos, muchos sistemas apuntan a un stub local (a menudo 127.0.0.53) y el demonio hace el trabajo upstream.
APT tiene su propia personalidad de red. No se comporta exactamente como curl o wget en manejo de proxy, preferencia IPv6 o reporte de errores. Probar con apt importa.
El despliegue parcial de IPv6 es peor que no tener IPv6. Una red que anuncia IPv6 pero no puede enrutarlo de forma fiable creará problemas intermitentes y difíciles de depurar en resolución y conectividad.
Happy Eyeballs existe porque IPv6 rompió a la gente. Clientes modernos prueban IPv6 e IPv4 en paralelo para reducir latencia percibida. Pero no todas las herramientas lo implementan igual, y algunas se quedan atascadas.
DNS de horizonte dividido es común en empresas. El DNS interno devuelve respuestas distintas al DNS público. Los nodos Proxmox a menudo están en segmentos “semi-internos” donde el resolvedor equivocado da respuestas incorrectas.
El resolvedor de glibc es conservador. Puede intentar servidores en orden, aplicar timeouts y reintentos. Un único servidor muerto en la primera posición puede añadir grandes retrasos que parecen “DNS caído”.
Los clústeres Proxmox dependen más de la resolución de nombres de lo que crees. Puedes funcionar por IP, pero muchos scripts operativos, métricas, integraciones de backup y configuraciones de repositorios asumen nombres que funcionan consistentemente.
Auto-config de proxy (PAC/WPAD) es antiguo y aún causa outages. Que un cliente recoja una configuración de proxy que no debería usar es una trampa clásica de “funcionaba ayer, falla hoy”.

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Estos son movimientos reales de operador. Cada uno tiene: el comando, qué significa la salida y qué decisión tomar después. Ejecútalos en el nodo Proxmox (pve), no en tu portátil, porque tu portátil siempre miente.

Tarea 1: Confirma que el error es realmente resolución de nombres

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'

Significado: APT afirma que la resolución DNS falló para un host específico. Esto aún puede ser mala configuración de proxy o alcanzabilidad IPv6 que provoca que el camino del resolvedor haga timeout.

Decisión: Pasa a pruebas directas de resolución (getent, resolvectl, dig) antes de editar cualquier cosa.

Tarea 2: Comprueba qué resolvedores cree tener el sistema (ruta 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

Significado: El host usa systemd-resolved en modo stub, con servidores DNS ascendentes listados. Bien: tienes una fuente de la verdad.

Decisión: Si los servidores DNS no son los esperados, arregla la configuración de red (interfaces) o la configuración de systemd-resolved; no codifiques /etc/resolv.conf a menos que tengas la intención de saltarte resolved.

Tarea 3: Si resolvectl no está disponible o parece vacío, inspecciona /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

Significado: Es un symlink al archivo stub de systemd-resolved. Editarlo directamente es perder el tiempo; será sobrescrito.

Decisión: Usa resolvectl, la configuración de systemd-resolved, o ajusta la DNS de la interfaz en lugar de editar manualmente.

Tarea 4: Prueba la resolución a través de libc (esto es lo que usan la mayoría de las apps)

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

Significado: libc puede resolver el nombre. Si APT sigue fallando, sospecha proxy, interceptación TLS o timeouts DNS intermitentes en lugar de una falla total de DNS.

Decisión: Si getent tiene éxito, pasa a pruebas de conectividad. Si falla, céntrate en configuraciones del resolvedor y accesibilidad al servidor DNS.

Tarea 5: Prueba DNS crudo a un servidor de nombres específico (salta la lógica del resolvedor local)

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

Significado: El servidor DNS es accesible y responde. Si otros nombres fallan, no es “el DNS está caído”, es “DNS está selectivamente roto”. Problema distinto.

Decisión: Si la consulta hace timeout, prueba el ruteo hacia el servidor DNS y revisa reglas de firewall entre el nodo y el resolvedor.

Tarea 6: Verifica que puedes alcanzar el servidor DNS en absoluto (ruteo + ACLs)

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

Significado: Al menos ICMP funciona. No es prueba de que UDP/53 funcione, pero elimina la teoría de “sin ruta”.

Decisión: Si ping falla, comprueba la ruta por defecto, el etiquetado VLAN, la configuración del bridge y las políticas de firewall.

Tarea 7: Confirma las rutas por defecto (IPv4 e IPv6) para descartar “DNS por un camino inexistente”

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

Significado: Tienes rutas por defecto para ambas pilas. Si la ruta por defecto IPv6 está presente pero el upstream está roto, algunos clientes intentarán IPv6 primero y se quedarán estancados.

Decisión: Si IPv6 parece sospechoso (ruta existe pero upstream no), prueba la alcanzabilidad IPv6 explícitamente y decide si desactivar IPv6 temporalmente o arreglar RA/ruta.

Tarea 8: Prueba conectividad sin DNS (prueba de 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

Significado: Puedes alcanzar Internet y hacer TLS a una IP conocida. El 400 está bien; el camino de red funciona.

Decisión: Si esto falla, para: tienes un problema de egress/ruteo/firewall, no de DNS.

Tarea 9: Prueba DNS + TCP al host del repo (chequeo “end-to-end”)

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

Significado: DNS y HTTPS funcionan end-to-end. Si APT aún falla, probablemente sea la configuración de proxy de APT, APT adquiriendo IPv6 de forma distinta, o un timeout transitorio del resolvedor.

Decisión: Si curl funciona pero APT falla, compara configuraciones de proxy y fuerza IPv4 en APT como prueba.

Tarea 10: Comprueba configuración de proxy que afecta a APT (común en redes corporativas)

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/";

Significado: APT está forzado a usar un proxy, aunque tu entorno de shell no lo esté. Si ese proxy está caído o mal comportado, APT puede mostrar errores engañosos.

Decisión: Valida la conectividad del proxy, autenticación y comportamiento DNS. Si el entorno no debería usar proxy, elimina esta configuración deliberadamente (no solo comentes y olvides).

Tarea 11: Revisa variables de entorno de proxy (pueden sabotear curl/wget también)

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

Significado: Tu shell está proxied. Algunas herramientas respetan estas variables, otras no. El comportamiento mixto es cómo obtienes pruebas contradictorias.

Decisión: Para pruebas limpias, ejecuta comandos con proxy deshabilitado/habilitado explícitamente.

Tarea 12: Prueba la conectividad al proxy y si el proxy resuelve DNS por ti

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

Significado: El proxy es accesible y puede establecer un túnel para HTTPS. Si el proxy devuelve “could not resolve host” por sí mismo, entonces el DNS roto está en el proxy, no en tu nodo.

Decisión: Si el proxy funciona pero el acceso directo falla, tu red requiere egress vía proxy. Si el acceso directo funciona pero el proxy falla, eliminar la dependencia del proxy para nodos si la política lo permite.

Tarea 13: Forzar IPv4 en una sola prueba para aislar problemas de preferencia 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

Significado: La ruta IPv4 está bien. Si el curl sin -4 cuelga o falla, IPv6 probablemente está roto o filtrado.

Decisión: Arregla el ruteo IPv6 o desactiva IPv6 en el nodo/red de gestión hasta que esté soportado de extremo a extremo.

Tarea 14: Inspecciona la configuración NSS (raro, pero letal cuando está mal)

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

Significado: La resolución de nombres usa /etc/hosts luego DNS. Si esta línea está rara (falta dns, o incluye módulos rotos), obtendrás fallos extraños.

Decisión: Mantén files dns a menos que tengas una razón muy buena para ser creativo.

Tarea 15: Revisa /etc/hosts por autolesiones

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

Significado: Esto es sensato: localhost mapea a 127.0.0.1 solamente; la IP de gestión del nodo mapea a su hostname. Si mapeas nombres externos aquí, mereces el outage que obtienes.

Decisión: Pinnea solo lo imprescindible (normalmente el propio nombre del nodo). Usa DNS para todo lo demás.

Tarea 16: Captura paquetes DNS (cuando necesitas pruebas, no opiniones)

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

Significado: Puedes ver consultas y respuestas. Aquí: el registro A devuelve resultado, AAAA no (tal vez NODATA). Eso no es inherentemente erróneo.

Decisión: Si ves consultas saliendo pero sin respuestas, es problema de camino/ACL. Si ves respuestas pero las apps aún fallan, revisa selección de resolvedor, caché o comportamiento de proxy.

Tarea 17: Revisa la salud y 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.

Significado: Resolved está cambiando servidores o degradando el transporte. Eso es una pista fuerte de que tus servidores DNS son inestables o están bloqueados para TCP/53/EDNS0.

Decisión: Escala al equipo de infraestructura DNS o ajusta qué resolvedores usa el nodo (prefiere resolvedores locales y estables).

Tarea 18: Valida la configuración de repositorios de Proxmox (porque “no se pudo resolver el host” a veces significa “host incorrecto”)

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

Significado: El host del repo es exactamente lo que APT está intentando resolver. Si copiaste una configuración de una wiki o de una build antigua, podrías estar apuntando a un hostname bloqueado, retirado o solo accesible vía proxy.

Decisión: Confirma que estás usando el repo correcto según tu estado de suscripción y política de red. No “arregles DNS” para alcanzar un repo al que no tienes permiso.

Pila DNS en Proxmox: resolv.conf, systemd-resolved y las trampas habituales

La mayoría de despliegues Proxmox son básicamente Debian con opiniones. Debian te da opciones para resolución de nombres: resolv.conf clásico o systemd-resolved como resolvedor local stub. Los nodos Proxmox a menudo se configuran a través de /etc/network/interfaces (ifupdown2) y a veces heredan DNS desde DHCP, a veces desde configuración estática.

Sabe qué ruta de resolvedor tienes

El indicio más rápido es: ¿qué hay en /etc/resolv.conf?

Si apunta a 127.0.0.53 (stub), estás en systemd-resolved y los resolvedores ascendentes se controlan en otro lugar.
Si contiene entradas nameserver 10.x.x.x directamente, probablemente estés en gestión clásica de resolv.conf (o resolved está en modo “foreign”).
Si se reescribe en cada reinicio, probablemente tengas un cliente DHCP, network manager o hooks de ifupdown que lo gestionan.

Los operadores se queman porque “arreglan” DNS editando resolv.conf, funciona 20 minutos y luego la pila de red lo sobrescribe. La siguiente ventana de parches se convierte en un festival de déjà vu.

Prefiere fuentes de resolvedor estables para nodos

En entornos empresariales, los mejores servidores DNS para nodos Proxmox suelen ser:

Resolvedores recursivos locales diseñados para infraestructura (a menudo internos), con monitorización y redundancia.
Resolvedores alcanzables en la VLAN de gestión con reglas de firewall explícitas.

Los peores servidores DNS para nodos Proxmox suelen ser:

Resolvedores de consumidores aleatorios accesibles “algunas veces” a través de rutas NAT.
DNS de oficinas remotas que desaparecen durante eventos WAN.
Cualquier cosa que dependa de portales cautivos, checks de postura de endpoint o autenticación web “útil”.

Comportamiento de timeout: un servidor muerto puede arruinar tu día

El resolvedor de libc normalmente intenta servidores en orden, con timeouts y reintentos. Si tu primer nameserver está muerto y el segundo está sano, la resolución seguirá siendo lenta y puede parecer que falla bajo carga.

Si ves largas pausas en apt update antes de que falle, sospecha timeouts en lugar de un NXDOMAIN limpio. Eso es ruteo, firewall o un resolvedor muerto, no una falta de ortografía.

Regla de cita

La esperanza no es una estrategia. — cita frecuente en cultura de operaciones (idea parafraseada)

Modos de fallo de IPv6 que se hacen pasar por DNS

IPv6 no es el villano. El villano es IPv6 a medias: cuando el nodo obtiene una dirección IPv6 y ruta por defecto (vía RA), pero el enrutamiento upstream, firewall o proxy no soportan realmente tráfico IPv6 saliente.

Así es como esto se convierte en un problema de “no se pudo resolver el host”:

Tu resolvedor devuelve A y AAAA.
El cliente prefiere AAAA (IPv6) o lo intenta primero.
El intento de conexión se queda colgado o falla.
La aplicación reporta un fallo genérico. Algunas apps culpan al DNS porque la resolución estuvo involucrada.

Patrones que claman “IPv6 te está mintiendo”

getent ahosts devuelve entradas IPv6 (AAAA) y IPv4, pero solo funcionan conexiones IPv4.
curl -4 funciona; curl sin opción es lento o falla.
Tienes ruta por defecto IPv6 pero sin conectividad IPv6 estable upstream.

Qué hacer al respecto

En un mundo perfecto, arreglas IPv6 correctamente: RA correcta, enrutamiento correcto, firewall correcto, DNS correcto. En el mundo real, también necesitas una solución operativa segura. Dos enfoques pragmáticos:

Forzar IPv4 para APT durante una ventana de outage (solución a corto plazo).
Deshabilitar IPv6 en la interfaz de gestión si tu organización no lo soporta aún (limpieza a medio plazo).

Sé disciplinado: si deshabilitas IPv6, documentalo y registra el trabajo para reactivarlo cuando la red esté lista. “Temporal” es cómo terminas con configuración heredada en 2035 y un equipo que cree que IPv6 está maldito.

Broma #2: IPv6 es genial—hasta que alguien lo despliega “como concepto” en lugar de como red.

Proxy corporativo y modos de fallo de proxy “transparente”

Los nodos Proxmox son servidores. Pero a menudo viven en redes diseñadas para endpoints. Ahí es donde aparecen proxies. A veces explícitos. A veces “transparentes”. A veces decididos por un archivo PAC que ningún servidor debería consumir, pero sorpresa: alguien exportó variables de entorno en /etc/environment y ahora APT negocia con una caja squid que cree que es un navegador de RRHH.

Modos de fallo de proxy que parecen DNS

Proxy caído: el cliente falla al conectar, el error puede escalar como “no se pudo resolver el host” según la herramienta y configuración.
Proxy requiere autenticación: APT puede fallar temprano. curl puede mostrar un 407. Algunas herramientas reportan errores genéricos de resolución tras reintentos.
El proxy resuelve DNS por sí mismo: tu nodo nunca resuelve nombres externos; lo hace el proxy. Si el DNS del proxy se rompe, todos los nodos “tienen problemas DNS” simultáneamente.
El proxy no resuelve DNS: espera que el cliente resuelva y luego CONNECT por IP o por hostname. Si el DNS del cliente está mal, el proxy es irrelevante.
Intercepción TLS: menos sobre resolución, más sobre “APT no puede descargar”, pero se diagnostica igual porque los operadores se fijan en la primera línea de error.

Reglas de manejo de proxy que aplico en nodos Proxmox

Sé explícito. Si un nodo debe usar proxy, configúralo en archivos de configuración de APT, no en perfiles aleatorios de shell.
Limita el alcance. Usa no_proxy para subredes de clúster, redes de almacenamiento y rangos de gestión para que el tráfico interno no haga hairpin a través del proxy.
Prueba ambos caminos. Ten una prueba estándar “directa” y una “vía proxy” para aislar rápidamente el dominio del fallo.

Errores comunes: síntoma → causa raíz → solución

Esta es la sección donde reconoces tu último outage.

1) Síntoma: `apt update` dice “no se pudo resolver el host”, pero `dig` funciona

Causa raíz: APT usa un proxy (configuración de APT), y el proxy está fallando en resolver o conectar. Tus pruebas directas de DNS lo eludieron.
Solución: Inspecciona /etc/apt/apt.conf.d por directivas de proxy; prueba el proxy con curl usando --proxy. Arregla el proxy o elimina la configuración de proxy.

2) Síntoma: DNS funciona para algunos nombres, falla para otros

Causa raíz: DNS de horizonte dividido, configuración de reenvío condicional o un resolvedor que bloquea ciertos dominios/categorías.
Solución: Consulta el mismo nombre contra múltiples resolvedores (dig @server), compara respuestas y elige el resolvedor correcto para el rol de red del nodo.

3) Síntoma: Todo es lento; a veces funciona después de 30–60 segundos

Causa raíz: el primer nameserver está muerto/filtrado, el segundo está bien; los timeouts del resolvedor desperdician tiempo antes del failover.
Solución: Elimina o deprioriza resolvedores muertos; asegúrate de que el firewall permita UDP/53 y TCP/53 a tus resolvedores.

4) Síntoma: `curl -4` funciona; `curl` sin opción cuelga o falla; APT es inestable

Causa raíz: ruta IPv6 rota o filtrado upstream IPv6. El cliente intenta IPv6 primero.
Solución: Arregla IPv6 correctamente (ruteo/RA/firewall) o desactiva IPv6 en la interfaz de gestión hasta que esté soportado. Como workaround, fuerza IPv4 para APT.

5) Síntoma: Editar `/etc/resolv.conf` “lo arregla” hasta el reinicio

Causa raíz: resolv.conf está gestionado (systemd-resolved, cliente DHCP, hooks ifupdown). Tu edición manual se sobrescribe.
Solución: Configura DNS en la capa correcta: configuración de interfaz, ajustes de systemd-resolved o opciones DHCP. Deja de pelear con la automatización.

6) Síntoma: El nodo resuelve nombres internos bien, nombres externos fallan

Causa raíz: el resolvedor interno carece de recursión al Internet, o el firewall bloquea DNS saliente desde ese segmento, esperando un proxy.
Solución: Usa resolvedores que provean recursión para nodos que necesitan updates, o proporciona una ruta de egress controlada (proxy o reenviador DNS) explícita.

7) Síntoma: Solo fallan nodos Proxmox, las VM funcionan

Causa raíz: la red del host difiere de la red de VM: ACLs de VLAN de gestión, vmbr0 con VLAN mal etiquetada, reglas de firewall en host, o gateway incorrecto en el host.
Solución: Compara ruteo/DNS entre host y VM, revisa configuración de bridge/VLAN, valida la ruta por defecto del host y accesibilidad a servidores DNS en interfaces vmbr.

8) Síntoma: El error aparece después de cambios de “endurecimiento”

Causa raíz: reglas de firewall bloqueando UDP/53 y TCP/53 salientes, o bloqueando ICMPv6 necesario (que rompe PMTUD y descubrimiento de vecinos, provocando rarezas).
Solución: Permite el tráfico DNS necesario hacia los resolvedores; permite los tipos ICMP/ICMPv6 requeridos; verifica con tcpdump y pruebas explícitas.

Listas de verificación / plan paso a paso

Checklist A: El plan de 10 minutos para “poner actualizaciones funcionando”

Prueba egress por IP: curl -I https://1.1.1.1. Si está roto, arregla ruteo/firewall antes de DNS.
Prueba resolución libc: getent ahosts enterprise.proxmox.com. Si falla, céntrate en configuración del resolvedor.
Prueba alcanzabilidad del servidor DNS: dig @<dns> enterprise.proxmox.com. Si hay timeouts, arregla ACLs/rutas hacia DNS.
Revisa la fuente de la verdad del resolvedor: resolvectl status y ls -l /etc/resolv.conf. No edites la capa equivocada.
Revisa configuración de proxy: grep -R Acquire:: /etc/apt/apt.conf.d y env | grep -i proxy.
Prueba forzar IPv4 como diagnóstico: curl -4 -I https://enterprise.proxmox.com/.
Vuelve a ejecutar apt-get update: confirma que la solución es real, no un placebo.

Checklist B: El plan para “hacer que se quede arreglado” (después del outage)

Elige el modelo de propiedad del DNS: systemd-resolved + DNS por interfaz, o gestión clásica de resolv.conf. Documentalo.
Haz explícitos los servidores DNS para redes de gestión estáticas. Depender de DHCP en un centro de datos está bien hasta que no lo esté.
Valida la postura IPv6: o lo soportas de extremo a extremo o lo desactivas intencionalmente en ese segmento. Sin medias tintas.
Estandariza la configuración de proxy: archivo de proxy de APT gestionado por CM; mantén el entorno shell limpio para operadores.
Añade una verificación ligera de salud del nodo: comprobaciones periódicas de DNS + alcanzabilidad de repositorio con alertas claras sobre qué capa falló.

Checklist C: Recolección de evidencias para escalado (cuando no es tu culpa)

Captura la configuración del resolvedor: resolvectl status, /etc/resolv.conf, /etc/nsswitch.conf.
Captura prueba de consultas DNS: salidas de dig @dns host y fragmentos de tcpdump.
Captura tablas de rutas: ip route, ip -6 route.
Captura configuración de proxy: archivo proxy de APT, variables de entorno y una prueba curl --proxy.
Anota timestamps. A los equipos de DNS les encantan los timestamps porque hay logs. Las sensaciones no.

Tres mini-historias del mundo corporativo desde el campo

Mini-historia 1: El incidente causado por una suposición equivocada

Un equipo heredó un pequeño clúster Proxmox con mezcla de redes de gestión e invitadas cruzando un par de VLANs. Todo parecía ordenado: vmbr0 para gestión, vmbr1 para invitados. Las actualizaciones eran “a veces inestables”, que todos interpretaron como “Internet es Internet”. Nadie lo quería, pero nadie lo poseía.

Durante una actualización planificada, apt update empezó a fallar con “no se pudo resolver el host” para múltiples repositorios. Un ingeniero hizo lo estándar: reemplazó /etc/resolv.conf por resolvers públicos y siguió. Funcionó. Por unas horas. Luego la automatización de mantenimiento reinició nodos uno por uno y el problema volvió en cada reinicio. Pánico.

La suposición equivocada fue simple: asumieron que resolv.conf era la autoridad. No lo era. El sistema usaba systemd-resolved, y DHCP en vmbr0 inyectaba servidores DNS desde un relay de oficina remota que perdía upstream intermitentemente. El “arreglo” fue sobrescrito exactamente cuando la fiabilidad importaba: durante reinicios.

Una vez mapearon la cadena de resolvedores, la solución real fue aburrida: fijar resolvedores recursivos internos estables para la interfaz de gestión y dejar de consumir DNS proporcionado por DHCP en esa VLAN. Luego documentaron el modelo de propiedad del resolvedor en el estándar de build. La siguiente actualización fue tranquila, que es el mayor cumplido que puedes dar a un SRE.

Mini-historia 2: La optimización que salió mal

Un proyecto de seguridad decidió “optimizar DNS” forzando todas las consultas DNS de servidores a través de un resolvedor central filtrante para estandarizar logging y bloquear categorías. Fue presentado como reducción de riesgo y simplificación de auditoría. Técnicamente lo hizo.

Pero los nodos Proxmox ahora estaban detrás de un resolvedor que rate-limitaba picos y tenía timeouts agresivos bajo carga. Los nodos PVE son verbosos en ventanas de mantenimiento: golpean mirrors Debian, repositorios Proxmox, a veces repos Ceph, además de endpoints de monitorización y backup. El nuevo resolvedor funcionó en horas normales y se desplomó durante oleadas de parches.

El primer síntoma fue “no se pudo resolver el host” en APT. El segundo fue peor: cargas lentas de la UI en pveproxy cuando intentaba resolver endpoints externos para ciertas integraciones. Los ingenieros “arreglaron” añadiendo otro nameserver (un resolver público) como fallback. Esto creó violaciones de política y, más importante, nondeterminismo: a veces se usaba DNS interno, otras veces se filtraban consultas externamente.

La solución eventual no fue heroica. Crearon una capa de resolvedores dedicada para nodos de infraestructura con mayor capacidad y ajustaron timeouts/reintentos, y fijaron las redes de gestión a ella. El resolvedor filtrante siguió existiendo para endpoints y servidores generales. La lección fue dolorosamente corporativa: la optimización no es gratis; solo mueve la factura a otro centro de coste.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra compañía tenía la costumbre casi anticuada: cada build de nodo Proxmox incluía una pequeña prueba de “contrato de conectividad”. Se ejecutaba después del provisioning y diariamente. Comprobaba tres cosas: resolver un hostname conocido usando el resolvedor configurado, conectar a una IP conocida directamente y descargar un archivo pequeño desde el origen del repo usado por ese entorno. Los resultados iban a monitorización con etiquetas explícitas: DNS, ruteo o repo/proxy.

Un martes por la mañana, varios equipos empezaron a quejarse de que sus sistemas no podían alcanzar servicios externos. El clúster Proxmox parecía sano. Las VM corrían. Nadie quería tocar los hypervisors.

Entonces saltó la alerta: “Fallo DNS en la ruta del resolvedor de la VLAN de gestión”. No “apt roto”. No “Proxmox no puede actualizar”. Un fallo DNS limpio, en nodos, con timestamps y datos de último conocido bueno. El equipo de ops fue directo al equipo de red, entregó capturas de paquetes mostrando consultas UDP/53 sin respuesta y restauraron el servicio DNS rápido.

La práctica aburrida no evitó el outage. Evitó el segundo outage: el de cinco ingenieros gastando medio día cambiando configuraciones al azar en hypervisors de producción porque no sabían qué capa fallaba.

Preguntas frecuentes

1) ¿Por qué Proxmox muestra “no se pudo resolver el host” durante `apt update`?

Porque APT no puede traducir el hostname del repositorio a una IP usando la ruta de resolvedor del nodo. Eso puede ser una falla real de DNS, servidores DNS inaccesibles, preferencia IPv6 rota o confusión relacionada con proxy.

2) Si `ping 8.8.8.8` funciona, ¿prueba que el problema es DNS?

No. Prueba egress IPv4 básico y ruteo para ICMP a esa dirección. DNS aún puede estar roto, bloqueado o mal configurado. Además, que ICMP funcione no prueba que TCP/443 funcione.

3) Si `dig` funciona pero APT falla, ¿qué debo sospechar primero?

Configuración de proxy y diferencias en preferencia IPv6. Revisa /etc/apt/apt.conf.d por directivas Acquire:: de proxy, luego prueba curl -4 frente al comportamiento por defecto.

4) ¿Debería simplemente editar `/etc/resolv.conf`?

Sólo si confirmaste que no está gestionado por systemd-resolved o hooks DHCP. Si es un symlink a systemd-resolved, editarlo es una ilusión temporal. Arregla DNS en la capa correcta de propiedad.

5) ¿Cómo puede IPv6 romper la resolución DNS?

IPv6 en sí no rompe DNS. Pero si tu red anuncia IPv6 y los clientes lo prefieren, los intentos de conexión pueden fallar o quedarse en espera, y las herramientas pueden reportar errores confusos que parecen problemas de resolución.

6) ¿Cuál es la forma más rápida de demostrar que es un problema de IPv6?

Ejecuta la misma prueba forzando IPv4: curl -4 -I https://host. Si IPv4 forzado funciona pero el modo por defecto no, el ruteo o filtrado IPv6 es sospechoso.

7) ¿Puede el clustering de Proxmox (corosync) verse afectado por problemas DNS?

Corosync normalmente corre por configuración IP, pero herramientas operativas, acceso a repositorios, métricas, backups y algunas integraciones dependen de resolución estable de nombres. Los problemas DNS no siempre rompen el clustering, pero sí rompen el mantenimiento, que es cuando menos quieres sorpresas.

8) Estoy detrás de un proxy corporativo. ¿Deben usarlo los nodos Proxmox?

Si la política lo exige, sí—explícita y consistentemente. Configura proxy de APT en un archivo gestionado, mantén no_proxy correcto para clúster y redes de almacenamiento, y prueba la alcanzabilidad del proxy como parte de las comprobaciones de salud del nodo.

9) ¿Por qué esto ocurre solo después de reiniciar?

Porque la configuración DNS suele inyectarse en el arranque por DHCP o servicios gestionados. Tu arreglo manual se sobrescribe. Confirma gestión con ls -l /etc/resolv.conf y resolvectl status.

10) ¿Cuándo debo escalar al equipo de DNS/red?

Cuando puedas demostrar: consultas salen del nodo, el servidor DNS es inaccesible o no responde, o los logs de resolved muestran cambios/degradación. Lleva capturas de paquetes y timestamps, no interpretaciones.

Conclusión: próximos pasos prácticos

“No se pudo resolver el host” en un nodo Proxmox rara vez es un misterio. Es un problema de flujo de trabajo. Si pruebas el dominio de fallo en orden—egress por IP, resolución libc, alcanzabilidad del servidor DNS, preferencia IPv6 y luego comportamiento de proxy—dejarás de tratar el DNS como folclore.

Próximos pasos que realmente rinden:

Estandariza la propiedad del resolvedor (usar o no systemd-resolved) y documentalo en tu build de nodo.
Fija servidores DNS estables para la red de gestión y asegúrate de permitir UDP/53 y TCP/53 explícitamente.
Decide sobre IPv6 intencionalmente: soportarlo de extremo a extremo o desactivarlo en el segmento. IPv6 a medias es deuda operativa con intereses.
Haz explícito el uso de proxy y que sea testeable. La configuración de proxy de APT no debe ser una búsqueda del tesoro.
Añade una pequeña verificación programada de conectividad para detectar deriva en DNS/proxy/ruteo antes de la noche de parches.