Cómo configurar failover de DNS en Pi-hole para alta disponibilidad

Por qué el DNS local necesita redundancia en el homelab

Quien administra un laboratorio residencial o una red doméstica un poco más robusta conoce el peso que un servidor de nombres centralizado soporta. Cuando utilizamos Pi-hole para bloquear publicidad y organizar los nombres internos, este se convierte en el cerebro de toda la navegación web. En la práctica, esto significa que si la máquina donde corre se reinicia o presenta problemas, todo el internet parece caerse en casa, incluso con el proveedor funcionando perfectamente. Para evitar este tipo de dolores de cabeza, crear una estrategia de alta disponibilidad con dos instancias trabajando juntas deja de ser un lujo y pasa a ser una necesidad operacional.

En una arquitectura estándar, solemos apuntar la dirección del Pi-hole directamente en la configuración del router o vía DHCP (el protocolo que distribuye las direcciones IP a los aparatos de la red). Si ese único servidor falla, los dispositivos se quedan sin saber a dónde enviar las peticiones de traducción de direcciones, bloqueando el acceso a cualquier sitio web. Antes de avanzar, configurar redundancia de red comparte similitudes con lo que discutimos al configurar failover automático de internet en OpenWrt, donde el tráfico necesita encontrar un camino alternativo sin intervención humana.

La arquitectura ideal con instancias sincronizadas

La idea básica detrás de la alta disponibilidad es simple en teoría pero exige cuidado en la ejecución: necesitamos al menos dos servidores Pi-hole independientes corriendo en hardware separado, como dos mini PCs diferentes o un servidor principal y una Raspberry Pi secundaria. Si uno de ellos deja de responder, el segundo asume el trabajo de forma transparente. Para que esto funcione sin sorpresas desagradables, ambas instancias deben mantener las mismas listas de bloqueo, los mismos registros locales y las mismas reglas de reenvío.

Mantener estos datos iguales de forma manual es una invitación al caos, ya que cualquier cambio puntual exigiría duplicar el esfuerzo. Aquí es donde entran herramientas de sincronización como Gravity-Sync, que conectan ambos servidores por detrás y mantienen todo alineado de manera automatizada. En la práctica, haces un cambio en el servidor principal y la herramienta se encarga de replicar los archivos de configuración al servidor secundario en pocos segundos, garantizando consistencia.

Configurando el enrutamiento dinámico y las direcciones IP

El gran desafío en el DNS residencial es que la mayoría de los dispositivos de consumo aceptan solo dos direcciones de servidores de nombres (primaria y secundaria). Si colocamos la IP del primer Pi-hole y la IP del segundo Pi-hole, el sistema operativo alternará entre ellas de manera imprevisible. Algunas aplicaciones pueden enviar consultas al servidor secundario y acabar recibiendo respuestas diferentes si los servidores no están perfectamente sincronizados en ese exacto momento.

Para sortear este comportamiento errático, un enfoque avanzado de ingeniería utiliza enrutamiento dinámico o direcciones IP virtuales compartidas (con la ayuda de protocolos como VRRP, que permite que dos máquinas compartan una misma dirección IP de forma inteligente). Cuando la máquina principal deja de responder a los latidos de la red, la segunda asume inmediatamente la IP virtual. Así, para los dispositivos de la red, absolutamente nada ha cambiado y el servicio continúa fluyendo sin interrupciones perceptibles.

Paso a paso para implementar la segunda instancia

La implementación del segundo servidor exige una planificación previa de la dirección de red y de los paquetes instalados. El procedimiento a continuación resume la preparación inicial de la máquina secundaria antes de activar la sincronización automatizada con la principal.

1. Instala el sistema operativo base (como Debian o Raspberry Pi OS) en el hardware secundario y asigna una dirección IP estática en tu red local.
2. Ejecuta el script de instalación oficial de Pi-hole utilizando el comando estándar en la terminal para asegurar la misma versión base:

   curl -sSL https://install.pi-hole.net | bash

3. Configura las mismas opciones de reenvío de DNS upstream (como Cloudflare o Google) que utilizas en tu primera instancia, garantizando respuestas estandarizadas.

Tras completar este paso inicial, ambos servidores estarán listos para recibir la capa de sincronización y comenzar a operar en conjunto dentro de tu infraestructura. Para complementar esta implementación en entornos de producción, consulte también nuestros análisis técnicos sobre ¿Placa base en corto? Cómo hallar el componente dañado y Cómo inspeccionar tráfico MQTT de dispositivos IoT con Wireshark.

Validación y buenas prácticas de operación

Con ambas instancias corriendo y sincronizadas, llega el momento de probar la resiliencia del sistema antes de relajarse. Desconecta físicamente de la corriente tu servidor principal y observa el comportamiento de los equipos y teléfonos conectados a la red. Si la configuración de IP virtual o de múltiples servidores es correcta, la navegación no debe sufrir interrupciones perceptibles, y las consultas de DNS seguirán siendo resueltas por el servidor de respaldo de manera totalmente transparente.

Monitorea también el uso de recursos para garantizar que los hardwares elegidos soporten la carga y eviten cuellos de botella inesperados. Una infraestructura bien planificada en el homelab evita que problemas comunes de red conviertan una noche de descanso en una sesión interminable de solución de problemas manuales.