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

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

Давайте разберем флоу запроса. Для DNS мало проверять «пингуется/не пингуется»: ICMP может жить отдельно от UDP/53, а TCP-резерв часто вспоминают уже после инцидента. Нужны как минимум три сигнала: ответ на DNS-query, время ответа и доля ошибок по каждому anycast-узлу.

Слепая метрика «uptime» без latency полезна только для отчета. Узел может отвечать, но с деградацией: рост RTT, очереди на socket, потеря пакетов на пути, перегрузка resolver-side cache. Проверяйте p50/p95/p99 отдельно и сравнивайте их между площадками, а не усредняйте по кластеру — среднее красиво, но бесполезно для диагностики.

Практика без костылей выглядит так:
— health-check с реальным A/AAAA/TXT-запросом;
— отдельный тест UDP и TCP;
— контроль SERVFAIL, timeout и truncation;
— разнесение метрик по PoP и upstream-пути;
— алерт не по факту падения, а по тренду задержки и росту ошибок. 🔧

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