Мониторинг DNS-узлов: доступность без RTT — это слепая зона в проде

Проверять только порт 53 недостаточно. Узел может отвечать на TCP/UDP, но отдавать ответы с деградацией по пути: перегруженный CPU, очередь в резолвере, loss на линке, асимметрия маршрута. Для DNS важны два слоя: liveness и service-level latency.

Собирайте минимум три метрики:
— reachability: UDP/TCP probe до 53 порта;
— response time: p50/p95/p99 по типам запросов;
— answer quality: SERVFAIL, timeout, truncation, unexpected NXDOMAIN.
Если метрика есть только одна, вы мониторите наличие процесса, а не качество сервиса. Стабильность DNS — это фундамент, а не опция.

Для anycast-сетей отдельно смотрите флоу запроса: клиент может попасть на живой узел, но через плохой маршрут. Считайте RTT с нескольких точек, сравнивайте отклонения между PoP и отслеживайте резкие расхождения. Проверим влияние на RTT и консистентность зон: высокий latency часто всплывает раньше полного отказа.

Не смешивайте health-check для балансировки и мониторинг для эксплуатации. Первый должен быть максимально дешёвым, второй — имитировать реальные запросы, включая DNSSEC, большие ответы и разные типы RR. Исключаем Human Error через автоматизацию.

Если у вас нет latency-алертов по DNS, у вас есть только надежда, что пользователи не заметят деградацию раньше вас.