Оптимизация рекурсивного резолвера начинается не с тюнинга, а с измерения флоу запросов

Оптимизация рекурсивного резолвера начинается не с тюнинга, а с измерения флоу запросов

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

Дальше смотрим на базовые рычаги:
— кэширование: отрицательный и положительный кэш должны жить по своим TTL, а не по надежде на удачу;
— параллелизм: ограниченный, но достаточный, иначе получите очередь и рост latency;
— upstream selection: меньше случайных прыжков, больше предсказуемости;
— лимиты на UDP/TCP: без них резолвер превращается в генератор деградации.

Отдельно проверяем поведение при промахах кэша и отказах авторитативов. Если резолвер слишком охотно ретраит, он раздувает RTT и создаёт лишнюю нагрузку на сеть. Если слишком рано сдаётся — клиент видит SERVFAIL там, где должен был дождаться ответа. Посмотрим, что говорит по этому поводу RFC: корректная деградация важнее героизма.

Исключаем Human Error через автоматизацию: шаблоны ACL, единые таймауты, контроль конфигурации и регулярный разбор метрик по hit ratio, qps, SERVFAIL и p95 latency. Оптимизировать резолвер надо так, чтобы он предсказуемо переживал плохие дни, а не красиво выглядел в спокойной лаборатории.