Bind9, Unbound и CoreDNS: где реально теряется производительность DNS

Bind9, Unbound и CoreDNS: где реально теряется производительность DNS

Давайте разберем флоу запроса. Bind9 чаще выбирают как авторитетный сервер: он стабильно держит зону, но при высоком QPS чувствителен к конфигурации, размеру ответов и очередям. Unbound — рекурсор с агрессивным кэшем и нормальной деградацией под нагрузкой. CoreDNS — модульный, хорошо масштабируется в контейнерных и service discovery-сценариях, но не магия: плагины и цепочка обработки тоже добавляют задержку.

По производительности сравнивают не «кто быстрее вообще», а где именно узкое место:
— Bind9: хорош на authoritative workload, но требует аккуратной настройки worker-потоков и кэша;
— Unbound: обычно выигрывает на рекурсивных запросах за счет кеширования и prefetch;
— CoreDNS: силен в коротком пути до ответа, если конфигурация не превращена в комбайн из плагинов.

Если мерить честно, смотрим не только latency, но и tail latency, hit ratio кэша, поведение при NXDOMAIN, TCP fallback и CPU на пике. Слабое место часто не сам движок, а логика вокруг него: длинные цепочки пересылки, лишняя DNSSEC-валидация на перегруженном рекурсоре, кривые TTL и отсутствие local cache. Проверим влияние на RTT и консистентность зон: иногда «медленный DNS» — это просто плохо спроектированный путь запроса.

Выбор простой: Bind9 — для authoritative и контроля над зоной, Unbound — для рекурсии и кеша, CoreDNS — для динамической среды, где важна интеграция. Исключаем Human Error через автоматизацию и тестируем под своим профилем запросов, а не по чужим бенчмаркам.