Hay averías de homelab que son molestas y averías que convierten la casa en una mesa de soporte técnico. Que se caiga Grafana no preocupa a nadie. Que no cargue internet porque el DNS vive en una VM que acabas de reiniciar ya es otra película.
El DNS tiene esa maldad discreta. Cuando funciona, nadie lo ve. Cuando falla, todo parece roto: el móvil dice que tiene WiFi pero no navega, la tele no abre las apps, el portátil carga algunas webs y otras no, Home Assistant empieza a quejarse de integraciones y tú pierdes diez minutos mirando el router antes de recordar que el DNS era “solo un contenedor”.
He llegado a una conclusión bastante sencilla: cualquier servicio que la familia use sin saber que existe necesita un modo degradado. El DNS doméstico entra de lleno en esa categoría. Puedes bloquear anuncios, resolver nombres internos y jugar con Unbound, pero necesitas una salida de emergencia que no dependa de tu entusiasmo del sábado por la noche.
Este artículo no va de instalar Pi-hole o AdGuard Home. Ya hay guías para eso. Va de la pregunta incómoda que viene después: qué pasa cuando esa pieza falla.
El fallo que quiero evitar#
El escenario típico es este:
| |
Funciona bien hasta que no funciona. Si el servidor se apaga, se actualiza, pierde red o el contenedor no levanta, los clientes siguen teniendo WiFi y puerta de enlace. Lo que no tienen es resolución de nombres. Para una persona normal eso significa “internet no va”.
La solución rápida suele ser entrar al router y cambiar DNS a mano. Eso está bien si estás en casa, despierto y con ganas. Como plan operativo es bastante pobre.
Lo que quiero es un modo degradado automático o casi automático:
- si cae el DNS principal, los dispositivos siguen navegando
- si el bloqueo de anuncios se pierde durante un rato, lo acepto
- los servicios internos pueden fallar de forma controlada
- la recuperación no exige recordar comandos raros
- la familia no tiene que entender qué es DNS
La prioridad es internet primero, homelab después. Esto duele un poco al orgullo técnico, pero se cura rápido.
Dos estrategias posibles#
Hay dos formas razonables de plantearlo.
La primera es tener dos DNS internos filtrados. Por ejemplo, dos instancias de AdGuard Home o Pi-hole en máquinas distintas. El router entrega ambos por DHCP. Si una cae, la otra responde.
| |
Es la opción más limpia si quieres mantener bloqueo de anuncios y nombres internos durante una caída. También exige cuidar dos piezas, sincronizar listas y asegurarte de que no dependen del mismo host, del mismo disco o del mismo experimento.
La segunda estrategia es usar un DNS interno y un DNS externo de emergencia.
| |
Es menos pura. Algunos clientes pueden usar el externo incluso cuando el interno está vivo, con lo que perderás parte del filtrado. Pero es simple y da una salida muy práctica si el homelab cae. En una casa donde la prioridad es que internet funcione, no me parece ninguna herejía.
Mi recomendación depende del contexto:
- casa con servicios críticos y varias máquinas: dos DNS internos
- casa pequeña o primer homelab: DNS local más fallback externo
- laboratorio puro: lo que quieras, pero no lo mezcles con la red familiar
Lo absurdo es no elegir. Dejar el DNS sin plan B no es minimalismo. Es optimismo caro.
Cuidado con el segundo DNS#
Hay una trampa bastante común: pensar que el segundo DNS solo se usa si cae el primero. No siempre.
El comportamiento depende del sistema operativo, del router, de la caché local y de detalles que no controlas del todo. Algunos clientes prueban ambos. Otros se quedan con el primero mientras responde. Otros cambian si una consulta tarda. En la práctica, si configuras un DNS local y uno público, parte del tráfico puede escapar del bloqueo.
Para mucha gente eso es aceptable. Para otras no. Lo importante es saberlo.
Si el objetivo principal es bloqueo consistente, usa dos DNS internos con la misma política. Si el objetivo principal es continuidad, acepta el DNS público de respaldo. No intentes venderte ambas cosas a la vez si no las has probado.
En mi red, para servicios que la familia usa, prefiero continuidad. Me molesta menos que una tele salte el bloqueo durante una hora que tener a alguien sin internet porque he querido diseñar el sistema perfecto. El homelab tiene que servir a la casa, no al revés.
Qué pondría como DNS de emergencia#
No usaría cualquier DNS al azar. Elegiría uno conocido y fácil de recordar.
Opciones razonables:
- Quad9:
9.9.9.9 - Cloudflare:
1.1.1.1 - Google:
8.8.8.8 - DNS del proveedor, si funciona bien
Quad9 me gusta porque añade bloqueo de dominios maliciosos y no es Google. Cloudflare suele ir muy rápido y es cómodo. Google funciona, pero ya le damos bastantes datos a Google sin regalarle también cada consulta DNS si no hace falta.
Si usas IPv6, recuerda configurar también DNS IPv6 o revisar qué reparte el router. Este es uno de esos sitios donde una red parece estar filtrada y luego descubres que los clientes salen por otro camino. No es magia negra. Es una configuración a medias.
También dejaría documentado el fallback en una nota local o impresa. Algo tan simple como:
| |
No necesitas un manual de 20 páginas. Necesitas que tu yo cansado entienda qué tocar.
Router como pieza de rescate#
El router es el sitio natural para el modo emergencia porque casi todos los clientes reciben DNS por DHCP desde ahí. Si el router permite cambiar DNS rápido, ya tienes una vía de recuperación.
Yo revisaría tres cosas:
- dónde se configuran los DNS entregados por DHCP
- si el router permite reservas DHCP para los servidores DNS
- si tiene una opción de DNS propio que pisa lo que tú crees haber configurado
Los routers de operadora pueden ser desesperantes. Algunos no permiten cambiar DNS. Otros lo permiten solo para IPv4. Otros anuncian DNS IPv6 por su cuenta. Otros se inventan un proxy DNS interno. Si tu router es así, quizá el primer paso serio de red no sea Pi-hole. Quizá sea poner un router decente detrás o cambiar a un firewall propio.
Pero no hace falta sobreactuar. Si el router permite poner dos DNS y reservar IPs, puedes tener una configuración doméstica bastante digna.
Lo que no haría es depender de una IP dinámica para el DNS local. El servidor DNS debe tener IP fija o reserva DHCP. Si un día cambia de dirección y el router sigue entregando la antigua, tendrás una avería absurda de esas que dan ganas de apagarlo todo e irse a tomar café.
Tailscale y VPN: otro sitio donde se rompe#
El DNS de casa no termina en la LAN. Si accedes por Tailscale, WireGuard o cualquier VPN, tienes que decidir qué DNS usan esos clientes cuando están fuera.
Con Tailscale puedes configurar DNS global, split DNS y MagicDNS. Es muy cómodo, pero también puede esconder problemas. Si el móvil fuera de casa depende del DNS interno para resolver servicios y ese DNS cae, quizá pierdas acceso justo cuando querías arreglarlo.
Para acceso remoto, me gusta separar dos cosas:
- nombres internos para servicios de casa
- resolución normal de internet para el dispositivo remoto
Si uso split DNS, solo mando el dominio interno hacia casa. El resto del tráfico DNS sigue usando el resolver normal del dispositivo o el que defina Tailscale. Así, si el DNS doméstico está tocado, no arrastro todo el internet del móvil con él.
También tendría al menos una forma de entrar que no dependa del DNS interno. Por ejemplo, una IP de Tailscale guardada para el servidor de administración o el panel del router si aplica. No para usarla a diario, sino como llave de emergencia.
La elección de esa puerta importa. Si dudas entre VPN privada, WireGuard directo o túnel web, la explico en Tailscale, WireGuard o Cloudflare Tunnel según el caso real. Para un plan B de DNS, yo priorizaría una vía privada y documentada antes que publicar paneles internos por comodidad.
La elegancia está muy bien hasta que no puedes resolver el nombre del servicio que necesitas para arreglar el DNS.
Qué pasa con los nombres internos#
Si usas un DNS externo como fallback, los nombres internos dejarán de resolver cuando caiga el DNS local. Eso es normal. nas.home.arpa o ha.home.arpa no existen fuera de tu casa.
La pregunta es si eso importa durante una caída.
Para mí hay dos niveles:
- internet doméstico: debe seguir funcionando
- servicios internos: pueden degradarse si el DNS local cae
Si Home Assistant, el NAS o Vaultwarden dependen de nombres internos, quizá fallen. Pero eso es mejor que dejar toda la casa sin internet. Si alguno de esos servicios es realmente crítico, entonces no basta con fallback público. Necesitas segundo DNS interno.
Esta distinción evita discusiones tontas. No todo tiene la misma prioridad. La navegación general, el trabajo remoto y el entretenimiento básico de la casa pesan más que resolver un dashboard interno durante una ventana de mantenimiento.
Prueba de caída real#
Un plan B que no se prueba es decoración.
Yo haría una prueba muy simple:
- Confirmar DNS actual en un portátil y un móvil.
- Apagar el DNS principal.
- Abrir una web que no hayas visitado hace poco.
- Probar una app de streaming o una web pesada.
- Mirar si el cliente usa el secundario.
- Encender el DNS principal.
- Confirmar que vuelve el bloqueo.
Si tienes dos DNS internos, apaga uno y mira si el otro responde. Luego apaga el otro. Luego reinicia ambos en orden distinto. Es aburrido, sí. Por eso funciona.
También limpiaría cachés al probar, o al menos tendría en cuenta que existen. Los navegadores, sistemas operativos y routers cachean respuestas DNS. Una prueba demasiado rápida puede darte una sensación falsa de seguridad.
En macOS, Windows, Linux, iOS y Android el comportamiento no es idéntico. Por eso pruebo dispositivos reales de la casa. El portátil del homelab no representa a la tele. La tele vive en su propio mundo, normalmente uno bastante peor.
Mi runbook de emergencia#
El runbook tiene que ser corto. Si necesitas leer una novela para recuperar DNS, no lo usarás.
El mío sería algo así:
| |
Esto no impresiona a nadie. Mejor. Los runbooks impresionantes suelen ser malos runbooks domésticos.
Lo guardaría fuera del servicio que puede caer. Una nota en el NAS está bien si el NAS no depende del DNS. Una página impresa en una carpeta también vale. Un documento dentro de una wiki que resuelve por el DNS roto es comedia involuntaria.
Errores que evitaría#
El primero: poner el DNS en Kubernetes si la red familiar depende de él y todavía estás aprendiendo Kubernetes. Me encanta Kubernetes para muchas cosas, pero no quiero que el internet de casa dependa de un cluster que estoy usando para experimentar con ingress, storage y upgrades.
El segundo: usar el mismo host para DNS principal y secundario. Dos contenedores en la misma máquina no son alta disponibilidad. Son dos procesos esperando al mismo apagón.
El tercero: olvidar IPv6. Si tu router entrega DNS IPv6 externo, parte de tus clientes puede pasar de tu DNS local. Si entrega el DNS local por IPv4 pero otro por IPv6, tendrás resultados raros.
El cuarto: poner listas agresivas y no tener forma rápida de desactivar bloqueo. A veces el problema no es que el DNS esté caído. Es que has bloqueado algo que una app necesita.
El quinto: no contar con el factor humano. Si cada vez que algo falla respondes “es que el DNS está propagando”, en casa te mirarán con razón como si estuvieras invocando excusas. Hazlo simple.
Cuándo merece la pena un segundo DNS interno#
Montaría segundo DNS interno si:
- trabajas desde casa y dependes de la red
- usas muchos nombres internos
- Home Assistant o servicios familiares dependen del DNS
- tienes varias VLANs
- ya tienes dos máquinas estables
- quieres bloqueo consistente sin escapes al DNS público
No lo montaría si estás empezando y eso te obliga a complicar toda la red. En ese caso, un fallback externo bien documentado es mejor que una réplica mal cuidada.
La madurez en homelab no siempre es añadir otra pieza. A veces es aceptar una degradación controlada.
Mi recomendación final#
Si hoy montara DNS doméstico para una casa con homelab, haría esto:
- DNS principal con AdGuard Home o Pi-hole en una máquina estable
- IP fija o reserva DHCP
- exportación de configuración
- DNS secundario interno si hay otra máquina fiable
- DNS externo de emergencia documentado si no hay segundo nodo
- prueba trimestral apagando el DNS principal
- nota corta de recuperación fuera del homelab
No necesito que el sistema sea perfecto. Necesito poder romper una parte sin romper la casa.
El DNS con bloqueo de anuncios es de las mejores mejoras pequeñas que puedes hacer en una red doméstica. Pero en cuanto lo pones delante de todo, deja de ser un juguete. Se convierte en infraestructura. Y la infraestructura doméstica tiene una obligación sencilla: fallar de una forma que no arrastre a todo el mundo contigo.
Si tu homelab cae y la casa sigue navegando, vas bien. Si apagas una VM y media familia pierde internet, el problema no es Pi-hole ni AdGuard. El problema es que convertiste una comodidad en punto único de fallo.