Как установить и настроить Unbound на VPS

MAATRIX

Публичные резолверы вроде 8.8.8.8 или 1.1.1.1 удобны, но видят каждый ваш DNS-запрос, а иногда ещё и подменяют ответы или режут TTL ради своей кеш-политики. Если вы уже держите VPN, Pi-hole или AdGuard Home и хотите закрыть последнее звено доверия — сам резолвинг — Unbound решает эту задачу: он ходит к корневым серверам DNS напрямую, минуя посредников, и проверяет подписи DNSSEC на каждом шаге. Ниже — рабочая установка на чистом VPS, без магии и лишних абстракций.

Что такое Unbound и зачем он на своём сервере

Unbound — рекурсивный кеширующий резолвер от NLnet Labs, тот же коллектив, что поддерживает NSD и делает часть инфраструктуры корневых серверов DNS. В отличие от форвардера (который просто пересылает запрос дальше на 8.8.8.8 или 1.1.1.1), Unbound сам идёт по цепочке: спрашивает корневые сервера, потом сервера зоны .com/.ru/что угодно, потом авторитетный сервер конкретного домена — и складывает ответ в собственный кеш. Ни один внешний резолвер не видит полную картину того, какие домены вы резолвите.

Это не панацея — сам сайт, к которому вы идёте, всё равно видит ваш IP, а провайдер видит UDP/TCP-пакеты на 53-й порт, если вы не завернули их в DoT/DoH. Но два практических плюса реальны: DNSSEC-валидация ловит попытки подмены ответа на пути, и запросы не оседают в логах чужого DNS-провайдера. Типичный сценарий — Unbound ставят рядом с Pi-hole или AdGuard Home именно как upstream-резолвер вместо публичного DNS, ваш блокировщик рекламы фильтрует домены, а Unbound сам находит на них ответ.

Ресурсы под него скромные: 512 МБ RAM с запасом хватает на личный сервер, кеш по умолчанию небольшой и настраивается отдельно. Для этой роли достаточно самого дешёвого VPS — переплачивать за CPU/RAM здесь не за что.

Установка на Ubuntu/Debian

Пакет есть в стандартных репозиториях, собирать из исходников не нужно.

sudo apt update
sudo apt install unbound unbound-anchor -y

unbound-anchor — отдельная утилита, она отвечает за первичную загрузку и проверку корневого доверенного якоря DNSSEC (root trust anchor). После установки systemd-юнит unbound-anchor-update уже настроен на автообновление, дополнительно ничего делать не нужно — но стоит один раз прогнать вручную и убедиться, что якорь на месте:

sudo unbound-anchor -a /var/lib/unbound/root.key

Если файл уже существует и валиден, команда просто завершится без вывода. Проверьте, что служба стартовала:

sudo systemctl enable --now unbound
sudo systemctl status unbound

На Ubuntu 24.04/22.04 и Debian 12 пакет одинаковый и ведёт себя одинаково — версия в репозиториях на конец августа 2026 года достаточно свежая для всех задач ниже. Если вам ещё только предстоит поднять сам сервер с нуля, порядок действий для базовой настройки DNS на домене описан в статье про настройку домена и DNS с нуля на Ubuntu 24.04.

Базовый конфиг: unbound.conf.d

Основной файл /etc/unbound/unbound.conf в пакетных сборках обычно уже подключает директорию /etc/unbound/unbound.conf.d/*.yml — проверьте это строкой в конце файла:

include-toplevel: "/etc/unbound/unbound.conf.d/*.yml"

Не редактируйте unbound.conf напрямую — при обновлении пакета его могут перезаписать. Создайте свой файл настроек:

sudo nano /etc/unbound/unbound.conf.d/local.conf

Минимальный рабочий конфиг для резолвера, который слушает локальный интерфейс и внутреннюю сеть (например, если Unbound стоит рядом с Pi-hole на том же сервере):

server:
    # Слушаем только там, где нужно
    interface: 127.0.0.1
    interface: ::1
    port: 53

    # Кому разрешено спрашивать
    access-control: 127.0.0.1/32 allow
    access-control: ::1/128 allow

    # Приватность
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes

    # DNSSEC
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Разумные лимиты кеша
    cache-min-ttl: 300
    cache-max-ttl: 86400
    msg-cache-size: 64m
    rrset-cache-size: 128m

    # Не резолвим приватные диапазоны наружу (защита от DNS rebinding)
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16

qname-minimisation — важная опция: вместо того чтобы отправлять авторитетному серверу зоны .com полное имя mail.example.com, Unbound спросит только про example.com, скрывая от промежуточных серверов часть запроса. Это стандарт (RFC 7816), включён по умолчанию в свежих сборках, но лишним не будет прописать явно.

После правки конфига обязательно проверьте синтаксис перед перезапуском — Unbound не запустится с битым файлом молча, а откажется стартовать:

sudo unbound-checkconf
sudo systemctl restart unbound

DNSSEC-валидация: как убедиться, что она реально работает

Смысл всей затеи с Unbound часто именно в этом — резолвер не просто получает ответ, а проверяет цепочку криптографических подписей от корневой зоны до конкретного домена. Если подпись не сходится (кто-то подменил ответ по пути), Unbound вернёт SERVFAIL вместо подделанного IP.

Проверить, что валидация активна, проще всего через dig с флагом +dnssec, направив запрос напрямую в свой Unbound:

dig @127.0.0.1 cloudflare.com +dnssec

В ответе ищите флаг ad (Authenticated Data) в секции flags заголовка — если он есть, ответ прошёл DNSSEC-проверку. Второй способ — сознательно спросить заведомо «сломанный» с точки зрения DNSSEC домен:

dig @127.0.0.1 dnssec-failed.org

Это тестовый домен, специально настроенный с невалидной подписью. Рабочий Unbound с включённой валидацией ответит SERVFAIL; если вернулся обычный IP — валидация не работает, и стоит перепроверить строку auto-trust-anchor-file в конфиге и содержимое /var/lib/unbound/root.key.

Unbound как upstream для Pi-hole или AdGuard Home

Именно эта связка — самый частый повод ставить Unbound: блокировщик рекламы фильтрует запросы по спискам доменов, а сам резолвинг «чистых» запросов отдаёт Unbound, а не публичному DNS. Так провайдер вашего фильтра (Google, Cloudflare, кто угодно) не видит, какие сайты вы на самом деле открываете.

Если Pi-hole или AdGuard Home стоят на том же VPS, конфиг из раздела выше уже подходит — Unbound слушает 127.0.0.1:53. В веб-интерфейсе Pi-hole идёте в Settings → DNS, убираете все публичные резолверы и добавляете кастомный:

127.0.0.1#5335

Обратите внимание на порт: если на том же сервере крутится и Pi-hole, и Unbound, оба не могут слушать 53-й порт одновременно на одном интерфейсе. Стандартная практика — Unbound слушает 127.0.0.1:5335, а Pi-hole (который сам слушает 53-й на всех интерфейсах) идёт к нему как к upstream. Поменяйте в конфиге Unbound:

server:
    interface: 127.0.0.1@5335

Для AdGuard Home то же самое — в Settings → DNS settings → Upstream DNS servers прописывается:

127.0.0.1:5335

и убираются DoH/публичные адреса по умолчанию. Если вы ещё не разворачивали сам блокировщик, пошаговая установка есть в статьях про Pi-hole на VPS и про AdGuard Home на VPS — там же разбор типичных ошибок конфигурации.

Firewall и ограничение доступа

Unbound по умолчанию из коробки слушает только 127.0.0.1, что уже безопасно для однопользовательского сценария — снаружи достучаться нельзя. Но если вы хотите использовать резолвер с других устройств в своей сети (например, роутер дома шлёт запросы на VPS через WireGuard), нужно явно открыть интерфейс и ограничить, кому разрешено спрашивать:

server:
    interface: 0.0.0.0
    interface: ::0

    access-control: 127.0.0.1/32 allow
    access-control: 10.8.0.0/24 allow    # например, подсеть WireGuard
    access-control: 0.0.0.0/0 refuse

Последняя строка критична: access-control работает по принципу «последнее совпадающее правило побеждает», и без явного refuse для всех остальных Unbound превратится в открытый резолвер (open resolver), которым любой в интернете может воспользоваться для DNS-амплификации — классической DDoS-техники. Проверьте, что порт 53/UDP не торчит наружу для чужих:

sudo ufw allow from 10.8.0.0/24 to any port 53
sudo ufw deny 53

Если сервер и так стоит за VPN и вход только по ключу, это дополнительный слой, а не замена базовой гигиены — ключи вместо пароля на SSH и файрвол на входе никто не отменял, об этом подробно в статье про SSH-ключи вместо пароля на VPS.

Диагностика и мониторинг

Штатная утилита unbound-control даёт живую статистику без сторонних инструментов. Включается парой строк в конфиге:

remote-control:
    control-enable: yes

и одной командой генерируются сертификаты для локального управления:

sudo unbound-control-setup
sudo systemctl restart unbound

Дальше доступны команды:

unbound-control status                # запущен ли, аптайм, версия
unbound-control stats_noreset         # счётчики без сброса
unbound-control dump_cache            # содержимое кеша

В статистике полезнее всего смотреть total.num.queries (сколько запросов обработано), total.num.cachehits против total.num.cachemiss (эффективность кеша) и total.num.recursivereplies (сколько реально ушло в рекурсию, а не отдалось из кеша). Если cachemiss стабильно намного выше cachehits при повторяющихся запросах — стоит проверить cache-min-ttl, возможно он слишком мал.

Логи по умолчанию идут в syslog, посмотреть — стандартным journalctl:

sudo journalctl -u unbound -f

Для повышения детализации на время отладки временно поднимите verbosity в конфиге до 2-3 (в проде держите 1, иначе диск быстро заполнится логами).

Типичные проблемы при первом запуске

Резолвер не стартует после правки конфига — почти всегда это опечатка в отступах YAML-подобного синтаксиса (Unbound чувствителен к пробелам, табы использовать нельзя) или дублирующийся interface/port из двух конфликтующих файлов в unbound.conf.d/. unbound-checkconf перед каждым restart экономит массу времени.

Второй частый случай — Unbound отвечает SERVFAIL на все домены сразу после установки. Обычно это означает, что время на сервере не синхронизировано (DNSSEC-подписи имеют срок действия, и при большом расхождении часов валидация проваливается повсеместно), или что root.key не скачался из-за временно недоступного сетевого доступа при установке. Проверка:

timedatectl status
sudo unbound-anchor -a /var/lib/unbound/root.key -v

Третий момент — если сервер стоит за NAT или в контуре с нестандартной MTU (например, поверх WireGuard), крупные DNS-ответы с DNSSEC-подписями иногда фрагментируются некорректно. Включите edns-buffer-size: 1232 в блоке server: — это значение де-факто стандарт для избежания проблем с фрагментацией UDP-пакетов у резолверов, использующих DNSSEC.

Частые вопросы