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

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

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

Что обычно режет производительность:
— слишком короткий negative TTL: одни и те же несуществующие имена снова уходят в сеть;
— слабая агрегация запросов: несколько клиентов одновременно бьют в один и тот же FQDN;
— неотстроенные лимиты по параллелизму и очередям;
— слишком агрессивные retry-политики, которые множат трафик вместо восстановления.

Оптимизация начинается с кеша: держите его достаточно большим для горячего набора, но без иллюзий, что он заменит архитектуру. Важнее контролировать serve-stale, prefetch и минимизировать fan-out к авторитативным серверам. Проверим влияние на RTT и консистентность зон: если latency растет, а hit ratio падает, вы лечите симптомы, а не причину.

Отдельно смотрите на EDNS0, DNSSEC и размер ответов: фрагментация и TCP fallback быстро превращают «рекурсию» в очередь ожидания. Исключаем Human Error через автоматизацию: метрики cache hit, upstream RTT, servfail rate и долю TCP-запросов должны быть в одном дашборде.

Если резолвер начал «думать», сначала ищите лишние обращения и таймауты, потом уже крутите кеш и параллелизм.