Оптимизация рекурсивного резолвера начинается не с магии, а с контроля очередей и кэша

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

Практический минимум:
— держите cache hit ratio отдельно для позитивных и негативных ответов;
— контролируйте outbound concurrency и очереди на upstream;
— проверяйте TTL у популярных зон: слишком маленький TTL убивает кэш, слишком большой усложняет ротацию;
— включайте prefetch и serve-stale только после оценки влияния на консистентность.

Отдельно смотрим на транспорт. Для апстримов важны таймауты, keepalive и балансировка между IPv4/IPv6, иначе резолвер сам себе создает лишнюю латентность. Если есть Anycast, проверяйте не только reachability, но и стабильность маршрутизации: краткие флаппинги дают всплески ретраев и ухудшают RTT сильнее, чем кажется по графикам.

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