Оптимизация рекурсивного резолвера: где теряются миллисекунды и стабильность

Оптимизация рекурсивного резолвера: где теряются миллисекунды и стабильность

Давайте разберем флоу запроса. Рекурсивный резолвер тратит время не на «поиск DNS», а на лишние походы: повторные обращения к авторитетам, слабый кеш и неудачную работу с таймаутами. Если кеш не прогревается, а отрицательные ответы живут слишком мало, нагрузка растет лавинообразно.

Что обычно правят в первую очередь:
— размер и политика кеша для положительных и отрицательных ответов;
— QNAME minimization и агрессивное использование кеша там, где это уместно;
— parallel queries к нескольким upstream, если есть риск деградации одного пути;
— контроль TCP fallback и лимитов на outstanding запросы.

Отдельная зона риска — таймауты и retry logic. Слишком короткие значения дают ложные отказы при нормальной сетевой джиттерной картине, слишком длинные превращают резолвер в очередь ожидания. Проверим влияние на RTT и консистентность зон: нужен баланс между быстрым failover и отказом от лишних повторов.

Не забывайте про locality: anycast без аккуратного health-check и синхронизации кеша может улучшить латентность, но ухудшить предсказуемость. Исключаем Human Error через автоматизацию: конфигурация, лимиты, ACL и метрики должны жить в одном контуре контроля.

Стабильность DNS — это фундамент, а не опция. Если резолвер начал «экономить» на кешировании и таймаутах, он просто переложил стоимость на апстрим и пользователей.