Mettre en place un contrôle de santé DNS planifié

Une recherche DNS ponctuelle vous donne l'état actuel. Une recherche planifiée et récurrente vous dit si cet état change, et un changement, pour un domaine que vous ne comptez pas modifier activement, est généralement ce qu'il vaut mieux savoir vite plutôt que de le découvrir des semaines plus tard.

Décider quoi inclure

Commencez par tout ce pour quoi un changement passé inaperçu aurait réellement de l'importance : les domaines de production et leurs sous-domaines clés, les domaines liés à la délivrabilité des e-mails et tout ce qui figure sur une liste de surveillance de sécurité. Planifier une vérification pour un domaine dont personne n'agirait en cas de changement n'a guère d'intérêt : l'objectif est un signal auquel vous réagirez réellement, pas un journal exhaustif que personne ne lit.

Choisir une fréquence

Que faire des résultats

La tâche elle-même ne représente que la moitié de la valeur : l'autre moitié, c'est ce qui se passe quand les résultats d'une exécution diffèrent de la précédente. Conservez au minimum assez d'historique pour comparer des exécutions consécutives (cet outil conserve l'historique des exécutions de tâches pendant une durée de rétention configurable précisément pour cette raison). Exporter les résultats de chaque exécution en CSV ou en JSON permet de les comparer facilement par programme, plutôt que de compter sur quelqu'un qui remarquerait un changement à l'œil nu dans un tableau de bord qu'il consulte ou non ce jour-là.

Une fois qu'un calendrier tourne de façon fiable, l'effet pratique est de transformer la surveillance DNS, d'une tâche manuelle occasionnelle, en un processus d'arrière-plan qui ne réclame votre attention que lorsqu'il y a réellement quelque chose à examiner, et c'est exactement le but.

Concevoir l'alerte, pas seulement la vérification

Une vérification planifiée qui notifie à chaque exécution, même celles qui n'ont rien trouvé de nouveau, habitue les gens à l'ignorer en quelques semaines, ce qui ruine tout son intérêt. Le signal utile, c'est précisément le changement : les adresses résolues de cette exécution diffèrent de celles de la précédente, un domaine est passé de la résolution à l'échec (ou l'inverse), ou une nouvelle adresse est apparue dans une plage qui ne devrait pas être joignable du tout. Construire la notification autour de « ce qui a changé depuis la dernière fois » plutôt que de « voici le résultat du jour » est ce qui garde l'alerte digne d'être ouverte des mois plus tard, au lieu de devenir un énième libellé non lu dans une boîte de réception.

Que se passe-t-il quand la vérification elle-même échoue

Une tâche planifiée a besoin d'un plan pour sa propre défaillance, pas seulement pour ce qu'elle trouve. Si la tâche ne peut pas s'exécuter du tout (file d'attente qui s'engorge, processus worker qui plante, infrastructure sous-jacente qui tombe), c'est un signal distinct et plus prioritaire que le résultat de n'importe quel domaine, car cela signifie que le filet de sécurité lui-même s'est tu sans que personne s'en aperçoive forcément. Une vérification simple et séparée, « la tâche s'est-elle bien exécutée dans la fenêtre attendue », qui alerte si une exécution est en retard, comble cette lacune ; sinon, un système de surveillance qui cesse silencieusement de surveiller est sans doute pire que pas de surveillance du tout, puisqu'il crée la fausse assurance que tout est encore sous contrôle.