<b>Мониторинг DNS-узлов: без него вы узнаете о падении позже клиентов</b>

<b>Мониторинг DNS-узлов: без него вы узнаете о падении позже клиентов</b>

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

Минимальный набор проверок:
— UDP/53: отвечает ли авторитативный сервер на типовой запрос;
— TCP/53: жив ли fallback для крупных ответов и DNSSEC;
— SOA/NS: корректна ли зона и не выпала ли репликация;
— RTT: нет ли роста задержки по сравнению с базовой линией;
— packet loss: DNS очень плохо переносит потери, потому что ретраи быстро съедают SLA.

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

Технически полезно разделять synthetic checks и реальные логи резолверов: первые показывают симптом, вторые — нагрузку и паттерн отказов. Стабильность DNS — это фундамент, а не опция. Если мониторинг не различает «не отвечает» и «отвечает медленно», это не мониторинг, а дорогая иллюзия.