El DNS de casa es una de esas piezas que parecen pequeñas hasta que fallan. Todo sigue encendido, el router tiene luz, el WiFi conecta, los servidores responden por IP, pero nadie puede abrir una web. La sensación para quien no está metido en redes es clara: “no hay internet”. Y técnicamente igual sí hay internet. Lo que no hay es resolución de nombres.
Este es uno de los fallos más tontos y más molestos de un homelab doméstico. Montas Pi-hole, AdGuard Home, Unbound, DNS interno, nombres bonitos para servicios, bloqueo de publicidad, split-horizon y cuatro comodidades más. Todo funciona. Te vienes arriba. Luego actualizas una máquina, reinicias un contenedor o apagas un nodo pensando que no pasa nada, y la casa entera se queda mirando el móvil como si el operador hubiese explotado.
No es un fallo grave si tienes plan B. Sin plan B, es la clase de tontería que convierte una tarde tranquila en soporte técnico familiar.
Yo veo el DNS doméstico con una regla bastante simple: puede ser sofisticado, pero el modo degradado tiene que ser aburrido. Si el homelab está tocado, la casa debe poder navegar.
El problema no es usar DNS propio#
No tengo nada contra usar DNS propio en casa. Al contrario. Me parece una de las mejoras más útiles de un homelab.
Con DNS local puedes tener:
- Nombres legibles para servicios internos.
- Bloqueo de publicidad y telemetría básica.
- Resolución coherente para móviles, portátiles y televisores.
- Integración con reverse proxy interno.
- Más control sobre qué pasa en la red.
- Unbound o DoH si quieres controlar la salida.
El problema aparece cuando ese DNS se convierte en un único punto de fallo. Y esto pasa muy fácil.
Ejemplo típico:
- El router entrega por DHCP la IP del Pi-hole.
- Pi-hole vive en una VM o contenedor.
- Esa VM vive en un nodo Proxmox.
- Ese nodo depende de almacenamiento, red o una actualización.
- Si algo cae, todos los clientes siguen preguntando al DNS muerto.
El resultado parece una caída total. No carga el banco, no carga YouTube, no carga la app del robot aspirador y alguien pregunta por qué “otra vez estás tocando cosas”. Esa frase debería venir incluida en todas las distribuciones de homelab como test de producción.
Qué quiero de un plan B#
Para mí, un buen plan B de DNS doméstico tiene que cumplir cinco cosas.
1. La familia debe seguir navegando#
Esto es lo primero. Si mi DNS bonito cae, los dispositivos normales deberían poder resolver dominios públicos. Igual pierdo bloqueo de anuncios, nombres internos o alguna comodidad. Vale. Pero internet básico debe seguir.
2. No debe depender del mismo fallo#
Si el DNS principal vive en el cluster, el secundario no debería vivir en la misma máquina, el mismo almacenamiento y el mismo punto de red. Si ambos caen juntos, no tienes redundancia. Tienes decoración simétrica.
3. Debe ser simple#
Un plan B que solo entiendo yo un martes con café no sirve. Tiene que ser lo bastante simple como para que no me dé pereza mantenerlo.
4. Debe degradar con claridad#
Cuando algo falle, quiero saber si estoy en modo normal o modo emergencia. No quiero pasar dos horas pensando que el DNS filtra anuncios cuando en realidad todos están saliendo por un resolver externo.
5. Debe probarse#
Si nunca lo has probado, no tienes plan B. Tienes una teoría.
Arquitectura mínima que usaría#
Para una casa normal con homelab, me gusta esta arquitectura:
- DNS principal: Pi-hole o AdGuard Home en un nodo eficiente y estable.
- DNS secundario: otro Pi-hole o AdGuard en hardware distinto, o el propio router si permite un modo básico decente.
- Upstream externo claro: 1.1.1.1, 9.9.9.9 o el proveedor que prefieras.
- DHCP entregando dos DNS a los clientes.
- Nombres internos documentados.
- Comprobación periódica desde fuera del servidor principal.
No hace falta montar una tesis. Hace falta evitar que una sola VM tenga a toda la casa agarrada por el cuello.
La variante más limpia es tener dos resolvers internos. Por ejemplo:
| |
Uso IPs de ejemplo. La idea es que DNS 1 y DNS 2 no vivan en el mismo sitio físico o lógico si puedes evitarlo.
Si tienes un mini PC siempre encendido y un NAS, no pondría ambos DNS en dos contenedores del mismo mini PC. Mejor uno en el mini PC y otro en el NAS, o uno en una Raspberry Pi pequeña, o uno en el router si el router lo permite.
Cuidado con el falso secundario#
Aquí hay una trampa clásica: configurar dos DNS en DHCP y pensar que el segundo solo se usa si el primero cae.
Muchos clientes no se comportan de forma tan ordenada. Algunos preguntan a ambos, otros mantienen cachés, otros insisten con el primero, otros alternan. Eso significa que si pones como secundario un DNS externo, parte del tráfico puede saltarse Pi-hole o AdGuard incluso cuando el principal funciona.
¿Es grave? Depende de tus prioridades.
Si lo más importante es que internet funcione siempre, poner un externo como segundo DNS puede ser aceptable. Si quieres filtrado consistente y nombres internos fiables, mejor tener dos DNS internos con la misma configuración básica.
Mi preferencia:
- Para red familiar: dos DNS internos si puedo.
- Para red de invitados: DNS del router o externo sin complicarme.
- Para laboratorio: DNS interno con más libertad y menos drama.
En una casa, la red familiar no debería pagar tus experimentos.
Qué pasa con los nombres internos#
El fallback externo no conoce tus nombres internos. Si usas nas.home.arpa, photos.home.arpa o router.home.arpa, necesitas que el DNS secundario también sepa resolverlos.
Esto se puede resolver de varias formas:
- Duplicar registros locales en ambos resolvers.
- Usar archivos o configuración sincronizada.
- Hacer que ambos consulten a una autoridad interna.
- Mantener pocos nombres y documentarlos bien.
Yo prefiero pocos nombres internos y claros. Si cada contenedor tiene cinco alias, el DNS acaba siendo otra base de datos artesanal que nadie quiere tocar.
Para servicios web internos, muchas veces basta con tener registros para:
nas.home.arpaproxmox.home.arpaapps.home.arpahomeassistant.home.arpamonitor.home.arpa
Luego el reverse proxy puede encargarse de rutas o subdominios si lo necesitas. Pero no convertiría el DNS doméstico en un cementerio de nombres antiguos.
El router como último recurso#
No todos los routers son buenos en DNS. Algunos son básicos, otros opacos y otros directamente molestos. Aun así, el router puede ser un buen último recurso.
Hay dos enfoques:
Router entrega DNS internos#
El router hace DHCP y entrega las IPs de Pi-hole o AdGuard. Es el modelo más común.
Ventaja: simple.
Problema: si los DNS internos caen y los clientes no tienen alternativa útil, internet parece muerto.
Router actúa como DNS visible para clientes#
Los clientes usan el router como DNS. El router reenvía a Pi-hole, AdGuard o resolvers externos según configuración.
Ventaja: puedes cambiar upstream en un solo sitio.
Problema: algunos routers cachean raro, no permiten reglas finas o dificultan saber qué cliente hizo cada consulta.
Si el router es decente, me gusta que pueda actuar como emergencia. Si el DNS interno cae, cambio upstream o activo fallback. Si el router es limitado, prefiero dos resolvers internos bien montados.
Unbound, DoH y la tentación de complicarlo todo#
Unbound está muy bien si quieres resolver de forma recursiva o tener más control. DNS over HTTPS también puede tener sentido según tu proveedor, privacidad y red. Pero ninguna de esas capas arregla el problema principal si todo vive en una sola VM.
Puedes tener una configuración preciosísima con Unbound, listas de bloqueo, caché y métricas. Si el contenedor cae, cae todo.
Mi orden de prioridades sería:
- Disponibilidad básica.
- Configuración entendible.
- Logs suficientes.
- Bloqueo de anuncios.
- Privacidad o resolución avanzada.
Mucha gente empieza por el punto 5 porque es más entretenido. Lo entiendo. Pero si la casa se queda sin internet cuando reinicias el nodo, el diseño todavía no está maduro.
Separar redes ayuda mucho#
No todas las redes de casa necesitan el mismo DNS.
En una red familiar, quiero estabilidad. En una red IoT, quiero control y aislamiento. En una red de laboratorio, quiero flexibilidad. En invitados, quiero que funcione y ya.
Una separación razonable podría ser:
- LAN principal: dos DNS internos estables.
- IoT: DNS filtrado y reglas más cerradas.
- Invitados: DNS del router o resolver externo.
- Laboratorio: DNS interno experimental.
Esto evita que una prueba en laboratorio afecte a la tele, al móvil de tu pareja o a un dispositivo doméstico. En firewall para homelab familiar ya defendía esa separación por convivencia más que por paranoia.
La seguridad importa, pero la paz doméstica también.
Monitorizar DNS sin montar un monstruo#
No hace falta Prometheus para saber si DNS responde. Una comprobación sencilla desde otra máquina ya aporta mucho.
Yo miraría tres cosas:
- ¿Resuelve un dominio público?
- ¿Resuelve un nombre interno?
- ¿La latencia es razonable?
Ejemplo conceptual:
| |
Si falla el principal, alerta. Si falla el secundario, alerta menos urgente pero alerta. Si ambos fallan, ahí sí hay incendio doméstico.
Lo importante es que la comprobación no viva únicamente dentro del mismo servidor DNS. Si el servidor está muerto, su propio monitor no va a escribirte una carta de despedida.
Prueba de caída controlada#
La prueba que haría es muy simple:
- Confirmar que todo funciona en modo normal.
- Apagar DNS principal.
- Probar navegación desde móvil y portátil.
- Probar resolución de un nombre interno.
- Mirar qué se pierde.
- Encender DNS principal.
- Apagar DNS secundario.
- Repetir.
No hace falta hacerlo cada semana. Pero sí una vez después de montarlo y otra después de cambios gordos.
La parte interesante no es que todo funcione perfecto. La parte interesante es descubrir qué se rompe. Igual internet va bien, pero nombres internos no. Igual móviles aguantan por caché, pero una tele no. Igual el portátil alterna resolvers de forma rara.
Mejor descubrirlo un domingo con café que un martes a las 21:30 con alguien intentando ver una serie.
Documentar el modo emergencia#
Yo dejaría una nota muy corta. Nada de documentación eterna.
Algo así:
| |
Esa nota puede estar en tu gestor de contraseñas, en un documento local o en el propio inventario del homelab. Lo que no haría es guardarla solo en el servicio que quizá no puedas resolver cuando el DNS está roto. Pequeño detalle, pero bastante gracioso cuando te pasa.
Qué evitaría#
Evitaría varias cosas.
No pondría el único DNS en una VM de laboratorio. No usaría un único contenedor sin backup de configuración. No mezclaría DNS crítico con experimentos de bloqueo agresivo. No entregaría solo un resolver por DHCP si la casa depende de él. No asumiría que “secundario” significa comportamiento ordenado en todos los clientes.
También evitaría listas de bloqueo enormes sin revisar. A veces el problema no es que el DNS caiga, sino que bloquea justo lo que no debería. Para una red familiar prefiero listas razonables y estabilidad. Si quiero experimentar con bloqueo más duro, lo hago en mi red o en un perfil separado.
Mi diseño favorito para una casa#
Si tuviese que dejarlo fino pero sin complicarlo, montaría esto:
- Router haciendo DHCP.
- Dos DNS internos en hardware distinto.
- Misma lista básica de registros locales en ambos.
- Upstream externo claro y documentado.
- Red de invitados fuera del DNS filtrado.
- Monitor simple desde una tercera máquina.
- Nota de emergencia con IPs y pasos mínimos.
Si solo puedes tener un DNS interno, entonces pondría un fallback externo conscientemente y aceptaría la pérdida parcial de filtrado. Prefiero que se salte un anuncio a que la casa piense que he roto internet.
Para homelab puro, puedes permitirte más elegancia. Para casa, estabilidad primero.
Conclusión#
El DNS doméstico merece cariño porque mejora mucho la experiencia del homelab. Pero no puede ser una pieza frágil escondida en una VM cualquiera. Si todo depende de él, hay que tratarlo como infraestructura.
Mi regla es sencilla: el DNS principal puede ser bonito, filtrado y muy cómodo. El plan B tiene que ser feo, claro y fiable.
Cuando el homelab está sano, disfrutas nombres internos, bloqueo y control. Cuando algo se rompe, la casa sigue navegando. Ese equilibrio vale más que cualquier dashboard perfecto. Sobre todo porque nadie en casa te va a felicitar por un DNS elegante, pero sí van a avisarte rápido si Netflix no carga.