<b>Рекурсивный резолвер тормозит не из-за DNS, а из-за плохой механики кеша</b>

<b>Рекурсивный резолвер тормозит не из-за DNS, а из-за плохой механики кеша</b>

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

Что проверять в первую очередь:
— размер и политики кеша: LRU без контроля заполнения быстро превращается в декоративную функцию;
— минимальные TTL и floor/ceiling: слишком низкие значения убивают повторное использование ответов;
— prefetch, serve-stale, negative caching: эти механизмы снижают пик задержек, если они включены осознанно, а не «для галочки».

Отдельно смотрим на EDNS buffer size, rate limiting и количество параллельных исходящих запросов. Неверные значения здесь дают фрагментацию, ретраи и лишнюю латентность. Ещё один классический костыль — общая рекурсия без разделения клиентов по пулам: один шумный источник забивает все очереди.

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