DNS в 2026 году — это уже не «прописал 8.8.8.8 и забыл». На серверах и рабочих станциях важны предсказуемые задержки, нормальный local DNS cache, аккуратный split DNS для VPN/корпоративных зон, а иногда и шифрование (DoT) плюс DNSSEC validation. При этом в Linux одновременно живут три «героя» одной сцены: systemd-resolved (системный stub resolver), dnsmasq (лёгкий форвардер/кэш и часто DHCP) и unbound (полноценный рекурсивный резолвер и валидатор).
Ниже — практичное сравнение: что каждый компонент реально делает, где чаще всего ошибаются при выборе и какие схемы развёртывания в 2026 выглядят наиболее рационально.
Сначала термины: stub resolver, кэш и «кто вообще делает резолвинг»
На Linux есть три уровня, которые часто путают. Если не развести их в голове, дальше вы будете чинить «DNS», который на самом деле ломается на другом уровне.
Stub resolver — «тонкий» клиент на хосте. Он принимает запросы от приложений (обычно через
/etc/resolv.confи/или локальный слушатель) и пересылает их дальше. В современных дистрибутивах эту роль часто берёт на себяsystemd-resolved.DNS caching / local DNS cache — кэширование ответов рядом с приложениями. Это может делать и
systemd-resolved, иdnsmasq, иunbound. Важно: «есть кэш» не означает «есть DNSSEC validation» или «есть рекурсия».Рекурсивный резолвер — компонент, который сам ходит в интернет к авторитативным серверам (через root/NS цепочки), строит путь и может проверять DNSSEC. Из этой тройки это типичная роль
unbound.
Главный практический вопрос: вы хотите просто ускорить запросы (кэш+форвардинг), или хотите контролировать доверие к ответу (DNSSEC validation) и минимизировать зависимость от внешних рекурсоров?
systemd-resolved в 2026: системный stub resolver и маршрутизация DNS
systemd-resolved часто «уже включён» на десктопах и многих серверных образах. Его сильная сторона — интеграция с системой: интерфейсы, VPN, разные DNS для разных линков, удобный split DNS (в смысле маршрутизации по доменным суффиксам) и нормальная работа с временными сетями (Wi‑Fi, туннели, NetworkManager, systemd-networkd).
Что он делает хорошо
Stub resolver на локальном адресе (часто
127.0.0.53) и централизованный контроль того, куда уходят запросы.Split DNS: для доменов вроде
corp.exampleможно настроить отдельные DNS-серверы, которые будут использоваться только для этих зон, а остальное — через «обычные» резолверы.Кэширование на хосте без отдельного демона, который вы вручную привязываете к интерфейсам/VPN.
Где он слабее
DNSSEC validation: режимы и поведение при ошибках могут отличаться по дистрибутивам и быть неожиданными в инцидентах. Для строгой валидации чаще выбирают
unbound.DoT: поддержка DNS-over-TLS есть, но на серверах многим проще эксплуатировать DoT через явный резолвер/форвардер (например,
unbound) с предсказуемой диагностикой.Тонкости с контейнерами: при Docker/Podman и собственных DNS внутри контейнерных сетей иногда проще жить с отдельным форвардером на явном адресе и понятной моделью порта 53.
Когда выбирать systemd-resolved
Если у вас одна машина (сервер или рабочая станция), важен split DNS для VPN и вы хотите минимум ручной поддержки — systemd-resolved обычно лучший старт. Он закрывает «stub resolver + local DNS cache» без лишних компонентов.
Если параллельно вам важно ускорять доступ к веб-приложениям и уменьшать «хвостовые» задержки, имеет смысл на уровне стека отдельно заняться кэшированием контента и ответов: например, посмотреть практику с кэшем Memcached/Redis для PHP (это не про DNS, но эффект по общей латентности часто заметнее, чем тюнинг резолвинга).
dnsmasq в 2026: лёгкий кэширующий форвардер и «швейцарский нож» для малых сетей
dnsmasq любят за простоту: поднял, указал апстримы — получил кэш, простые локальные записи, а при необходимости ещё и DHCP. В 2026 он остаётся актуальным, когда нужно «быстро и ясно» на роутере, небольшом узле, в лаборатории/VM-стенде, а также как локальный кэш для группы машин, если вы не хотите полноценную рекурсию и строгую DNSSEC validation.
Сильные стороны dnsmasq
Минимальная сложность: конфиг обычно короткий и читабельный, эксплуатация предсказуемая.
DNS caching и простые локальные записи (например, «вот этот A/AAAA для dev-сервиса»).
DHCP в комплекте для маленьких сетей/стендов.
Ограничения
DNSSEC validation — не его основной профиль. Если вам нужен строгий валидатор с понятным поведением при сбоях, обычно проще смотреть в сторону
unbound.DoT: как системная история «из коробки» обычно решается хуже, чем в
unbound. Часто появляются дополнительные прокси/туннели, а это лишние подвижные части.Split DNS реализуем, но обычно менее «нативно», чем в
systemd-resolved, который живёт в контексте интерфейсов и VPN.
Когда выбирать dnsmasq
Если задача — local DNS cache и простой форвардинг, плюс, возможно, DHCP для небольшой подсети. Также dnsmasq часто выбирают там, где нужен «плоский» предсказуемый сервис без сильной привязки к systemd.
Unbound в 2026: рекурсивный резолвер, DNSSEC validation и контроль над транспортом (DoT)
unbound — это уже «настоящий DNS-сервис», а не просто stub resolver. Его выбирают, когда требуется контроль качества ответа, безопасность и повторяемость поведения: строгая DNSSEC validation, грамотный кэш, тонкая настройка таймаутов, агрессивный кэш негативных ответов и в целом хорошая производительность при нормальной конфигурации.
Что Unbound умеет лучше всего
Полная рекурсия: можно не зависеть от публичных рекурсоров (или зависеть минимально).
DNSSEC validation: сильная сторона Unbound. В продакшене это часто причина №1 выбора.
DoT как транспорт до апстрима (forwarding) в гибридных схемах: можно форвардить на выбранные резолверы через TLS и при этом сохранять локальный контроль кэша.
Гибкая политика для приватных зон: локальные данные, stub-зоны, forward-зоны — удобно для split DNS.
Где Unbound «дороже»
Сложнее вход: больше параметров, больше вариантов сделать «почти работает, но не идеально».
Нужно выбрать роль: на одной машине Unbound может быть и кэшем, и рекурсором, и форвардером. Лучше заранее определиться с архитектурой и точкой входа.
Когда выбирать Unbound
Когда у вас сервер/группа серверов и нужен «правильный DNS» для инфраструктуры: DNS caching + DNSSEC validation, предсказуемая деградация, централизованная политика, опционально DoT до апстрима, плюс аккуратный split DNS для внутренних зон.
Split DNS: что именно вы делите и почему тут легко ошибиться
Под split DNS в быту называют разные вещи — и из-за этого люди спорят, хотя обсуждают разные схемы.
Split-horizon: разные ответы на один и тот же домен в зависимости от того, откуда пришёл запрос (обычно на авторитативном DNS). Это отдельная тема.
Split DNS на клиенте: разные резолверы для разных доменов, обычно из-за VPN. Например,
*.corp.example— через DNS компании, всё остальное — через публичный резолвер.
В рамках этой статьи важен второй вариант. Здесь часто побеждает systemd-resolved, потому что он знает про интерфейсы и может маршрутизировать запросы по доменным суффиксам. Но и связка «resolved как маршрутизатор → unbound как локальный резолвер» тоже распространена: resolved принимает запросы от приложений и прокидывает их на локальный Unbound, а Unbound уже решает, куда форвардить и как валидировать.
Практика: если split DNS завязан на VPN-клиент, сначала проверьте, кто именно управляет DNS-настройками (NetworkManager, systemd-networkd, cloud-init, скрипты VPN). От этого зависит, будет ли система корректно применять доменные маршруты.
DoT (DNS-over-TLS) в 2026: где уместен и чего от него не ждать
DoT решает задачу защиты канала «клиент → резолвер» от пассивного прослушивания и части MITM на сети доступа. Но важно помнить:
DoT не делает DNS анонимным для самого резолвера: резолвер всё равно видит ваши запросы.
DoT не заменяет DNSSEC validation. DNSSEC — про криптографическую целостность ответа (при наличии подписанной зоны), DoT — про шифрование транспорта.
В админской практике DoT чаще всего имеет смысл:
на рабочих станциях и ноутбуках, особенно вне доверенной сети;
на edge-узлах (роутер/шлюз) как единая точка выхода DNS;
в средах VDS/серверов — когда вы осознанно форвардите на внешние резолверы и хотите защитить транспорт, не поднимая полную рекурсию.
Если вы выносите DNS-резолвер как сервис наружу (например, для офисов/филиалов), не забывайте про защиту канала и сервиса целиком: корректные сертификаты и управление сроками. Для внешних сервисов пригодятся SSL-сертификаты — не для DoT как такового (там своя модель), а для публичных веб-интерфейсов, панелей и API рядом с инфраструктурой, которые часто оказываются «забытым слабым местом».
DNSSEC validation: почему «включить галочку» недостаточно
DNSSEC validation в реальности упирается в политику обработки ошибок. Когда цепочка доверия ломается (ошибка подписи, неправильный DS, проблемы у регистратора), валидатор честно вернёт ошибку, и пользователи скажут «интернет умер». Поэтому важно:
понимать, где вы готовы принимать строгий режим, а где нужен план действий на инцидент;
иметь наблюдаемость: логи валидатора, метрики, быстрый способ временно ослабить политику на период расследования;
разделять внутренние зоны (часто без DNSSEC) и внешние зоны (с DNSSEC), чтобы валидатор не ломал то, что вы не подписывали.
По этой причине Unbound часто выбирают как «центральный валидатор» для инфраструктуры, а stub resolver на хостах оставляют максимально простым.
Производительность: задержки, кэш и почему «кто быстрее» — не главный вопрос
В сравнении unbound vs dnsmasq vs systemd-resolved вопрос «кто быстрее» почти всегда сводится к архитектуре и кэшу:
Если запрос попал в local DNS cache, разница обычно минимальна (в пределах реализации и нагрузки).
Если запрос вне кэша, побеждает тот, у кого лучше апстрим, маршрутизация, таймауты и меньше потерь.
«Самый быстрый» часто означает «самый близкий и самый предсказуемый»: локальный резолвер на хосте или в подсети.
Практический совет для серверов: если у вас много короткоживущих контейнеров/джобов, они создают всплески DNS. Тут выигрывает локальный кэш (resolved, dnsmasq или unbound), потому что вы разгружаете внешний резолвер и уменьшаете tail-latency.
Типовые схемы, которые реально работают
1) Только systemd-resolved (рабочие станции, простые серверы)
Подходит, если вам нужен stub resolver, умеренный DNS caching и split DNS для VPN, а «снаружи» резолвится через DNS провайдера/корпоративный.
Плюсы: минимум компонентов. Минусы: меньше контроля над DNSSEC/DoT политиками и диагностика иногда «слишком магичная».
2) dnsmasq как локальный кэш-форвардер (стенды, небольшие сети)
Схема: приложения → dnsmasq → апстрим DNS (провайдер/корпоративный). Удобно, когда нужен local DNS cache и простые локальные записи, иногда DHCP.
3) Unbound как локальный резолвер (сервер/площадка), опционально с форвардингом по DoT
Схема: приложения → (stub resolver) → unbound → либо рекурсия, либо forward на выбранные резолверы через DoT. Это хорошая база для DNSSEC validation и стабильной производительности.
4) systemd-resolved + Unbound (разделение ролей)
Схема: systemd-resolved остаётся системным stub resolver и отвечает за split DNS «по интерфейсам», а Unbound — за кэш, DNSSEC validation и транспорт (DoT) к апстримам. Это компромисс между удобством resolved и контролем Unbound.
Отладка и диагностика: что проверить в первую очередь
Какая бы связка ни была, в 80% случаев проблемы одинаковые: не тот /etc/resolv.conf, конфликт сервисов на 53 порту, «пропал» split DNS после VPN или приложения обходят системный резолвер.
Быстрые команды для проверки
resolvectl status
resolvectl query example.com
cat /etc/resolv.conf
ss -lntup | grep ':53 '
dig @127.0.0.1 example.com
Если вы используете systemd-resolved, ключевой момент — понять, куда реально идут запросы: на 127.0.0.53, на адрес вашего локального DNS-демона, или напрямую на внешние DNS. Если видите «зоопарк» (часть приложений ходит в одно, часть — в другое), сначала выравнивайте точку входа.
Рекомендации выбора (коротко, но по делу)
Нужен удобный split DNS на ноутбуке/сервере с VPN и минимум ручной поддержки →
systemd-resolved.Нужен простой local DNS cache + иногда DHCP для небольшой сети/стенда →
dnsmasq.Нужна DNSSEC validation, строгая политика, контроль кэша и стабильная производительность на инфраструктуре →
unbound(часто как центральный резолвер).Нужно лучшее из двух миров: split DNS по интерфейсам и строгая валидация →
systemd-resolved+unbound(разделение ролей).
Что важно учесть перед внедрением
Перед тем как «переехать» на новую схему, проверьте:
кто управляет DNS на хосте (NetworkManager, systemd-networkd, cloud-init, VPN-клиент);
какие домены должны уходить в корпоративную сеть (требования split DNS);
нужна ли DNSSEC validation именно на этом уровне (на хостах или на центральном резолвере);
нужен ли DoT и где: «хост → локальный резолвер», «локальный резолвер → апстрим» или оба;
как будут жить контейнеры/оркестрация (важно избежать конфликтов DNS и неожиданных таймаутов).
Самая рабочая стратегия: сначала добиться предсказуемого поведения без шифрования (правильный stub resolver, кэш, split DNS), затем добавлять DoT и DNSSEC validation — по одному изменению за раз.
Итог
В 2026 году выбор между systemd-resolved, dnsmasq и unbound — это не «какой лучше», а «кто какую роль играет».
systemd-resolved силён как системный stub resolver и маршрутизатор split DNS. dnsmasq остаётся простым кэширующим форвардером для малых сетей и стендов. unbound — выбор, когда нужна серьёзная DNSSEC validation, гибкая политика и контролируемая производительность, включая DoT до апстрима. А наиболее зрелые конфигурации часто комбинируют: resolved — «вход» на хосте, unbound — «мозг» резолвинга.
