Construyendo un HomeLAB: DNS propio y reverse proxy

30/8/2026

Por qué un DNS propio

Con varias máquinas virtuales y servicios corriendo, empecé a acumular direcciones IP que tenía que recordar de memoria — no es sostenible. La solución fue desplegar un resolutor DNS interno con capacidad de bloqueo de publicidad, y usarlo como DNS de toda la red doméstica.

Esto trajo su propio aprendizaje sobre redes de contenedores: el resolutor necesitaba una IP real dentro de la red física, no una IP interna de Docker — porque otros dispositivos de la casa (móviles, portátiles) necesitan poder consultarlo directamente, no solo el propio servidor. La solución fue un modo de red específico que le asigna una dirección real de la LAN, en vez de esconderlo detrás de la capa de red habitual de los contenedores.

La consecuencia de esa decisión, que tardé en entender del todo: ese resolutor queda aislado del resto de contenedores que sí viven en la red interna normal de Docker. Un contenedor de monitorización no puede alcanzarlo directamente por esa vía — tuve que resolverlo con un mecanismo distinto (un pequeño script en un dispositivo externo que le avisa activamente de su estado, en vez de que el monitor le pregunte). Es un buen ejemplo de cómo el aislamiento de red, cuando lo diseñas a propósito, tiene efectos que hay que anticipar en las piezas que dependen de él.

Un paso más: independencia total de proveedores DNS externos

Más adelante añadí un resolutor DNS recursivo propio, que consulta directamente a la jerarquía real de Internet en vez de reenviar las peticiones a un proveedor externo. La primera consulta a cada dominio nuevo es algo más lenta — tiene que recorrer la cadena de delegación DNS real — pero a cambio, ningún tercero ve mis consultas de forma centralizada.

Un único punto de entrada: el reverse proxy

Con varios servicios corriendo, necesitaba una forma de exponerlos todos bajo nombres claros, sin memorizar puertos distintos para cada uno. Un reverse proxy resuelve esto: recibe todo el tráfico, y según el nombre de dominio de la petición, decide a qué servicio interno reenviarla.

Esto también me obligó a pensar en certificados TLS de dos formas distintas: para nombres puramente internos (que nunca salen de mi propia red), un certificado autofirmado es suficiente — el aviso de “no confiable” del navegador se acepta una vez, y punto. Para el dominio público real, en cambio, se puede emitir un certificado válido reconocido por cualquier navegador, sin ninguna advertencia.

La lección de la que más aprendí: túneles y modos de cifrado no siempre encajan por defecto

Al exponer un servicio al público a través de un túnel en vez de abrir puertos directamente en el router, me encontré con un bucle de redirección que costó bastante diagnosticar: el propio servicio redirigía todo tráfico HTTP a HTTPS, pero el túnel le entregaba el tráfico ya “traducido” en HTTP puro por dentro. El resultado era un bucle infinito — cada redirección volvía a entrar por el mismo camino. La solución fue dejar que la capa exterior (el propio proveedor del túnel) se encargara de forzar HTTPS, y quitarle esa responsabilidad al servicio interno. Fue un buen recordatorio de que cuando algo “no tiene sentido que falle” y aun así falla, casi siempre hay una capa intermedia haciendo algo que no habías considerado.

Lo que viene

Con el DNS y el reverse proxy resueltos, el terreno quedó listo para el resto de servicios: gestor de contraseñas, repositorio de código propio, y monitorización de todo el conjunto. Lo cuento en la siguiente entrada.