DNS-узел может отвечать, но уже быть плохим. Это ловится мониторингом, а не надеждой.

DNS-узел может отвечать, но уже быть плохим. Это ловится мониторингом, а не надеждой.

Давайте разберем флоу запроса. Для клиента важны два параметра: доступность резолвера и задержка до ответа. Если health-check смотрит только на ping или TCP/53, он пропускает деградацию: очередь запросов растет, CPU упирается в рекурсию, а RTT уезжает вверх без полного отказа.

Набор проверок должен быть раздельным:
— сетевой reachability: ICMP, TCP/UDP 53, отсутствие фильтрации;
— прикладной ответ: запрос к конкретной зоне с ожидаемым RCODE;
— latency: p50/p95 по разным площадкам и протоколам;
— consistency: одинаковый ответ от всех anycast-узлов и отсутствие stale data.

Смотрите не на один график, а на связку. Рост RTT при нормальном up/down — типичный признак перегруза, асимметрии маршрута или проблем с кешем. Падение доступности на одном POP при норме на остальных — уже повод проверять BGP, локальный firewall и состояние демона. Для DNS это особенно важно: один «живой» узел с плохой задержкой иногда вреднее, чем честно снятый с балансировки.

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