Мониторинг DNS-узлов без RTT-шума: что проверять до первого инцидента

Давайте разберем флоу запроса. Для DNS мало знать, что порт 53 «отвечает»: узел может принимать пакеты, но деградировать по latency, терять UDP-фрагменты или упираться в локальный резолвер. Поэтому мониторинг строят в два слоя: доступность сервиса и качество ответа.

Минимальный набор проверок:
— UDP query к авторитетной зоне с фиксацией времени ответа
— TCP query как отдельный путь, а не «на всякий случай»
— контроль SERVFAIL, REFUSED и NXDOMAIN по эталонным именам
— сравнение RTT между anycast-нодами и точками измерения
— проверка SOA/NS consistency после изменений зоны

Стабильность DNS — это фундамент, а не опция. Если один узел отвечает быстро, а другой медленно, клиентский опыт ломается не по факту падения, а по хвостам latency. Учитывайте это в алертах: порог по SLA без распределения p95/p99 превращается в шумный будильник. Проверим влияние на RTT и консистентность зон.

Отдельно смотрите на источник метрики. Внешний probe видит сетевой путь целиком, внутренний — только сервер. Для anycast это критично: «живой» узел может быть недоступен из части сети из-за BGP, фильтрации или асимметрии маршрута. И да, ICMP-пинг к DNS почти всегда слишком грубый инструмент.

Исключаем Human Error через автоматизацию: одна и та же тестовая матрица для всех узлов, одинаковые имена, одинаковые таймауты, одинаковая интерпретация ответа. Тогда алерт говорит о проблеме, а не о фантазии мониторинга.