Actualizar el DNS de Producción sin Tocar Nunca el Nodo en Vivo

DNS es el servicio donde un homelab deja de ser un hobby. Nada en la casa funciona sin él, a nadie en la casa le importa por qué, y la falla es total en lugar de parcial.

El mío corre en par: dos instancias de Pi-hole, cada una con su propio resolvedor recursivo, compartiendo una dirección flotante gestionada por VRRP. Un nodo es maestro con mayor prioridad y preempción; el otro es un respaldo en caliente. Los clientes solo hablan con la dirección flotante.

Recientemente el respaldo necesitó una actualización de versión mayor — una nueva imagen base que también eliminó el resolvedor recursivo incluido, así que ese también tuvo que convertirse en su propio contenedor. Suficientes piezas en movimiento para ser genuinamente riesgoso en el servicio del que depende todo.

El procedimiento se define por el nodo que toques

Toda la seguridad de esta operación viene de una precondición, verificada antes que nada:

Confirma que el maestro tiene la dirección flotante y que el nodo en el que vas a trabajar es el respaldo.

Si eso es cierto, el DNS del respaldo puede parpadear, reiniciarse, romperse o reconstruirse desde cero con cero impacto en los clientes, porque ningún cliente está hablando con él. Si es falso — si el respaldo tomó el control silenciosamente en algún momento y no te diste cuenta — entonces la misma secuencia de comandos es una caída total.

Mismos comandos. Mismo host. Todo igual. La diferencia entre mantenimiento rutinario y un incidente es una consulta que haces primero. Ahora escribo esa verificación como una puerta explícita al inicio del runbook, con un “no procedas si” adjunto, porque la versión en mi cabeza es la que salto cuando estoy confiado.

La verificación de salud es un contrato

La verificación de failover era una línea: ¿puede alguien conectarse al puerto de la interfaz web?

Eso convierte un detalle de implementación — el puerto en el que escucha la interfaz de administración — en un contrato fundamental entre dos contenedores que no saben uno del otro. La nueva imagen usa por defecto un puerto diferente. Si lo hubiera dejado, la verificación de salud habría fallado, el respaldo se habría declarado no saludable, y habría pasado la noche depurando VRRP en lugar de DNS.

Así que el nuevo despliegue fija explícitamente el servidor web al puerto viejo. La línea de configuración parece arbitraria y vestigial. Es la única razón por la que el failover funciona, y escribí un párrafo junto a ella diciendo eso, porque la próxima persona que limpie un enlace de puerto “arbitrario” seré yo en ocho meses.

Dos nodos no son dos configuraciones

Tener un par redundante crea un problema nuevo: deben estar de acuerdo. Las listas de bloqueo, registros locales y configuraciones se desincronizan si ambos se editan, y la desincronización en DNS produce la peor clase de bug — comportamiento que depende de qué nodo respondió.

La solución fue dejar de tratarlos como pares para configuración. Un nodo es la fuente de la verdad, y un servicio de sincronización empuja un subconjunto seleccionado al otro. No todo: gravity y configuraciones específicas, deliberadamente acotadas, porque una replicación completa también copiaría la identidad por nodo y desharía lo que los hace máquinas separadas.

La redundancia es una propiedad del plano de datos. El plano de control debe tener exactamente un escritor. Dos Pi-hole que puedo editar es no alta disponibilidad, son dos Pi-hole.

Lo que hizo esto seguro fue aburrido

Un respaldo tomado antes que nada, en un directorio del host, con la configuración vieja preservada al lado. Imágenes fijadas por digest en lugar de una etiqueta flotante, para que un rollback regrese a los mismos bytes. Auto-actualización explícitamente deshabilitada en los contenedores DNS, porque un servicio del que depende toda la casa no debe cambiar mientras duermo porque alguien upstream publicó una etiqueta.

Nada de eso es ingenioso. Todo eso es por qué una actualización mayor en DNS de producción fue una noche normal.