Servicio de diagnóstico y corrección de resolución DNS entre contenedores Docker y el host (bridge, overlay, systemd‑resolved)

Por Kevin Marcondes · Publicado el 31/10/2026 · 7 min de lectura

Patio portuario visto desde arriba con filas de contenedores coloridos — Vista aérea ordenada de contenedores — metáfora de contenedores Docker y redes Foto: Diego F. Parra / Pexels

¿Los contenedores no resuelven nombres, alternan entre timeouts y respuestas lentas o fallan al acceder a servicios internos? El servicio de diagnóstico y corrección de resolución DNS entre contenedores Docker y el host cubre bridge, overlay e integraciones con systemd‑resolved. Investigamos la cadena de resolución, identificamos causas y aplicamos correcciones seguras, con validación y pautas para evitar regresiones.

Qué recibe con este servicio

El objetivo es restablecer la resolución de nombres de forma predecible y estable. Intervenimos en Docker, en el host y en los encaminadores, siempre con un plan de validación.

El trabajo entrega un diagnóstico claro, correcciones aplicadas y recomendaciones para el mantenimiento futuro.

Mapa de la cadena de resolución (container → 127.0.0.11 → host → upstreams)
Hallazgos priorizados por impacto y riesgo
Correcciones en configuraciones de Docker, redes y resolvedor del host
Pull requests o parches para Compose/Swarm cuando aplique
Pruebas de validación y checklist de regresión

Qué síntomas indican fallo de resolución entre contenedores y host

Algunos síntomas apuntan directamente a problemas de DNS en Docker. Identificarlos temprano reduce el tiempo de indisponibilidad.

Si observa uno de los siguientes puntos, un diagnóstico dirigido a DNS suele acelerar la corrección.

getaddrinfo EAI_AGAIN, timeouts intermitentes o alta latencia en llamadas HTTP
Servicios internos resuelven vía VPN en el host, pero no dentro de los contenedores
Nombres como db, api o .local funcionan en una red y fallan en otra
Fallo de resolución en una red overlay entre tareas del Swarm
host.docker.internal no disponible en Linux o comportamiento inconsistente
La conexión cae en bridge tras cambios en el DNS del host

Cómo funciona la resolución de nombres en Docker (bridge, overlay y host)

En redes definidas por el usuario, Docker expone un resolvedor interno en 127.0.0.11. Éste resuelve nombres de contenedores en la misma red y reenvía dominios externos a los servidores del host.

En hosts Linux con systemd‑resolved, /etc/resolv.conf puede apuntar al stub 127.0.0.53. Esa diferencia entre el stub y los upstreams reales suele ser la causa de conflictos.

En overlay (Swarm), el DNS interno proporciona service discovery; la elección de search domains y las políticas de la VPN influyen en el resultado. IPv6 y split‑DNS requieren atención específica.

Causas comunes y líneas de corrección que aplicamos

Los problemas de DNS en Docker siguen patrones recurrentes. A continuación se muestran causas frecuentes y las directrices de corrección que aplicamos según el caso. Los cambios se validan antes de pasar a producción.

/etc/resolv.conf del host apunta a 127.0.0.53: alinear Docker con el archivo usando los upstreams reales del host o definir DNS explícitos
Search domains y ndots que generan intentos excesivos: ajustar opciones y el orden de resolución
VPN corporativa con split‑DNS: rutas y servidores por interfaz, con políticas consistentes para los contenedores
host.docker.internal en Linux: mapear vía host‑gateway o extra_hosts cuando sea necesario
Overlay con conflictos de nombres: normalizar nombres de servicios y aislar redes
Timeouts intermitentes bajo carga: estabilizar MTU/routing y evitar caídas de encaminadores

Escenario	Causa probable	Indicadores	Línea de corrección
Contenedores no resuelven dominios externos	Docker leyendo el stub 127.0.0.53 del host	Respuestas variables; ping en el host funciona	Hacer que Docker use los upstreams reales del resolvedor del host
Servicios internos de la VPN fallan solo en el contenedor	Split‑DNS por interfaz	En el host resuelve; en el contenedor, NXDOMAIN	Propagar servidores y rutas correctas al contenedor/red
Resolución lenta e intermitente	Search domains y ndots agresivos	Múltiples intentos antes de usar el FQDN	Ajustar opciones del resolver y el orden de búsqueda
Fallo entre tareas en Swarm	Conflicto de nombres o red overlay incorrecta	El servicio A no encuentra a B por nombre	Revisar nombres, redes y el DNS del cluster
Acceso al host por nombre especial indisponible	Sin mapeo host‑gateway	La aplicación intenta usar host.docker.internal	Agregar host‑gateway o una entrada estática

Etapas del trabajo: del diagnóstico a la validación

Seguimos una secuencia diseñada para minimizar riesgos y acelerar la identificación de la causa raíz. Todas las acciones se registran para permitir reproducibilidad.

La priorización considera impacto, facilidad de reversión y ventanas de cambio.

Triagem y reproducción del error en un entorno controlado
Inspección de redes (bridge/overlay), resolv.conf y nsswitch en host y contenedores
Recopilación de trazas y consultas DNS de extremo a extremo
Plan de corrección con rollback definido
Aplicación de cambios y validación funcional
Checklist final y recomendaciones de prevención

Cómo garantizamos estabilidad tras la corrección

La corrección de DNS debe sobrevivir reinicios, actualizaciones y cambios de red. Validamos funcionalmente y dejamos guardrails operativos.

Los puntos siguientes ayudan a mantener la previsibilidad a largo plazo.

Pruebas de resolución en CI/CD y health checks de dependencias
Estandarización de Compose/Stacks con dns, dns_search y extra_hosts cuando sea necesario
Documentación de procedimientos para cambios de DNS/VPN
Alertas para tiempos de resolución y picos de NXDOMAIN
Revisiones periódicas cuando se añaden nuevas sub‑redes o dominios internos

Cuánto tiempo lleva y qué necesitamos para empezar

El tiempo depende del alcance, número de redes e integraciones (VPN, split‑DNS, overlay). Casos simples suelen resolverse rápido; entornos complejos requieren más verificación.

Para iniciar se necesita acceso al host, a los archivos de Compose/Stacks y la posibilidad de ejecutar pruebas controladas.

Acceso al host y al Docker/Swarm para inspección
Archivos docker-compose.yml o especificaciones de servicios
Información sobre DNS internos/VPN y políticas de red
Ventana para pruebas y, si procede, para el cambio con rollback

Preguntas frecuentes

Cómo saber si el problema está en Docker o en systemd‑resolved del host?

Pruebe la resolución dentro del contenedor y en el host para el mismo dominio. Si funciona en el host y falla en el contenedor, el reenvío de Docker hacia los upstreams del host puede estar incorrecto. Inspeccione el resolv.conf en ambos lados y la presencia de 127.0.0.11 y 127.0.0.53.

host.docker.internal funciona en Linux?

En muchos entornos Linux no existe por defecto. Puede mapear el host vía host‑gateway o usar extra_hosts en Compose. Esto expone la IP del host al contenedor de forma predecible y evita depender de nombres especiales.

Por qué en una red overlay un servicio no encuentra a otro por nombre?

Suele deberse a conflicto de nombres, red incorrecta o servicio no expuesto en la misma red overlay. Revise los nombres de servicio, las redes asociadas y el DNS interno del cluster para garantizar que el nombre se resuelva al VIP o a la tarea correcta.

La VPN corporativa puede romper el DNS de los contenedores?

Sí, especialmente en escenarios de split‑DNS. El host recibe servidores por interfaz, pero los contenedores no. Es necesario propagar esos servidores a las redes de Docker o ajustar el resolvedor del host para que encamine correctamente.

Qué cambia al usar IPv6 con Docker y DNS?

Debe garantizar prefijos, enrutamiento y servidores DNS IPv6 válidos. Fallos comunes incluyen ausencia de rutas o de registros AAAA. Valide la resolución AAAA y la conectividad IPv6. Ajustes de MTU también pueden evitar timeouts aparentes de DNS.

¿Listo para resolver el DNS entre sus contenedores y el host?

Diagnostiquemos la cadena de resolución y apliquemos correcciones seguras para bridge, overlay y systemd‑resolved, con validación y rollback definidos.

Quiero un diagnóstico de DNS en Docker