Resumen

  • George Michaelson tenía un respaldo DNS en teoría, pero no lo había puesto en marcha; al reiniciar el supuesto principal descubrió que era la única instancia.
  • DHCP y los anuncios de router permiten entregar varias direcciones de resolvedores, aunque esa lista no demuestra que los equipos la hayan conservado ni que usen la alternativa al fallar la primera.
  • Una constancia de conmutación debe distinguir servicio activo, independencia, configuración enviada, estado observado en clientes, respuesta útil, reglas equivalentes y reversión.

George Michaelson contó el 9 de septiembre en el blog de APNIC cómo operaba Pi-hole y AdGuard como DNS interno de su casa. La entrada es una experiencia personal, no un aviso de incidente de la infraestructura de APNIC. Su hallazgo es más sencillo y más útil: había pensado en un plan de respaldo, pero no lo había implementado. Cuando reinició el servicio que llamaba principal, distintos dispositivos dejaron de funcionar. Entonces comprobó que no había un principal y un secundario. Había uno solo.

La fuente no ofrece duración, captura de paquetes, inventario de equipos, diagrama de red ni daño de seguridad. No hace falta inventarlos. La evidencia disponible basta para separar una intención de un estado operativo. Un segundo resolvedor puede figurar en un esquema sin que exista un proceso. Puede estar encendido sin que el router anuncie su dirección. La dirección puede salir por DHCP y no quedar guardada en todos los clientes. Incluso puede responder durante una caída y aplicar reglas diferentes a las del primer servicio.

La prueba en vivo fue consecuencia de una prueba omitida

El reinicio produjo la interrupción, pero no creó la ausencia del respaldo. Esa ausencia ya estaba incorporada al sistema. La diferencia afecta a la decisión de mantenimiento. Detener un endpoint parece una operación acotada cuando se cree que existe una alternativa probada. Si la alternativa sólo está en la cabeza del administrador, la operación prueba las dependencias directamente sobre quienes usan la red.

Michaelson describe una superficie amplia: al reiniciar DNS se detenían funciones de la casa; cambiar el router podía derribar la red inalámbrica; modificar el DNS del router afectaba DHCP. Por eso formula tres preguntas: qué dispositivos dependen del componente, si adoptarán otro servicio y si es posible regresar a la situación previa.

La cantidad de máquinas no resuelve esas preguntas. Dos procesos en el mismo equipo comparten su caída. Dos equipos conectados a la misma fuente de energía comparten el corte. Dos direcciones anunciadas por un solo router comparten el fallo del router. Dos copias de una configuración equivocada comparten el error humano. La independencia debe definirse por la avería que una alternativa sí puede sobrevivir.

Anunciar dos direcciones no prueba la conmutación

RFC 2132 permite que la opción 6 de DHCPv4 entregue una lista de servidores DNS en orden de preferencia. RFC 3646 hace algo parecido con DHCPv6 y una o más direcciones IPv6 de servidores recursivos. RFC 8106 permite incluir direcciones RDNSS en anuncios de router IPv6 y asignarles una vigencia; el valor cero indica que ya no deben usarse.

Estas normas describen cómo se aprovisiona la información. Una captura de la opción emitida demuestra qué quiso comunicar el router o el servidor DHCP en ese momento. No demuestra qué recibió un televisor, un teléfono, un portátil o un sensor. RFC 6419 registró diferencias relevantes entre sistemas con varias interfaces: listas por interfaz o globales, selección del primer o último conjunto recibido y diversas estrategias de espera y repliegue. Es un documento histórico, no un censo actual de la casa mencionada. Aun así, impide tratar la pantalla del router como prueba de todos los clientes.

RFC 9520 también permite que un resolvedor reintente una consulta con otro servidor o transporte. No garantiza que todos los clientes lo hagan ni fija el momento. La resolución sólo fracasa, según ese texto, cuando ninguno de los servidores disponibles entrega datos útiles para la consulta. Por tanto, el resultado que importa no es “se publicaron dos direcciones”, sino “un cliente identificado obtuvo una respuesta útil durante la ausencia controlada de la preferida”.

Seguir en línea puede ocultar una regla perdida

El DNS doméstico del relato incluía bloqueos y redirecciones de determinados nombres hacia direcciones no enraizadas. Eso obliga a comprobar la paridad de política. Una alternativa puede resolver nombres comunes y no reproducir la respuesta local o el bloqueo previsto. La conexión parece recuperada mientras el comportamiento cambia.

La fuente no acredita una brecha de seguridad ni una fuga. La conclusión debe ser más estrecha: una prueba de respaldo tiene dos resultados. Debe verificar disponibilidad y también el tratamiento local esperado. Si el segundo resolvedor responde pero usa otra política, el resultado es parcial y debe quedar anotado.

Una constancia doméstica, no una burocracia empresarial

La mejor objeción viene del propio texto: no todas las casas necesitan redundancia empresarial y muchas pueden tolerar una interrupción ocasional. Mantener dos servicios, sincronizar listas y probar distintas clases de clientes consume tiempo. La disciplina sólo es sensata si guarda proporción con las dependencias reales del hogar.

Una nota breve puede bastar. Registrar los resolvedores A y B y sus dependencias comunes; capturar las direcciones y vigencias emitidas por DHCPv4, DHCPv6 o RDNSS; observar algunos clientes distintos; retirar por unos minutos el servicio preferido; consultar un nombre ordinario y otro sujeto a una regla local; anotar qué endpoint respondió cuando sea visible; y restaurar la configuración previa.

Ese ejercicio no certifica todos los dispositivos ni todos los tipos de fallo. Sí convierte una afirmación general en un caso comprobado y deja claros sus límites. La alternativa pasa de plan a respaldo cuando se ejecuta, de respaldo a resiliencia cuando los clientes la usan, y de resiliencia a operación mantenible cuando la reversión también funciona.

Fuentes