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

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

Давайте разберем флоу запроса. Большая часть потерь сидит не в самом lookup, а в лишних походах за данными: лишняя рекурсия, короткий TTL, повторные NXDOMAIN и отсутствие кеша на отрицательные ответы.

Что обычно режет производительность:
— cache miss на популярных именах из-за слишком малого TTL;
— запросы к одинаковым зонам без агрегации и prefetch;
— отсутствие лимитов на QPS и per-client throttling;
— слишком длинные цепочки CNAME и делегирования;
— разные политики кеширования для IPv4 и IPv6, которые ломают консистентность.

Проверим влияние на RTT и консистентность зон: оптимизация начинается с локального кеша, затем с контроля stale data, затем с разнесения upstream’ов по латентности и отказоустойчивости. Anycast здесь помогает только если сам резолвер не превращен в помойку из разношерстных правил и ручных исключений.

Исключаем Human Error через автоматизацию: политики TTL, ACL, rate limiting и health-check для upstream должны жить в конфиге, а не в памяти дежурного инженера. Стабильность DNS — это фундамент, а не опция.