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

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

Доступность DNS — это не только ответ «есть/нет». Для резолвера важно, отвечает ли узел стабильно, укладывается ли в RTT и не деградирует ли по пути. Если метрика смотрит только на ICMP или TCP-порт 53, вы получаете картину для отчёта, а не для эксплуатации.

Давайте разберем флоу запроса. Минимальный набор проверок:
— UDP-запрос к авторитетному узлу;
— TCP-fallback для больших ответов и DNSSEC;
— выборка RTT по нескольким PoP или регионам;
— доля SERVFAIL, REFUSED и timeout, а не только success rate;
— корреляция с packet loss и jitter на сети.

Отдельно измеряйте latency по типам ответов: A/AAAA, NS, SOA, DNSKEY. Тяжёлые зоны ведут себя иначе, чем «лёгкие» записи, а anycast без контроля распределения трафика быстро превращается в красивую схему с плохим хвостом задержек. Проверим влияние на RTT и консистентность зон: один узел может быть доступен, но отдавать устаревшую или частично синхронизированную зону.

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