Мониторинг DNS-узлов без RTT и health-check по одному флагу — это слепая зона

Мониторинг DNS-узлов без RTT и health-check по одному флагу — это слепая зона

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

Набор метрик должен быть раздельным:
— availability: UDP/TCP reachability, потери, ICMP как вспомогательный сигнал;
— latency: p50/p95/p99 по реальным query, а не по абстрактному ping;
— correctness: SERVFAIL, REFUSED, timeout, NXDOMAIN;
— consistency: одинаковый ответ с разных точек и отсутствие «плавающих» зон.

Важно мерить не только снаружи, но и между anycast-площадками и автораторами. Узел может быть доступен из одного сегмента сети и терять пакеты из другого. Для этого нужны синтетические запросы к конкретным именам, часть из которых есть в кэше, а часть должна идти до авторитативной зоны. Проверим влияние на RTT и консистентность зон — без этого мониторинг превращается в коллекцию красивых графиков.

Исключаем Human Error через автоматизацию: алерты должны срабатывать на комбинацию признаков, а не на один всплеск. Стабильность DNS — это фундамент, а не опция. Если у узла выросла задержка и одновременно пошли таймауты, его надо выводить из маршрутизации до анализа причины, а не ждать «само пройдет».