¿Por qué la resolución de DNS funciona en el host, pero falla dentro de un contenedor?
El DNS del host puede funcionar mientras el DNS del contenedor falla porque el contenedor utiliza una ruta de resolución, un espacio de nombres, una ruta de firewall o un estado de reenvío de Docker diferentes.
En un servidor doméstico, el host puede consultar directamente un router, Pi-hole o un resolvedor de VPN, mientras que un contenedor conectado a una red puente envía las solicitudes mediante el resolvedor integrado de Docker o un archivo resolv.conf copiado. El diagnóstico más rápido prueba primero una dirección IP y, después, consulta explícitamente cada resolvedor desde el contenedor que falla, para no confundir un fallo de DNS con un problema general de conectividad saliente.
Separa el fallo de DNS de un fallo general de red
Desde el contenedor que falla, prueba una IP externa conocida y la dirección IP del servidor DNS previsto antes de probar cualquier nombre de host. Registra las rutas, la pérdida de paquetes y si los puertos TCP y UDP 53 son accesibles.
Un caso con un contenedor de Manjaro demuestra la situación contraria: el tráfico IP directo también fallaba, lo que probaba que el problema era más amplio que el DNS. Esta prueba de conectividad IP directa evita que los cambios en el resolvedor oculten un puente, NAT o una ruta de firewall defectuosos.
Si falla la conectividad IP, repara primero la red del contenedor. Si la IP funciona pero fallan los nombres, continúa con la configuración del resolvedor y la ruta de consulta.
Inspecciona la configuración del resolvedor dentro del contenedor
Lee /etc/resolv.conf dentro del contenedor y compáralo con el del host. Observa las direcciones de los servidores de nombres, los dominios de búsqueda, las opciones, el modo de red y si el archivo cambia después de recrear el contenedor.
Un caso de OpenMediaVault informó de fallos en las consultas desde contenedores a través del resolvedor integrado de Docker 127.0.0.11 después de una actualización del motor. Esa ruta del resolvedor integrado puede diferir de la consulta correcta del host.
No edites permanentemente el archivo generado dentro de un contenedor en ejecución. Define los servidores DNS y los dominios de búsqueda intencionados en la configuración de Compose o de la plataforma para que sobrevivan a la recreación.
Consulta por separado el DNS de Docker y el resolvedor ascendente
Realiza la misma consulta contra el resolvedor integrado de Docker, el router o servidor DNS local y un resolvedor externo conocido cuando la política lo permita. Compara los tiempos de espera, los rechazos, las respuestas NXDOMAIN y las direcciones devueltas.
Un caso de la comunidad de TrueNAS atribuyó el fallo de DNS exclusivo del contenedor a un perfil de acceso del router que bloqueaba las solicitudes, aunque el resto del tráfico del host funcionaba. La observación decisiva fue que el DNS estaba bloqueado para la ruta del contenedor, no que el nombre de host fuera incorrecto.
Si las consultas directas al servidor ascendente funcionan pero falla el resolvedor integrado, reinicia o repara el resolvedor y el estado de red de Docker. Si todos los servidores DNS agotan el tiempo de espera, inspecciona el enrutamiento del puerto 53, el firewall, la VPN y el tráfico de respuesta.
Comprueba si hay bucles de DNS locales y respuestas internas incorrectas
Determina si el contenedor intenta consultar un servicio DNS en el mismo host, otro contenedor o un nombre de host que vuelve a resolverse a través del proxy inverso. Captura la respuesta en lugar de asumir que toda consulta exitosa es correcta.
Un caso de la comunidad de Traefik descubrió que un contenedor resolvía un dominio personalizado hacia sí mismo en lugar del par previsto. Esa respuesta DNS incorrecta dentro del contenedor superaba una prueba básica de resolución, pero aun así impedía la conexión con la API.
Usa nombres de servicio para el tráfico entre contenedores de la misma red y DNS dividido para nombres de host públicos solo cuando la ruta de retorno sea intencionada. Evita las rutas de retorno que envían un contenedor a través del proxy público para acceder a una dependencia local, salvo que esa ruta se haya probado explícitamente.
Verifica las respuestas UDP, el NAT y el aislamiento de red
Captura el tráfico del puerto 53 en la interfaz del contenedor y en el puente del host. Confirma que la consulta sale, que el resolvedor la recibe y que la respuesta vuelve desde la dirección que espera el cliente.
Usuarios de Pi-hole han documentado que las consultas entre contenedores del mismo host agotaban el tiempo de espera porque las respuestas regresaban desde un origen traducido inesperado. Este origen inesperado de la respuesta DNS distingue un problema en la ruta de respuesta de un resolvedor silencioso.
Si la solicitud y la respuesta atraviesan redes de Docker diferentes, añade la red compartida o la ruta correcta en lugar de trasladar todos los servicios a la red del host. Comprueba las zonas del firewall y las políticas de VPN que puedan tratar las subredes puente de forma distinta a la dirección del host.
Recrea el estado de la red y demuestra la solución
Después de corregir el resolvedor, el firewall o la definición de red, recrea un contenedor de prueba en la red prevista y repite las pruebas de IP, resolvedor directo, resolvedor integrado, nombre de servicio y nombre público.
La guía de ZimaSpace sobre separar los fallos de dirección y de nombre ofrece el límite de diagnóstico complementario en el lado del host.
El problema solo se resuelve cuando la configuración de DNS sobrevive a la recreación y al reinicio, los nombres de servicios internos y los nombres públicos autorizados devuelven las direcciones previstas y el tráfico de la aplicación funciona a través de la misma ruta de red. Si el fallo reaparece únicamente después de una actualización de Docker, conserva la versión y los registros del demonio como referencia del límite de una posible regresión del entorno de ejecución.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
