Мониторинг DNS-узлов без иллюзий: доступность, RTT и ложные срабатывания

Мониторинг DNS-узлов без иллюзий: доступность, RTT и ложные срабатывания

Давайте разберем флоу запроса. Для мониторинга DNS-узла недостаточно проверить, что порт 53 отвечает: ICMP, TCP и UDP дают разную картину, а реальный клиентский запрос упирается еще и в маршрут, фильтрацию и состояние anycast-раскатки.

Минимальный набор проверок:
— UDP query на рабочую зону с валидным ответом;
— TCP fallback, если ответ фрагментируется или размер растет;
— измерение RTT по нескольким точкам сети, а не с одного NMS;
— контроль rcode, EDNS0 и присутствия ожидаемых NS/SOA.
Иначе вы мониторите не доступность, а собственную надежду.

Latency без контекста тоже бесполезна. Если смотреть только среднее значение, вы пропустите хвосты, которые и создают жалобы: рост очереди на резолвере, деградацию линка, перекос anycast-маршрутизации. Проверяем не только медиану, но и p95/p99, плюс разброс между площадками. Это помогает отделить локальную проблему от сетевого шума.

Ещё один слой — консистентность. Один и тот же узел может отвечать быстро, но отдавать устаревшую зону, если сломалась репликация или задержался reload. Стабильность DNS — это фундамент, а не опция. Поэтому алерт должен срабатывать не только на timeout, но и на аномалию содержимого ответа.

Итог простой: мониторинг DNS строится вокруг запроса, а не вокруг «жив ли хост». Исключаем Human Error через автоматизацию и проверяем влияние на RTT и консистентность зон.