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

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

Давайте разберем флоу запроса. Клиенту не важно, жив ли сервер по ping; ему важно, отвечает ли авторитативный узел на 53/UDP и 53/TCP с приемлемым RTT. Поэтому мониторинг должен разделять три сигнала: reachability сети, успешный DNS-ответ и латентность ответа.

Базовый набор проверок:
— UDP query к реальной зоне, а не к пустому корню;
— TCP fallback, иначе не увидите проблемы с фрагментацией и large responses;
— latency по p50/p95, а не только «ответил/не ответил»;
— разные источники проверок, чтобы не спутать отказ узла с деградацией маршрута.

Если мерить только ICMP, получите ложное чувство контроля. Если мерить только синтетический query из одной точки, пропустите региональные проблемы Anycast и перекосы BGP. Нужны как минимум несколько vantage points и алерты по сочетанию: рост RTT, рост timeout rate, падение доли NOERROR, а не один красный индикатор на все случаи жизни.

Отдельно проверяйте консистентность зон: SOA serial, nsset, время ответа между узлами, наличие SERVFAIL и REFUSED. Иначе мониторинг будет бодро сообщать, что «сервер жив», пока часть клиентов уже уходит в ретраи и кэширует мусор.

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