Рекурсивный резолвер тормозит не DNS, а лишняя работа внутри него

Рекурсивный резолвер тормозит не DNS, а лишняя работа внутри него

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

Базовая оптимизация выглядит скучно, и именно поэтому она работает:
— включить aggressive caching там, где это допустимо по TTL и политике;
— снизить повторные обращения через deduplication одинаковых qname/qtype;
— отделить «горячие» зоны от редких, чтобы не смешивать профиль нагрузки;
— держать разумные timeout/retry, иначе резолвер сам создает очередь.

Дальше смотрим на сеть. RTT до авторитетных серверов и кэширующих апстримов важнее красивых графиков CPU. Если резолвер ходит в разные Anycast-точки без контроля латентности, консистентность ответа падает, а хвосты задержек растут. Проверим влияние на RTT и консистентность зон: иногда проблема не в DNS-коде, а в маршрутизации и потере пакетов.

Не забывайте про лимиты: размер cache, число worker-потоков, conntrack, UDP buffer, max outstanding queries. Перекос в одну сторону дает либо memory pressure, либо «экономию» ценой очередей и таймаутов. Исключаем Human Error через автоматизацию: шаблоны конфигурации, тесты на синтетической нагрузке и контроль изменений перед раскаткой.

Итог простой: сначала режем лишние запросы и хвосты латентности, потом трогаем горизонтальное масштабирование. Так резолвер ускоряется без магии и без костылей.