El reto: descubrimiento de servicios en contenedores. En el desarrollo backend moderno la mayor parte de los sistemas se ejecuta en entornos aislados, habitualmente contenedores. Un backend típico está compuesto por varios servicios que deben comunicarse entre sí. Orquestadores como Kubernetes y Docker Compose ofrecen DNS interno para que los servicios se encuentren por nombre, lo que resulta muy cómodo y casi mágico.
Por qué el DNS interno no basta cuando hace falta una URL publica. ¿Qué ocurre si necesitas acceder a un servicio mediante una URL publica? Imagina un proxy inverso que expone todo, con Keycloak detrás y un oauth2-proxy gestionando la autentificación con Keycloak. El proxy necesita dos parámetros clave: redirect-url que es la URL que alcanza el navegador y oidc-issuer-url que es la URL que usa el proxy para obtener tokens. Para evitar problemas CSRF también se suele activar cookie-secure true. Como los clientes alcanzan Keycloak a través del proxy inverso la redirect-url debe apuntar al proxy; el issuer-url debe apuntar a Keycloak. Usar un nombre DNS interno para el issuer rompe las comprobaciones CSRF: ambas URLs deben compartir el mismo hostname, algo que normalmente es un dominio publico que no tenemos en desarrollo local. Dilema.
Por qué hostnames distintos provocan errores CSRF. Durante el flujo OAuth OIDC el proxy establece un valor efímero state o nonce en una cookie en el host exacto que visita el usuario, por ejemplo auth.local.test. Cuando Keycloak redirige de vuelta el proxy debe comparar el state en la URL de callback con la copia almacenada en la cookie. Esa comparación es la defensa CSRF. Si mezclas hosts, por ejemplo si el navegador visita https://auth.local.test pero el issuer es https://keycloak:8080 el navegador no enviará la cookie al otro host porque el ámbito de la cookie depende del hostname. Además cookie-secure obliga a enviar la cookie solo por HTTPS, así que cualquier salto por HTTP la pierde. Las reglas SameSite modernas también consideran hosts distintos como cross site y bloquean aún más la cookie. El proxy no encuentra la cookie que él mismo puso y la comprobación de state falla generando el error CSRF. Por eso resolver el nombre publico hacia tu contenedor localmente es tan efectivo: todos los pasos ven el mismo host, el navegador envía la cookie correcta y la comprobación CSRF pasa.
Soluciones existentes. Muchas personas recurren a falsificar dominios en el archivo hosts o buscan herramientas que mapeen nombres de contenedores a hostnames. Actualizar hosts en cada inicio de Docker funciona pero es frágil y vulnerable a sobreescrituras. Lo ideal es un comportamiento parecido al DNS real sin tener que editar archivos a mano.
Una mejor aproximación: servidor DNS local para contenedores. Ejecuta un servidor DNS local que vigile los contenedores en ejecución. Si una consulta coincide con el nombre o alias de un contenedor responde con su IP; si no, reenvía la consulta a los servidores DNS habituales. Con las APIs de Docker y bibliotecas de DNS en lenguajes como Go es sencillo montar un servidor pequeño y fiable. El servidor resuelve nombres de contenedores a IPs y reenvía el resto a los upstreams públicos, imitando el comportamiento de producción en el entorno de desarrollo.
Cómo funciona a grandes rasgos. El navegador pregunta por example.com. El resolvedor local comprueba si hay un contenedor llamado o con alias example.com en ejecución. Si existe devuelve la IP del contenedor. Si no existe reenvía la consulta al DNS publico y devuelve esa IP.
Ejemplo práctico con Docker Compose. Si lanzas un servicio con container_name github.com el servidor DNS local responderá github.com con la IP del contenedor. Por ejemplo una consulta dig github.com devolverá en la sección ANSWER la IP 172.21.0.2 que corresponde al contenedor. Puedes verificarlo con el comando docker compose ps -q ubuntu | xargs docker inspect -f {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} que muestra la IP del contenedor.
Configurar el sistema para usar el DNS local. Apunta tu resolvedor al servicio DNS local. Si usas systemd resolved el comando es sudo resolvectl dns INTERFACE 127.0.0.1:5300 sustituyendo INTERFACE por la interfaz adecuada. Este cambio puede ser temporal y reinicializarse al reiniciar el sistema; para volver al comportamiento por defecto basta reiniciar systemd resolved.
Ventajas. Resolver nombres publicos hacia contenedores locales evita desajustes de host que causan problemas de autenticación y cookies. No hace falta editar archivos hosts a mano. Funciona con Docker Compose de forma nativa y es fácil de verificar con herramientas como dig. En resumen un hostname coherente de extremo a extremo reduce sorpresas con auth y cookies y acerca el entorno local a producción.
Sobre Q2BSTUDIO. En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida especializada en soluciones personalizadas que integran inteligencia artificial y ciberseguridad, con experiencia en servicios cloud aws y azure, servicios inteligencia de negocio y soluciones como power bi. Ofrecemos desarrollo de aplicaciones a medida y software a medida que incluyen capacidades de ia para empresas y agentes IA para automatizar procesos y mejorar la toma de decisiones. Si te interesa potenciar tu infraestructura y despliegues en entornos locales y cloud podemos ayudar a diseñar la mejor arquitectura y flujo de trabajo, desde la integración con servicios cloud hasta los controles de seguridad. Conoce nuestros servicios de servicios cloud aws y azure y descubre cómo desarrollamos software a medida y aplicaciones a medida adaptadas a tu negocio. También ofrecemos ciberseguridad y pentesting para entornos productivos y de desarrollo y soluciones de inteligencia de negocio con Power BI para explotar tus datos.
Conclusión. Un pequeño servidor DNS local que mapea nombres a contenedores y reenvía el resto a upstreams públicos soluciona de forma elegante el problema de los hostnames desalineados en desarrollo. Menos hacks, menos errores CSRF y un entorno local que imita mejor a producción, facilitando integraciones con autenticación, IA y servicios cloud.
