Плановая проверка работоспособности DNS: как настроить

Разовая DNS-проверка показывает текущее состояние. Регулярная проверка по расписанию показывает, меняется ли это состояние, а изменение у домена, который вы не собирались трогать, обычно и стоит заметить быстро, а не обнаруживать спустя недели.

Что включить в проверку

Начните с того, где незамеченное изменение действительно имело бы значение: рабочие домены и их ключевые поддомены, домены, от которых зависит доставляемость почты, и всё, что находится в списке наблюдения по безопасности. Нет смысла планировать проверку для домена, на изменение которого никто не отреагирует: цель — сигнал, на который вы действительно будете реагировать, а не исчерпывающий журнал, который никто не читает.

Выбор периодичности

Что делать с результатами

Сама задача даёт лишь половину пользы; вторая половина — что происходит, когда результаты очередного запуска отличаются от предыдущего. Как минимум храните историю, достаточную для сравнения последовательных запусков (этот инструмент сохраняет историю запусков задач в течение настраиваемого срока хранения именно по этой причине). Экспорт результатов каждого запуска в CSV или JSON упрощает программное сравнение, вместо того чтобы полагаться на то, что кто-то заметит изменение на глаз в панели, которую он в тот день может и не открыть.

Когда расписание работает надёжно, на практике DNS-мониторинг превращается из эпизодической ручной задачи в фоновый процесс, который требует внимания только тогда, когда действительно есть на что смотреть, и в этом вся суть.

Проектируйте оповещение, а не только проверку

Плановая проверка, которая уведомляет при каждом запуске, даже когда ничего нового не найдено, за пару недель приучает людей её игнорировать, а это сводит на нет весь смысл. Полезный сигнал — именно изменение: разрешённые адреса этого запуска отличаются от прошлого, домен перешёл от успешного разрешения к сбою (или наоборот) или новый адрес попал в диапазон, который вообще не должен быть доступен. Если строить уведомление вокруг вопроса «что изменилось с прошлого раза», а не «вот сегодняшний результат», такое оповещение остаётся достойным внимания и через месяцы, а не превращается в очередное непрочитанное письмо во входящих.

Что происходит, когда сбоит сама проверка

У плановой задачи должен быть план на случай собственного сбоя, а не только на случай того, что она находит. Если задача вообще не может запуститься (очередь копится, процесс-воркер падает, отказывает инфраструктура, от которой она зависит), это отдельный и более приоритетный сигнал, чем результат любого отдельного домена: страховочная сетка замолчала, а никто, возможно, этого не заметил. Простая отдельная проверка «запускалась ли задача в ожидаемое окно» с оповещением о просроченном запуске закрывает этот пробел; иначе система мониторинга, молча переставшая следить, пожалуй, хуже полного отсутствия мониторинга, потому что создаёт ложную уверенность, что за всем по-прежнему наблюдают.