Son las 02:17, tu ventana de despliegue se está cerrando y apt de repente se niega a descargar cualquier cosa. El error es casi insultante en su simplicidad: Could not resolve host. Sabes que la máquina tiene enlace. Puedes hacer ping a una IP. Aun así, cada nombre de host parece haber sido borrado del universo.
Aquí es donde importan los instintos de producción. No “intentes arreglos aleatorios” y definitivamente no reinicies como herramienta de diagnóstico. Haz el triaje de la resolución de nombres como lo harías con un incidente de almacenamiento: encuentra el límite, demuestra dónde falla y cambia una cosa a la vez.
Playbook de diagnóstico rápido
Este es el camino para “detener la hemorragia”. Está sesgado hacia la velocidad, no la elegancia. Intentas responder tres preguntas rápidamente:
- ¿Puede esta máquina alcanzar algún resolvedor en absoluto?
- ¿Está el resolvedor respondiendo correctamente?
- ¿Está la aplicación evitando tu resolvedor por peculiaridades de proxy/IPv6/NSS?
Primero: demuestra si DNS es el problema o solo lo primero que falla
- Comprueba la conectividad IP hacia algo estable (puerta de enlace, resolvedor, IP pública conocida si la política lo permite). Si la conectividad IP falla, depurar DNS es mera apariencia.
- Resuelve usando la ruta del sistema (
getent) y una herramienta directa (digoresolvectl). Si no coinciden, has encontrado la línea de fractura.
Segundo: localiza el resolvedor en uso y su upstream
- Lee /etc/resolv.conf y comprueba si es un stub (127.0.0.53) o servidores reales.
- Usa resolvectl para ver qué servidores DNS están realmente configurados por enlace y si DNSSEC/DoT están implicados.
Tercero: revisa el enrutamiento “invisible” de la aplicación: proxy y preferencia IPv6
- Proxy: valida variables de entorno y fragmentos de proxy de APT. Un proxy puede hacer que DNS parezca roto porque el proxy está realizando la resolución (o fallando en hacerlo).
- IPv6: si tu host obtiene registros AAAA pero no puede enrutar IPv6, verás tiempos de espera y fallos estilo “could not resolve host” dependiendo del cliente.
Si tienes prisa: empieza por las Tareas 1–6 abajo. Normalmente te dirán dónde cavar más profundo.
Qué significa realmente “Could not resolve host”
La frase aparece en múltiples clientes (curl, wget, git, a veces apt vía su pila HTTP). No es un único error. Es una familia de fallos que terminan con el mismo encogimiento de hombros: “Intenté convertir un nombre en una dirección y no obtuve ninguna”.
En Debian 13, las piezas móviles habituales son:
- resolución de nombres de glibc (NSS) vía
/etc/nsswitch.conf - /etc/resolv.conf (ya sea un archivo real o un enlace simbólico en el mundo de systemd)
- systemd-resolved (si está habilitado) y su escucha stub
- NetworkManager o systemd-networkd que alimentan a resolved con servidores DNS
- clientes VPN que hacen split-DNS, a veces mal
- configuración de proxy (variables de entorno, config de APT, archivos PAC corporativos)
- preferencia y políticas IPv6 (Happy Eyeballs ayuda, pero no te absuelve de v6 roto)
Un mantra confiable: “Could not resolve host” es el síntoma. Tu trabajo es identificar qué capa está mintiendo.
Broma #1: DNS es el único sistema distribuido donde olvidar un punto puede arruinar tu día y tu fin de semana.
Hechos interesantes y contexto histórico
Estos no son trivias por trivia. Cada uno explica por qué la resolución de nombres moderna en Linux se comporta como lo hace y por qué los “arreglos simples” pueden ser trampas.
/etc/hostsprecede a DNS. Los primeros sistemas ARPANET usaban un único archivo HOSTS.TXT distribuido centralmente; DNS reemplazó ese desastre de escalado con delegación.- La librería resolutora no es lo mismo que “DNS”. En Linux, NSS de glibc decide si consultar archivos, DNS, mDNS, LDAP, SSSD, etc. DNS es solo un módulo.
resolv.conffue diseñado para redes estáticas. Portátiles, DHCP, VPN split DNS y contenedores lo convirtieron en un archivo disputado donde varios demonios pelean—amistosamente o no.- systemd-resolved introdujo un stub local por defecto en muchas distribuciones. Esa entrada 127.0.0.53 no es “incorrecta”; es un reenviador local y caché—hasta que algo más alrededor se rompe.
- El cache negativo existe. Los resolvedores pueden cachear resultados “NXDOMAIN”, así que una falla transitoria upstream puede persistir como “este host no existe” por un tiempo.
- Los timeouts de DNS pueden parecer fallos de resolución. Muchos clientes mapean “tiempo de espera contactando DNS” a errores genéricos porque solo les importa que no obtuvieron una dirección.
- DNSSEC y DoT son compensaciones de fiabilidad. La validación y el cifrado añaden modos de fallo: desajuste de reloj, puerto 853 bloqueado o middleboxes que manejan mal EDNS0.
- IPv6 rompió muchas suposiciones. Doble pila significa que puedes “resolver con éxito” registros AAAA pero fallar en conectar si el enrutamiento v6 está medio configurado.
- Los proxies corporativos a veces resuelven nombres por ti. Tu cliente puede no hacer DNS en absoluto; entrega el hostname al proxy y espera. Eso cambia la ruta de depuración.
Árbol de decisión: DNS vs proxy vs IPv6 vs enrutamiento
Aquí está el modelo mental que te evita editar archivos aleatoriamente. Tu objetivo es encontrar la primera capa que se desvía del comportamiento esperado.
1) ¿Puedes alcanzar algo por IP?
Si no puedes hacer ping a tu puerta de enlace predeterminada o alcanzar una IP conocida, para. Arregla enlace/enrutamiento/firewall. DNS no es el incidente principal, es daño colateral.
2) ¿Funciona la ruta del resolvedor del sistema?
Usa getent ahosts porque ejerce la misma ruta que la mayoría de las aplicaciones usan (NSS). Si getent falla, tienes un problema de resolvedor a nivel sistema. Si getent funciona pero curl falla, estás mirando ajustes de proxy, anulación de DNS a nivel de aplicación, o comportamiento de conexión IPv6.
3) ¿Estás usando systemd-resolved y /etc/resolv.conf es honesto?
En muchas roturas, /etc/resolv.conf apunta a un stub que no está escuchando (resolved está deshabilitado), o apunta a resolvedores obsoletos proporcionados por DHCP que no puedes alcanzar (la VPN te movió). Es aburrido y común.
4) ¿Estás en un régimen de proxy?
A las redes corporativas les encantan los proxies. Algunos usan proxies explícitos configurados mediante variables de entorno; otros imponen proxies transparentes o PAC. Si APT tiene un proxy configurado pero el proxy es inalcanzable, puedes obtener errores engañosos que parecen DNS.
5) ¿IPv6 está creando un bucle “resolución exitosa, conexión fallida”?
Muchas herramientas resuelven AAAA y prueban IPv6 primero. Si DNS IPv6 funciona pero el enrutamiento IPv6 está roto, verás fallos lentos. Algunos clientes resumen eso como un fallo de resolución. Tu trabajo es separar “obtuve una dirección” de “puedo alcanzar la dirección”.
Tareas prácticas: comandos, salidas y decisiones
Estas son tareas reales que puedes ejecutar en Debian 13. Cada una incluye (a) el comando, (b) qué significa la salida típica, y (c) qué decisión tomas después. Hazlas en orden hasta que encuentres la divergencia.
Task 1: Confirmar la superficie del error (qué herramienta, qué 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.
Qué significa: APT no puede resolver el hostname del repositorio. Puede ser DNS, una configuración de proxy o una discrepancia del resolvedor.
Decisión: No edites nada todavía. Pasa a las comprobaciones de conectividad IP y del resolvedor del sistema.
Task 2: Verificar estado de interfaces y ruta por defecto
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
Qué significa: Tienes una dirección IPv4 y una ruta por defecto. Al menos en el papel, el tráfico saliente debería funcionar.
Decisión: Prueba la alcanzabilidad hacia la puerta de enlace y una IP conocida.
Task 3: Probar conectividad IP cruda (puerta de enlace, luego una IP conocida)
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
Qué significa: La ruta de red funciona hacia Internet por IP. Esto apunta fuertemente de vuelta a resolución de nombres o proxy.
Decisión: Comprueba el comportamiento del resolvedor del sistema con getent a continuación.
Task 4: Probar resolución a través de NSS (lo que la mayoría de apps usa)
cr0x@server:~$ getent ahosts deb.debian.org
Qué significa si está vacío: NSS no pudo producir direcciones. Eso es un problema del resolvedor a nivel sistema, no “APT siendo extraño”.
Decisión: Inspecciona /etc/nsswitch.conf y la configuración del resolvedor (/etc/resolv.conf, resolvectl).
Task 5: Inspeccionar orden de NSS (fuentes de resolución de hosts)
cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
Qué significa: El sistema comprueba /etc/hosts, luego mDNS, luego DNS. Es un predeterminado común en escritorios; en servidores puede ser una trampa si mDNS se porta mal.
Decisión: Si la resolución es lenta o errática, considera si mDNS está interfiriendo. Pero no cambies esto todavía—primero confirma si DNS es alcanzable.
Task 6: Comprobar identidad y contenido de /etc/resolv.conf
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
Qué significa: Estás usando el stub local de systemd en 127.0.0.53. Eso está bien si systemd-resolved está en funcionamiento y los servidores upstream están configurados correctamente.
Decisión: Verifica que resolved esté en ejecución y tenga servidores upstream. Si resolved está parado, este stub se convierte en un agujero negro.
Task 7: Comprobar estado de systemd-resolved y DNS upstream
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
Qué significa: resolved está activo y reenviando a 10.10.0.53/54. Sin DoT, DNSSEC no validando. Parece sensato.
Decisión: Ahora prueba consultas directamente contra el servidor DNS configurado para detectar firewall/VPN/split DNS.
Task 8: Consultar directamente al DNS upstream (omitir el 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
Qué significa: Tu servidor DNS upstream no es alcanzable (timeout). Podría ser enrutamiento, firewall o estás en la red equivocada para ese resolvedor (clásico fallo de split DNS de VPN).
Decisión: Comprueba si puedes alcanzar 10.10.0.53 en absoluto (ICMP puede estar bloqueado; prueba TCP/UDP 53). Valida VPN y enrutamiento.
Task 9: Probar alcanzabilidad al servidor DNS en puerto 53 (TCP y 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
Qué significa: Ambos intentos TCP y UDP fallan. Esto no es un problema de “error tipográfico de DNS”; es alcanzabilidad de red hacia el resolvedor.
Decisión: Arregla enrutamiento/VPN/firewall hacia el resolvedor, o cambia temporalmente a resolvedores alcanzables (si la política lo permite) para restaurar el servicio.
Task 10: Identificar quién configuró 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
Qué significa: systemd-networkd está proporcionando servidores DNS. Si esos servidores no son alcanzables desde este segmento de red, necesitas ajustar la configuración de networkd o el ámbito DHCP.
Decisión: Valida que los servidores DNS sean correctos para este VLAN/VPN. Si te mudaste de red recientemente, este es tu indicador humeante.
Task 11: Verificar configuración de proxy (variables de entorno)
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
Qué significa: Tu shell está configurada para usar un proxy. Herramientas como curl, wget y a veces git obedecerán esto.
Decisión: Si el proxy es obligatorio, prueba su alcanzabilidad. Si el proxy no es necesario en esta red, elimínalo y vuelve a probar la resolución.
Task 12: Comprobar configuración de proxy de APT (puede anular 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";
Qué significa: APT está fijado a un proxy independientemente de tus variables de entorno. Si ese proxy es inalcanzable, APT falla incluso si DNS está bien.
Decisión: Valida conectividad al proxy; si estás fuera de la red corporativa, deshabilita o condiciona esta configuración.
Task 13: Probar conectividad al proxy y ruta de resolución de nombres
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!
Qué significa: DNS está fallando para el nombre del proxy, pero la IP del proxy es alcanzable. Es una situación clásica donde “DNS está caído” es cierto, pero la mitigación más rápida es usar la IP del proxy temporalmente (si la política lo permite) o arreglar DNS.
Decisión: Elige mitigación: arreglar DNS upstream, o usar una entrada temporaria basada en IP para el proxy para restaurar instalaciones de paquetes durante el incidente.
Task 14: Detectar problemas de preferencia IPv6 (AAAA resuelve, conexión falla)
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
Qué significa: Este es un ejemplo de desajuste: getent devuelve direcciones, pero curl dice que no puede resolver. En incidentes reales, esto suele apuntar a configuración de proxy (curl usa proxy y falla allí), o a la configuración DNS de curl (raro) o a una discrepancia de NSS/plugins en entornos contenedorizados.
Decisión: Ejecuta curl con proxy deshabilitado y fuerza familia de direcciones para aislar.
Task 15: Forzar que curl omita proxy y fijar familia de direcciones
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
Qué significa: DNS está bien. IPv4 funciona. La conexión IPv6 agota el tiempo. Eso no es “resolución”, es enrutamiento o firewall para IPv6.
Decisión: O arregla el enrutamiento IPv6 correctamente o temporalmente desprioriza/deshabilita IPv6 en el cliente/sistema afectado mientras reparas la red.
Task 16: Comprobar rutas IPv6 y estado de RA
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
Qué significa: No tienes ruta por defecto IPv6. Puedes resolver AAAA, pero no puedes alcanzar Internet IPv6. Este es el peor tipo de “casi configurado”.
Decisión: Arregla RA/ruta por defecto, o deshabilita IPv6 en esa interfaz (o configura enrutamiento de política) según la intención de tu entorno.
Task 17: Comprobar si resolved escucha en el 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:*
Qué significa: El listener stub está presente. Si no ves nada escuchando en 127.0.0.53:53 mientras /etc/resolv.conf apunta allí, la resolución fallará para casi todo.
Decisión: Si no está escuchando, arranca/habilita resolved o repunta /etc/resolv.conf a resolvedores reales (con cuidado y preferiblemente temporalmente).
Task 18: Inspeccionar logs de resolved por fallos upstream y problemas DNSSEC/DoT
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.
Qué significa: Los resolvedores upstream no están respondiendo. Aquí es donde dejas de pinchar el cliente y empiezas a mirar ACLs de red, estado de VPN o salud del servicio DNS upstream.
Decisión: Escala a los propietarios de red/DNS con evidencias: IP del servidor, IPs de resolvedor, rango de tiempo y si UDP/TCP fallan.
Task 19: Validar la config del resolvedor desde la perspectiva de la aplicación
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)
Qué significa: En realidad está intentando 127.0.0.53, y no obtiene respuesta a tiempo. Es una confirmación sólida de problemas con el stub/resolved.
Decisión: Arregla resolved/alcanzabilidad upstream. No pierdas tiempo reescribiendo /etc/hosts a menos que necesites una solución quirúrgica temporal para un hostname.
Task 20: Mitigación temporal rápida (solo si la política lo permite)
Si necesitas paquetes ahora y tienes un resolvedor IP alcanzable, puedes reemplazar temporalmente el stub por servidores directos. Esto es táctico, no una “solución final”.
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
Qué significa: Has pasado por alto el stub local y los resolvedores corporativos. Esto puede violar la política corporativa o romper la resolución interna. Úsalo solo como puente durante un incidente.
Decisión: Tras el incidente, revierte y arregla el problema upstream real. Las soluciones permanentes y torpes se convierten en fallos futuros.
Errores comunes (síntoma → causa raíz → solución)
Esta sección es deliberadamente específica. Estos patrones se repiten porque son fáciles de crear y difíciles de detectar bajo presión.
1) Síntoma: /etc/resolv.conf muestra 127.0.0.53, pero nada se resuelve
Causa raíz: systemd-resolved está deshabilitado/detenido, o el listener stub no está enlazado por conflictos.
Solución: Habilita/inicia resolved y verifica que esté escuchando; o repunta /etc/resolv.conf a un resolvedor real. También busca un servicio DNS local competidor (dnsmasq, unbound) que esté ocupando el puerto 53.
2) Síntoma: dig funciona pero apt y curl fallan con “could not resolve host”
Causa raíz: Configuración de proxy. Tu prueba DNS con CLI es directa, pero la aplicación usa un proxy (config de proxy de APT o variables de entorno) y falla antes de DNS o delega la resolución al proxy.
Solución: Valida Acquire::http::Proxy y http_proxy/https_proxy. Prueba con proxy deshabilitado (--noproxy) para confirmar.
3) Síntoma: La resolución es lenta, intermitente y CPU inactiva; los logs muestran timeouts
Causa raíz: Resolvedores upstream inalcanzables por cambios de ruta de VPN, firewall o DNS DHCP erróneo. systemd-resolved cicla servidores y reintentos.
Solución: Confirma alcanzabilidad a servidores configurados con pruebas UDP/TCP 53. Corrige la lista de servidores DNS para la red en la que estás.
4) Síntoma: Existen registros AAAA; las conexiones cuelgan; a veces el error dice “could not resolve host”
Causa raíz: IPv6 está habilitado lo suficiente para preferirse pero no lo bastante para funcionar (sin ruta por defecto v6, firewall roto, RA mal configurada).
Solución: O arregla el enrutamiento IPv6 correctamente (preferido en redes reales), o fuerza IPv4 temporalmente para el cliente afectado o deshabilita IPv6 en la interfaz si no es compatible.
5) Síntoma: Nombres internos fallan, nombres externos funcionan (o viceversa)
Causa raíz: Split DNS y dominios de búsqueda. La VPN espera resolvedores corporativos para corp.example, pero estás usando resolvedores públicos; o tu dominio de búsqueda hace que nombres cortos se resuelvan incorrectamente.
Solución: Usa DNS por enlace y configuración de dominio de enrutamiento con systemd-resolved (~corp.example routing domains) o corrige la configuración DNS proporcionada por la VPN.
6) Síntoma: Solo un host es “inresoluble” y todos editan /etc/hosts
Causa raíz: Cache negativo obsoleto, DNS autoritativo mal configurado, o un corte reciente que no propagó. /etc/hosts “arregla” una máquina y crea deuda de mantenimiento.
Solución: Verifica TTLs y respuestas autoritativas. Vacía caches donde corresponda (resolvectl flush-caches) y arregla registros DNS en lugar de tallar excepciones en archivos hosts.
7) Síntoma: Un contenedor no puede resolver, el host sí
Causa raíz: El runtime del contenedor escribe su propio resolv.conf o usa un resolvedor diferente, a menudo bloqueado por la política de red.
Solución: Inspecciona /etc/resolv.conf del contenedor y las configuraciones DNS del runtime. Alinea con resolvedores alcanzables desde el host o usa un resolvedor interno dedicado accesible desde esa red.
8) Síntoma: DNS funciona justo después del reinicio, luego falla más tarde
Causa raíz: Carrera/sobrescritura entre servicios que escriben la configuración del resolvedor: cliente DHCP vs NetworkManager vs networkd vs scripts de VPN up/down.
Solución: Elige un único propietario de la pila de red por host. Elimina servicios competidores. Asegura que la configuración del resolvedor se gestione de forma consistente y monitorizada.
Broma #2: Si “arreglas” DNS hardcodeando IPs en /etc/hosts, felicidades—acabas de inventar drift de configuración con pasos extra.
Tres microhistorias corporativas desde la trinchera
Microhistoria 1: El outage causado por una suposición equivocada
Tenían una imagen estándar para servidores Debian: networkd, resolved y un perfil de hardening de seguridad. Un equipo creó un nuevo entorno en un segmento de centro de datos distinto y clonó la misma imagen. Todo arrancó. Los agentes de monitoring contactaron. Luego empezaron a fallar despliegues con “Could not resolve host”.
El on-call supuso “DNS debe estar caído” porque eso decía el error. Escalaron al equipo de DNS, que respondió (correctamente) que su servicio estaba sano y respondiendo consultas. Mientras tanto, el incidente continuó porque las actualizaciones de paquetes no podían proceder, las imágenes de contenedores no podían descargarse y la pipeline de despliegue se reintentó en un pequeño DDoS auto-infligido.
El problema real fue aburrido: la imagen tenía servidores DNS fijados a las IPs del resolvedor del segmento antiguo. Esas IPs eran alcanzables solo dentro del VLAN original; el nuevo segmento no podía enrutar hacia ellas por diseño. La suposición fue que “DNS es global”, que es verdadero filosóficamente y falso en la práctica. El DNS corporativo a menudo es por segmento por latencia, control y políticas.
Lo arreglaron obteniendo servidores DNS vía DHCP en ese entorno en lugar de hardcodearlos, y añadiendo una validación al arranque: si los servidores DNS configurados no son alcanzables en UDP/TCP 53, fallar la provisión temprano. Al día siguiente, todos recordaron que “resolve host” es medio nombrado y medio enrutar hacia el resolvedor.
Microhistoria 2: La optimización que salió mal
Un equipo de plataforma quería builds más rápidas. Habilitaron DNS sobre TLS en una flota porque DNS cifrado sonaba como una ganancia: privacidad, integridad y modernidad. También quedaba bonito en las revisiones de seguridad.
Dos semanas después, empezaron a ver fallos esporádicos en horas punta. No outages totales—peor. Algunos hosts tardaban 20–30 segundos en resolver ciertos nombres. Jobs de CI fallaban. Los desarrolladores abrían tickets diciendo “la red está encantada”. El servicio DNS en sí estaba bien, pero el camino hacia él no.
El culpable fue una política de firewall upstream que rate-limitaba o dejaba caer intermitentemente el puerto 853 cuando emergía cierto patrón de tráfico. UDP/53 estaba permitido y estable; TCP/853 estaba “permitido” pero no de forma fiable. Los clientes retrocedían de formas desordenadas: algunos reintentaban, otros bloqueaban, otros cachearon resultados negativos. La optimización mejoró postura de seguridad pero añadió una dependencia frágil en middleboxes que no lo soportaban bajo carga.
La solución pragmática fue hacer DoT condicional: habilitarlo solo en redes con soporte verificado, con monitorización que comparara latencia y tasas de fallo entre modos. También lo documentaron en los perfiles de build para que futuros equipos no heredaran “features de seguridad” que silenciosamente reducen la fiabilidad.
Microhistoria 3: La práctica aburrida que salvó el día
Un sistema cercano a finanzas (lee: nadie quiere downtime y nadie quiere cambios) corría Debian y tenía reglas de egress estrictas. Solo podían hablar con un pequeño conjunto de servicios internos: un proxy, DNS interno y unos pocos repositorios espejados dentro de la compañía.
El equipo hizo una cosa aburrida excepcionalmente bien: mantuvieron un runbook con salidas conocidas como buenas para el estado del resolvedor. No teoría. Capturas reales de un sistema sano: resolvectl status, ip route, getent hosts para dominios internos clave, además de qué servicio posee la configuración DNS en ese host.
Cuando “Could not resolve host” apareció durante una ventana de cambio, no debatieron. Compararon las salidas actuales con las buenas. El diff fue instantáneo: los servidores DNS habían cambiado a una lista genérica proporcionada por DHCP tras un reinicio de servicio de red. Esa lista era correcta para escritorios y errónea para servidores bloqueados. El runbook “aburrido” significó que no persiguieron al proxy, no culparon al DNS upstream y no perdieron 45 minutos discutiendo sobre IPv6.
Revirtieron la fuente de DNS, fijaron la propiedad de la red a networkd y añadieron una alerta: si los servidores DNS configurados se desvían del conjunto aprobado, alertar antes de que empiecen los errores de aplicación. No fue glamuroso, pero mantuvo el incidente bajo control.
Listas de verificación / plan paso a paso
Este es el plan que sigues cuando quieres resultados repetibles, no depuración heroica.
Checklist A: Triaje rápido (5–10 minutos)
- Captura el comando fallido y el hostname. ¿Repositorio APT? ¿Remoto Git? ¿Hostname del proxy? Escríbelo.
- Comprueba dirección IP y ruta por defecto.
ip -br addr,ip route. - Haz ping a la puerta de enlace y a una IP conocida. Si IP falla, para y arregla enrutamiento.
- Comprueba la ruta de resolución del sistema.
getent ahosts <host>. - Inspecciona /etc/resolv.conf. Stub vs servidores directos.
- Si hay stub, verifica resolved.
systemctl status systemd-resolved,resolvectl status,ss -lntu | grep :53. - Prueba resolvedores upstream directamente.
dig @server host A, luego pruebas de puerto si es necesario. - Comprueba proxies.
env | grep -i proxyy entradas de proxy en/etc/apt/apt.conf.d. - Verifica la realidad IPv6.
ip -6 route; pruebacurl -4vscurl -6.
Checklist B: Mitigaciones seguras (elige una, no las apiles ciegamente)
- Vaciar caches (útil cuando arreglaste upstream pero los clientes aún fallan):
cr0x@server:~$ sudo resolvectl flush-cachesDecisión: Si la resolución se recupera tras vaciar caches, investiga flaps upstream o eventos de cache negativo.
- Reiniciar resolved (útil cuando el stub está trabado, no cuando upstream es inalcanzable):
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: ens3Decisión: Si el reinicio ayuda, aún debes explicar: ¿por qué se trabó? Mira logs y alcanzabilidad upstream.
- Forzar IPv4 temporalmente para una operación crítica (útil cuando IPv6 está roto y necesitas un puente):
cr0x@server:~$ sudo apt-get -o Acquire::ForceIPv4=true update Hit:1 http://deb.debian.org/debian trixie InRelease Reading package lists... DoneDecisión: Si esto funciona, programa la remediación IPv6 adecuada o configura la política si IPv6 no está soportado.
- Omitir proxy temporalmente para endpoints conocidos (útil cuando la config de proxy está mal):
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 GMTDecisión: Si deshabilitarlo arregla, trata el proxy como el dominio del incidente. Reconfigura correctamente en lugar de dejarlo a medias.
Checklist C: Hacer que permanezca arreglado (endurecimiento post-incidente)
- Fuente única de la verdad para la config DNS. Elige NetworkManager o networkd. Elimina el otro si es posible.
- Monitoriza alcanzabilidad de resolvedores. Alerta cuando los servidores DNS configurados no respondan en UDP/TCP 53.
- Registra salidas conocidas buenas. Mantén una base para
resolvectl status, objetivo de/etc/resolv.confy config de proxy. - Documenta la propiedad del proxy. ¿Es variables de entorno, config de APT o política a nivel sistema? Hazlo explícito.
- Decide qué hacer con IPv6. ¿Soportado totalmente o deshabilitado explícitamente? “Medio funcionando” no es una estrategia.
Preguntas frecuentes
1) ¿Por qué ping a una IP funciona pero fallan los nombres?
Porque el enrutamiento está bien pero la resolución de nombres falla. Has demostrado conectividad L3; ahora aísla la ruta del resolvedor (getent, /etc/resolv.conf, resolvectl).
2) ¿Por qué dig funciona pero getent falla?
dig consulta DNS directamente. getent usa NSS, que puede consultar files, mDNS, SSSD u otras fuentes antes que DNS. Revisa /etc/nsswitch.conf y si el módulo DNS es alcanzable a través del resolvedor configurado.
3) ¿Es un bug tener 127.0.0.53 en /etc/resolv.conf?
No. Es el resolvedor stub de systemd-resolved. Es correcto cuando resolved está en funcionamiento y configurado. Es incorrecto cuando resolved está parado o los servidores upstream son inalcanzables y nadie lo nota.
4) ¿Cómo sé si el proxy está causando “Could not resolve host”?
Deshabilita el proxy para una prueba. Para curl: curl --noproxy '*'. Para APT: comenta temporalmente la config de proxy en /etc/apt/apt.conf.d (o ejecuta en un entorno controlado). Si el error desaparece, la ruta del proxy es tu culpable.
5) ¿Por qué forzar IPv4 lo arregla?
Porque la resolución DNS devuelve tanto registros A como AAAA, y el cliente puede preferir IPv6. Si el enrutamiento/firewall IPv6 está roto, las conexiones se estancan. Forzar IPv4 evita esa ruta. Es una mitigación, no una victoria moral.
6) ¿Debo hardcodear servidores DNS en /etc/resolv.conf?
Como mitigación temporal de incidente, a veces. Como solución a largo plazo, normalmente no—porque será sobrescrito por tu pila de red y rompe split DNS y nombres internos. Arregla la fuente de configuración real (DHCP, networkd, NetworkManager, cliente VPN).
7) ¿Por qué los nombres cortos internos se resuelven diferente en hosts distintos?
Dominios de búsqueda y split DNS. Un host puede tener search corp.example, otro no. Algunos entornos dependen de nombres cortos; otros no deberían. Estandariza y prefiere FQDNs para automatización.
8) ¿Cómo sé qué componente “posee” la configuración DNS en Debian 13?
Comprueba qué servicio de red está activo (NetworkManager vs systemd-networkd), luego usa resolvectl status y networkctl status. También inspecciona si /etc/resolv.conf es un symlink hacia el directorio de systemd-resolve.
9) ¿Cuál es la forma más segura de depurar sin romper producción?
Prefiere comandos de solo lectura primero (ip, getent, resolvectl, dig, ss, logs). Cuando cambies algo, cambia un control, regístralo y estate listo para revertir.
10) ¿Qué cita recuerdas durante estos incidentes?
La esperanza no es una estrategia.
— idea parafraseada que se repite a menudo en círculos de fiabilidad y operaciones.
Conclusión: siguientes pasos que puedes hacer hoy
Si solo recuerdas una cosa: separa resolución de alcanzabilidad, y separa la ruta del resolvedor del sistema del comportamiento de la aplicación. Eso detiene las ediciones inútiles y te lleva con rapidez al propietario correcto.
La próxima vez que “Could not resolve host” aparezca en Debian 13:
- Demuestra conectividad IP (
ip route, ping a la puerta de enlace, ping a IP conocida). - Demuestra resolución NSS (
getent ahosts) y compárala con DNS directo (dig). - Confirma propiedad del resolvedor (
/etc/resolv.confsymlink,resolvectl status). - Interroga proxies e IPv6, porque mienten de formas que parecen DNS.
- Aplica una mitigación única, restaura el servicio, luego arregla la causa upstream y quita la mitigación.
Haz la inversión aburrida: salidas base, monitorización de alcanzabilidad de resolvedores y una decisión sobre soporte IPv6. Así evitas que “Could not resolve host” se convierta en un personaje recurrente en tus informes de incidentes.