Resolución DNS Local para Docker en Desarrollo

En entornos modernos de backend la mayoría de los servicios se ejecutan en entornos aislados como contenedores, y la comunicación entre servicios suele resolverse con DNS interno proporcionado por el orquestador. Eso funciona bien hasta que aparece la necesidad de exponer servicios mediante una URL publica y todo deja de comportarse como en produccion.

El problema típico ocurre con flujos OAuth/OIDC donde interviene un reverse proxy, un proveedor de identidad como Keycloak y un proxy de autenticacion tipo oauth2-proxy. Ese proxy necesita una redirect url que es la que visita el navegador y una oidc issuer url que usa para obtener tokens. Para evitar problemas CSRF normalmente activas cookies seguras y SameSite, de modo que el navegador solo envia la cookie cuando la misma comunicacion usa exactamente el mismo nombre de host y HTTPS. Si tu issuer apunta a un nombre interno de contenedor mientras la redirect url usa el dominio publico del proxy, el navegador no enviara la cookie al host distinto y la comprobacion de state/nonce fallara generando errores CSRF aparentemente inexplicables.

La raiz del problema es que los navegadores aplican alcance de cookies por host y politicas SameSite estrictas; cualquier salto entre nombres de host o entre HTTP y HTTPS impide que la cookie viaje junto con la peticion y la comparacion que protege contra CSRF no encuentra el valor esperado.

Soluciones habituales pasan por manipular /etc/hosts o por herramientas que mapean nombres a containers, pero editar archivos hosts es frágil y propenso a sobrescrituras. Una alternativa mas robusta es ejecutar un servidor DNS local que observe los contenedores en ejecucion y responda con la IP del contenedor cuando la consulta coincide con un nombre o alias de contenedor; para el resto de dominios reenvia a los resolvers publicos habituales.

El comportamiento es simple: el resolver local recibe una consulta para ejemplo.com, comprueba si existe un contenedor llamado o aliasado como ejemplo.com y si existe devuelve la IP del contenedor; en caso contrario reenvia la consulta a los DNS ascendentes. Con esta aproximacion todos los pasos del flujo de autenticacion ven el mismo nombre de host y las cookies seguras y SameSite funcionan como en produccion evitando los errores CSRF.

En la practica puedes ejecutar este servidor DNS en el puerto 53 o en otro puerto y apuntar tu resolucion local hacia el servidor. Por ejemplo con systemd-resolved puedes probar temporalmente resolvectl dns INTERFACE 127.0.0.1:5300. En Docker Compose un ejemplo sencillo es declarar un servicio ubuntu con container_name github.com; tras levantar Compose cualquier consulta DNS por github.com retornara la IP del contenedor, lo que permite que dig github.com apunte a la IP interna del contenedor y que el navegador trate la comunicacion como si fuese el mismo host publico en todo el flujo.

Verificar es directo: comprueba la IP del contenedor con docker compose ps y docker inspect para confirmar que la IP devuelta por el resolver coincide con la IP del contenedor. Si todo esta configurado correctamente no necesitas editar hosts ni recurrir a soluciones temporales, y tu entorno de desarrollo se comportara de forma mas parecida al entorno de despliegue.

En Q2BSTUDIO somos especialistas en construir soluciones que mejoran el flujo de desarrollo y la fiabilidad de sistemas distribuidos. Ofrecemos servicios de desarrollo de aplicaciones a medida y arquitecturas cloud, y podemos integrar soluciones como un resolutor DNS local dentro de pipelines de desarrollo o entornos de CI para evitar estos problemas de discovery en contenedores. Tambien acompañamos con servicios cloud aws y azure para asegurar despliegues coherentes entre desarrollo y produccion.

Ademas de desarrollo y despliegue ofrecemos expertise en inteligencia artificial, ciberseguridad, servicios de inteligencia de negocio y herramientas como power bi. Si necesitas IA para empresas, agentes IA, pentesting o automatizacion de procesos podemos asesorarte para que la infraestructura de desarrollo y las politicas de seguridad no entorpezcan flujos criticos como la autenticacion OIDC.

Beneficios principales: una sola hostname de extremo a extremo reduce sorpresas con cookies y auth, evita ediciones manuales de hosts y funciona con Compose sin complicaciones. Si quieres una demo o integrarlo en tu stack contacta con nosotros y evaluamos la mejor opcion para tu arquitectura y procesos de desarrollo.