Configurare un controllo DNS pianificato

Un singolo lookup DNS ti dice lo stato attuale. Un lookup pianificato e ricorrente ti dice se quello stato sta cambiando, e il cambiamento, per un dominio che non ti aspetti di modificare attivamente, è di solito la cosa da sapere subito invece di scoprirla settimane dopo.

Decidere cosa includere

Parti da tutto ciò per cui una modifica passata inosservata avrebbe davvero conseguenze: i domini di produzione e i loro sottodomini chiave, i domini legati alla recapitabilità della posta e tutto ciò che si trova in una watchlist di sicurezza. Pianificare un controllo per un dominio sul quale nessuno agirebbe in caso di modifica serve a poco: l'obiettivo è un segnale a cui risponderai davvero, non un registro completo che nessuno legge.

Scegliere la frequenza

Cosa fare con i risultati

Il job in sé vale solo metà: l'altra metà è ciò che succede quando i risultati di un'esecuzione differiscono da quelli della precedente. Come minimo, conserva abbastanza storico da confrontare esecuzioni consecutive (questo strumento conserva lo storico delle esecuzioni dei job per una finestra di retention configurabile proprio per questo motivo). Esportare i risultati di ogni esecuzione in CSV o JSON rende semplice confrontarli in modo programmatico, invece di contare sul fatto che qualcuno noti a occhio una modifica in una dashboard che quel giorno potrebbe anche non aprire.

Quando una pianificazione funziona in modo affidabile, l'effetto pratico è trasformare il monitoraggio DNS da attività manuale occasionale a processo in background che richiede attenzione solo quando c'è davvero qualcosa da guardare, ed è esattamente lo scopo.

Progettare l'avviso, non solo il controllo

Un controllo pianificato che invia una notifica a ogni singola esecuzione, anche a quelle che non hanno trovato nulla di nuovo, abitua le persone a ignorarlo nel giro di un paio di settimane, vanificando l'intero scopo. Il segnale utile è specificamente il cambiamento: gli indirizzi risolti in questa esecuzione sono diversi da quelli dell'ultima, un dominio è passato dal risolversi al fallire (o viceversa) oppure un nuovo indirizzo è finito in un intervallo che non dovrebbe essere affatto raggiungibile. Costruire la notifica attorno a «cosa è cambiato dall'ultima volta» invece che a «ecco il risultato di oggi» è ciò che rende l'avviso degno di essere aperto anche dopo mesi, invece di diventare l'ennesima etichetta non letta in una casella di posta.

Cosa succede quando a fallire è il controllo stesso

Un job pianificato ha bisogno di un piano per il proprio guasto, non solo per ciò che trova. Se il job non riesce a girare affatto (una coda che si accumula, un processo worker che va in crash, l'infrastruttura da cui dipende che va giù) è un segnale distinto e di priorità più alta rispetto al risultato di un singolo dominio, perché significa che la rete di sicurezza stessa si è zittita senza che necessariamente qualcuno se ne accorga. Un semplice controllo separato che verifichi se il job è stato eseguito nella finestra prevista, con un avviso se un'esecuzione è in ritardo, colma questa lacuna; altrimenti un sistema di monitoraggio che smette in silenzio di monitorare è probabilmente peggio di nessun monitoraggio, perché crea la falsa sicurezza che tutto sia ancora sotto osservazione.