Configura una comprobación de estado de DNS programada

Una consulta DNS puntual te dice cuál es el estado actual. Una consulta programada y recurrente te dice si ese estado está cambiando, y un cambio en un dominio que no esperas modificar suele ser justo lo que conviene saber enseguida, en lugar de descubrirlo semanas después.

Decidir qué incluir

Empieza por todo aquello en lo que un cambio inadvertido importaría de verdad: los dominios de producción y sus subdominios clave, los dominios ligados a la entregabilidad del correo y todo lo que esté en una lista de vigilancia de seguridad. Programar la comprobación de un dominio por cuyo cambio nadie haría nada tiene poco valor: el objetivo es una señal a la que realmente vayas a responder, no un registro exhaustivo que nadie lee.

Elegir una frecuencia

Qué hacer con los resultados

El trabajo en sí es solo la mitad del valor; la otra mitad es lo que ocurre cuando los resultados de una ejecución difieren de los de la anterior. Como mínimo, conserva el historial suficiente para comparar ejecuciones consecutivas (esta herramienta conserva el historial de ejecuciones de los trabajos durante una ventana de retención configurable precisamente por este motivo). Exportar los resultados de cada ejecución como CSV o JSON facilita compararlos por programa, en lugar de depender de que alguien note un cambio a ojo en un panel que quizá consulte o no ese día.

Una vez que una programación funciona de forma fiable, el efecto práctico es convertir la supervisión del DNS de una tarea manual ocasional en un proceso en segundo plano que solo exige atención cuando de verdad hay algo que mirar, que es exactamente el objetivo.

Diseñar la alerta, no solo la comprobación

Una comprobación programada que notifica en cada ejecución, incluso en las que no encontraron nada nuevo, enseña a la gente a ignorarla en un par de semanas, lo que frustra todo su propósito. La señal útil es específicamente el cambio: las direcciones resueltas de esta ejecución difieren de las de la anterior, un dominio pasó de resolverse a fallar (o al revés), o una dirección nueva cayó en un rango que no debería ser accesible en absoluto. Construir la notificación en torno a «qué ha cambiado desde la última vez» y no a «este es el resultado de hoy» es lo que mantiene la alerta digna de abrirse meses después, en lugar de convertirse en otra etiqueta sin leer en una bandeja de entrada.

Qué pasa cuando falla la propia comprobación

Un trabajo programado necesita un plan para su propio fallo, no solo para lo que encuentra. Si el trabajo no puede ejecutarse en absoluto (una cola que se acumula, un proceso de trabajo que se cae, la infraestructura de la que depende que deja de funcionar), es una señal distinta y de mayor prioridad que el resultado de cualquier dominio concreto, porque significa que la red de seguridad se ha quedado en silencio sin que necesariamente nadie lo note. Una comprobación sencilla y separada de «¿se ejecutó el trabajo dentro de la ventana esperada?», que avise si una ejecución se retrasa, cierra esa brecha; de lo contrario, un sistema de supervisión que deja de supervisar en silencio es, sin duda, peor que no tener supervisión, porque genera una falsa confianza en que todo sigue vigilado.