Bind9, Unbound и CoreDNS: где теряется RTT и кто быстрее под нагрузкой

Bind9, Unbound и CoreDNS: где теряется RTT и кто быстрее под нагрузкой

Давайте разберем флоу запроса. С точки зрения производительности сравнивают не «самый быстрый DNS вообще», а конкретную роль: авторитативный сервер, рекурсор или гибрид. Здесь и начинаются типовые ошибки, когда Bind9 пытаются заставить быть всем сразу, а потом удивляются очередям, cache miss и лишним системным вызовам.

Bind9 — тяжелее по профилю, но предсказуем. Он силён как авторитативный сервер и умеет нормально жить в сложной зоне, ACL, views и динамике. Цена — больше памяти и более заметная чувствительность к неудачной настройке thread/cache/io. Если его перегрузить рекурсией, получите не «медленный DNS», а медленную архитектуру.

Unbound — рекурсор с хорошей дисциплиной кэша и DNSSEC, обычно выигрывает на запросах с повторяемостью. Он меньше склонен к лишней универсальности и лучше держит стабильный latency при нормальном размерe cache и корректных таймаутах. Но чудес нет: плохая сеть до апстрима убьёт его быстрее, чем любой бенчмарк успеет порадовать графиком. ⚙️

CoreDNS — не конкурент Bind9 как классический authoritative-first DNS, а удобный конструктор для Kubernetes и сервисной инфраструктуры. Производительность упирается в цепочку плагинов: чем больше логики в middleware, тем больше CPU и RTT. В простом сценарии он быстрый; в перегруженном — превращается в набор взаимных ожиданий между плагинами.

Стабильность DNS — это фундамент, а не опция. Проверим влияние на RTT и консистентность зон: Bind9 берут за предсказуемую авторитативность, Unbound — за рекурсивный кэш, CoreDNS — за интеграцию и гибкость. Выбирайте роль, а не «самый быстрый пакет», и исключайте Human Error через автоматизацию.