На VDS DNS часто становится «скрытой» точкой отказа: медленный резолв добавляет задержку к каждому исходящему запросу (обновления пакетов, API, базы, почта), а неудачная схема кэширования приводит к плавающим таймаутам. Поэтому вопрос «CoreDNS vs dnsmasq vs Unbound» — это не про вкусовщину, а про правильный выбор роли: локальный кэш, полноценный рекурсивный резолвер или DNS-слой для контейнеров/сервисов.
Ниже — практическое сравнение трёх популярных вариантов: dnsmasq (лёгкий кэширующий форвардер), Unbound (рекурсивный резолвер и кэш) и CoreDNS (модульный DNS-сервер с цепочкой плагинов). Отдельно разберём типовые кейсы: local DNS cache, улучшение DNS performance, split DNS и замена systemd-resolved без сюрпризов.
Какие задачи решает DNS на VDS: сначала определяем роль
Перед выбором софта важно сформулировать, какую роль должен играть DNS на сервере или в инфраструктуре. На практике чаще всего встречаются четыре сценария:
- Локальный кэш для самого сервера: сократить задержки и зависимость от внешних резолверов.
- Рекурсивный резолвер для вашей инфраструктуры: несколько VDS/контейнеров используют один управляемый DNS.
- Форвардинг по зонам + split DNS: внутренние домены резолвим через VPN/внутренние DNS, остальное — наружу.
- DNS как часть платформы: сервис-дискавери, динамика, интеграции, метрики.
Если роли не разделить, легко промахнуться: например, поставить форвардер там, где нужна строгая рекурсия и DNSSEC-валидация, или тащить CoreDNS на одиночный сервер, где достаточно Unbound.
Краткая характеристика: кто есть кто
dnsmasq
dnsmasq — лёгкий кэширующий DNS-форвардер (плюс DHCP/TFTP, но на VDS обычно нужен только DNS). Он принимает запросы от клиентов и пересылает их на upstream-резолверы, сохраняя ответы в кэше. Сильные стороны: простота, минимальная конфигурация, низкое потребление ресурсов.
Типичный кейс: быстрый локальный DNS-кэш на одном сервере или простые правила форвардинга по зонам.
Unbound
Unbound — полноценный recursive resolver и один из самых практичных вариантов для собственного рекурсивного DNS на Linux. Может работать как форвардер или как рекурсор «до корня», поддерживает DNSSEC-валидацию, гибкие политики приватности и кэширование (включая негативный кэш для NXDOMAIN и ошибок).
Если нужен предсказуемый «DNS как сервис» для одной или нескольких машин, Unbound обычно даёт наиболее стабильный результат.
CoreDNS
CoreDNS — модульный DNS-сервер, где конфигурация — это цепочка плагинов. Он особенно известен как DNS-компонент Kubernetes, но может быть полезен и вне K8s: как внутренний DNS для зон, как DNS-прокси, как слой с логированием и метриками.
Важный нюанс: CoreDNS часто выбирают не как «универсальный рекурсор на всё», а как удобный конструктор внутренней DNS-логики (зоны, маршрутизация, наблюдаемость) с форвардингом на более специализированный резолвер.
CoreDNS vs Unbound: где проходит граница
Запрос «CoreDNS vs Unbound» появляется, когда хочется «один DNS на всё». На практике граница обычно такая:
- Unbound — когда приоритет: предсказуемая рекурсия, сильный кэш, DNSSEC, безопасные дефолты для резолвинга интернета.
- CoreDNS — когда приоритет: внутренние зоны, логика маршрутизации, интеграции, метрики и удобная расширяемость плагинами.
Частая рабочая схема на VDS (особенно с контейнерами): CoreDNS обслуживает внутренние зоны и форвардит наружу в Unbound, а Unbound отвечает за рекурсивный резолв и кэширование «в интернет».
Если нужен «просто быстрый и надёжный DNS для интернета» — начинайте с Unbound. Если нужен «DNS как часть платформы» — смотрите CoreDNS, часто в связке с Unbound.
dnsmasq vs Unbound: когда простота важнее, а когда — нет
Сравнение «dnsmasq vs Unbound» обычно упирается в требования к контролю, безопасности и диагностике:
- dnsmasq выигрывает, когда нужен быстрый старт: локальный кэш, простые правила, минимум настроек.
- Unbound выигрывает, когда важны: DNSSEC-валидация, тонкая настройка кэша, защита от нестабильных upstream, стабильность под нагрузкой и роль центрального резолвера.
На одиночной VDS dnsmasq может быть «достаточным», но у него меньше рычагов контроля. Когда начинаются разборы инцидентов «почему иногда 5–10 секунд не резолвится домен», преимущества Unbound становятся заметнее.
Производительность: что реально влияет на DNS performance
Скорость DNS — это не только скорость демона, но и характеристики цепочки резолвинга:
- Латентность upstream (если вы форвардите).
- Качество кэша и политика TTL (включая негативный кэш).
- Конкурентность и поведение при параллельных запросах.
- Стабильность при деградации сети: таймауты, ретраи, отказоустойчивость.
Практически:
- Unbound обычно даёт наиболее предсказуемую картину для кэша и рекурсии, особенно если настроить несколько upstream и политику таймаутов (или включить рекурсию «до корня» там, где это допустимо).
- dnsmasq хорошо ускоряет типовые запросы за счёт кэша, но зависимость от upstream ощущается сильнее, а инструментов «жёсткой» политики меньше.
- CoreDNS может быть быстрым, но итог зависит от цепочки плагинов: лишние плагины и логирование на каждый запрос легко превращаются в «узкое место».
Split DNS (split horizon): где проще жить
Под split DNS обычно понимают ситуацию, когда часть доменов должна резолвиться «внутрь» (VPN, приватные зоны, сервисы), а всё остальное — через обычный интернет-DNS. На VDS это типовая история для админских доменов, мониторинга и внутренних API.
Что выбрать по удобству:
- dnsmasq: отлично подходит для простых правил «эту зону форвардь туда», особенно на VPN-шлюзах и jump-серверах.
- Unbound: удобен, если split DNS — часть строгой DNS-политики (локальные зоны, контроль приватных диапазонов, DNSSEC, явные правила).
- CoreDNS: особенно хорош, когда split DNS завязан на сервисы/кластер, и нужна управляемая «логика маршрутизации» плюс наблюдаемость.
Критерий выбора простой: пара суффиксов для VPN — берите dnsmasq или Unbound. Много зон, динамика, сервисы — CoreDNS может быть удобнее как «DSL для DNS».
Альтернатива systemd-resolved: что ставить на сервер
Желание заменить systemd-resolved чаще всего появляется, когда не нравится stub-резолвер на 127.0.0.53, «магия» с источниками DNS, или хочется управляемый кэш с понятным поведением. Для VDS обычно выбирают один из двух сценариев:
- Простой локальный кэш без сложных политик: dnsmasq — самый быстрый путь.
- Контроль + рекурсия + DNSSEC и перспектива роста: Unbound — наиболее универсален.
Если вы строите инфраструктуру на базе VDS и хотите единообразный DNS-слой на всех узлах, Unbound обычно проще стандартизировать: один подход к кэшу, логике форвардинга по зонам и отладке.
Типовые архитектуры на VDS (без усложнений)
1) Один сервер: local DNS cache для исходящих запросов
Цель: уменьшить задержки и количество внешних DNS-запросов. Это типовой сценарий для веб-сервера, CI-раннера, бэкап-ноды.
- dnsmasq: быстро и просто.
- Unbound: если хотите более предсказуемо и «с запасом» (политики, DNSSEC, диагностика).
2) Несколько серверов: общий резолвер для приватной сети
Цель: единая DNS-политика для нескольких VDS (внутренние домены, кэш, контроль). Практичный вариант — Unbound в роли центрального резолвера плюс резервный второй экземпляр (или второй сайт/узел).
3) Контейнеры/оркестрация: внутренние зоны + форвардинг наружу
Цель: сервис-дискавери, внутренние имена, правила по зонам, наблюдаемость. Здесь CoreDNS часто закрывает «внутреннюю» часть, а Unbound становится upstream для рекурсивного резолва и кэша.
Наблюдаемость и отладка: что удобнее в эксплуатации
Эксплуатация DNS — это не только «оно отвечает», но и «почему оно перестало отвечать»:
- CoreDNS удобен, когда важны метрики и управляемость цепочки обработки (плагины, логирование, интеграции).
- Unbound хорош, когда вы хотите контролируемую рекурсию и понятные политики безопасности/кэша.
- dnsmasq прост, но глубокой диагностики меньше: нередко проблема оказывается в upstream, а инструментов, чтобы «дожать» политику, не хватает.
Для быстрой проверки DNS на сервере держите под рукой минимальный набор команд:
resolvectl status
getent hosts example.com
dig +time=2 +tries=1 example.com
ss -lntup | grep -E '(:53\b)'
journalctl -u systemd-resolved --no-pager -n 200Если вы ушли от systemd-resolved, замените строку с resolvectl на просмотр логов и статуса вашего демона (dnsmasq/unbound/coredns), но принцип тот же: проверить путь резолва, таймауты и порт 53 (TCP и UDP).
Шпаргалка выбора
- Нужен local DNS cache на одном сервере → dnsmasq или Unbound (если важнее контроль и DNSSEC).
- Нужен recursive resolver для нескольких узлов → Unbound.
- Нужен split DNS по зонам → dnsmasq (просто), Unbound (гибко и строго), CoreDNS (если это часть платформы).
- Нужна альтернатива systemd-resolved без сюрпризов → чаще Unbound (с перспективой) или dnsmasq (минимализм).
- Нужен DNS-слой для микросервисов/кластеров → CoreDNS, нередко в паре с Unbound.
Частые ошибки при выборе и настройке
Несколько типовых «граблей» для VDS:
- Пытаться решить всё одним форвардером: когда нужна рекурсия и строгая политика, форвардинг на «случайные» upstream часто даёт нестабильность.
- Оставлять один upstream: при проблемах у провайдера DNS получите таймауты у приложений, хотя сеть «вроде работает».
- Игнорировать негативный кэш (NXDOMAIN/ошибки): неверная политика может усилить последствия временных сбоев.
- Смешивать внутренние и внешние зоны без явных правил: так рождаются самые неприятные баги split DNS.
Итог
У спора «CoreDNS vs dnsmasq vs Unbound» нет победителя «на все случаи». На VDS чаще всего выигрывает подход от роли:
- dnsmasq — минималистичный вариант для быстрого локального кэша и простого split DNS.
- Unbound — наиболее универсальный выбор, если нужен сильный рекурсивный резолвер, качественное кэширование и предсказуемая эксплуатация.
- CoreDNS — инструмент, когда DNS становится частью платформы (контейнеры, сервисы, плагины, интеграции), особенно если наружу он форвардит в Unbound.
Если ваша схема включает внутренние домены и публичные имена под одним брендом, заранее продумайте DNS-политику для домена и его продления: полезно свериться с материалом про grace/redemption периоды при продлении домена, чтобы не попасть на простой из-за просрочки. А для управляемого выпуска сертификатов в сложных DNS-сценариях пригодится разбор автоматизации DNS-01 для wildcard SSL.
