Рекурсивный резолвер тормозит не из-за DNS, а из-за плохой дисциплины запросов

Рекурсивный резолвер тормозит не из-за DNS, а из-за плохой дисциплины запросов

Давайте разберем флоу запроса. Основные точки потерь: лишние итерации, повторные обращения к одинаковым именам и слабый контроль кэша. Если резолвер не умеет агрессивно переиспользовать позитивные и негативные ответы, RTT растет почти без шансов на чудо.

Что обычно режут в первую очередь:
— размер и политику кэша, чтобы не вымывать горячие записи;
— минимизацию лишних рекурсий и одинаковых QNAME/QTYPE-поисков;
— rate limiting на клиентов, которые устраивают шторм из однотипных запросов;
— параллелизм к upstream-целям без превращения узла в генератор очередей.

Отдельно смотрим на отрицательный кэш и TTL. Слишком короткие значения дают лишнюю нагрузку на авторитативные серверы, слишком длинные — маскируют изменения и усложняют отладку. В нормальной схеме резолвер должен быстро отдавать повторяемые ответы и не тратить CPU на то, что уже известно.

Проверим влияние на RTT и консистентность зон: сначала измеряем hit ratio, затем смотрим очереди, потом — долю таймаутов и SERVFAIL. Если метрики не связаны с кэшем, ищите сетевую деградацию, а не лечите симптомы увеличением потоков. Стабильность DNS — это фундамент, а не опция.