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

Давайте разберем флоу запроса. На практике сравнивают не «кто быстрее вообще», а кто быстрее в конкретной роли: authoritative, recursive или service discovery.

• Bind9 — универсален, но тяжелее по памяти и логике обработки. На больших зонах и сложных ACL он предсказуем, но не всегда самый экономный по CPU.
• Unbound — обычно сильнее в рекурсии: агрессивный кеш, нормальная работа с DNSSEC, хорошая стабильность под смешанной нагрузкой.
• CoreDNS — удобен как склейка плагинов и сервисный резолвер, но производительность сильно зависит от набора плагинов и количества цепочек обработки.

Ключевая ошибка — сравнивать их по одному synthetic QPS. Нужны минимум три сценария: холодный кеш, горячий кеш и деградированный путь с промахами и внешними апстримами. Проверим влияние на RTT и консистентность зон: у Bind9 узкое место чаще в конфигурационной сложности, у Unbound — в размере кеша и паттерне запросов, у CoreDNS — в лишней логике на каждый lookup.

Если нужен authoritative для классических зон — Bind9 остается рабочей лошадью. Если нужна рекурсия с упором на кеш и предсказуемую задержку — Unbound обычно рациональнее. Если строится внутренняя DNS-склейка для Kubernetes и сервисов — CoreDNS уместен, но его нельзя нагружать как универсальный комбайн без расчета цепочки плагинов.

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