Доступность DNS-узла без latency — это полупроверка. Нужен полный контроль флоу
Пинг до хоста показывает только L3. Для DNS этого мало: клиент может получать ответы медленно, даже если ICMP проходит идеально. Давайте разберем флоу запроса: есть сеть, есть listener, есть очередь, есть сам ответ. Отвал любой ступени меняет картину.
Минимальный набор метрик для каждого узла:
— uptime сервиса и порта 53, отдельно для UDP и TCP
— RTT по реальному DNS-запросу, а не по ping
— доля timeouts и SERVFAIL
— размер очереди, saturation CPU и drops на интерфейсе
— расхождение ответа между anycast-нодами, если оно возможно
Проверка должна идти с нескольких точек: изнутри сети, с внешних резолверов и с соседних PoP. Иначе вы увидите не проблему DNS, а локальный маршрут или фильтрацию. Для latency полезны percentiles, а не среднее: p95 и p99 быстро показывают деградацию, которую среднее аккуратно прячет. Стабильность DNS — это фундамент, а не опция.
Если мониторите только доступность, инцидент обнаружите поздно. Если добавляете latency, таймауты и разбор по протоколам, у вас появляется реальная диагностика. Исключаем Human Error через автоматизацию и проверяем не «жив ли узел», а способен ли он отвечать в SLA.
Управление DNS инфраструктурой
@dns_management_flow_arb
Доступность DNS-узла без latency — это полупроверка. Нужен полный контроль флоу
Этот пост опубликован в Telegram-канале Управление DNS инфраструктурой. Подписаться можно по ссылке: @dns_management_flow_arb.