<b>Оптимизация рекурсивного резолвера начинается не с кеша, а с контроля флоу запроса</b>

<b>Оптимизация рекурсивного резолвера начинается не с кеша, а с контроля флоу запроса</b>

Давайте разберем флоу запроса. На рекурсоре обычно теряются не миллисекунды, а дисциплина: лишние апстримы, слабый кеш, агрессивные таймауты и отсутствие границ между клиентским и апстрим-трафиком. Стабильность DNS — это фундамент, а не опция.

Что реально снижает нагрузку:
— разделение cache hit и cache miss в метриках;
— минимизация обращений к корневым и авторитетным серверам через нормальный negative caching;
— ограничение рекурсии для локальных сетей, а не для всего мира;
— fail-open/fail-closed политика должна быть осознанной, а не «как получилось».

Отдельно смотрим на RTT и консистентность зон. Если кеш живет слишком мало, резолвер превращается в генератор лишних запросов. Если слишком долго — получаете устаревшие ответы и странные эффекты после изменений в зоне. Баланс держится на TTL, prefetch и корректной обработке serve-stale, а не на надежде, что «пройдет само». Исключаем Human Error через автоматизацию.

Ещё один слой — защита самого резолвера: RRL для входящих, лимиты на concurrency, изоляция control-plane и data-plane, обязательный мониторинг SERVFAIL/NXDOMAIN долей. Если эти метрики не видны, вы оптимизируете вслепую.

Практика простая: сначала измеряем, потом режем шум, и только потом трогаем кеш-политику. Иначе ускорение одной точки просто переносит проблему в следующую.