Unbound — локальный DNS-сервер на Debian с поддержкой DoT

Unbound — это свободный и открытый DNS‑сервер, ориентированный на валидацию, рекурсивную резолвацию и кэширование. Он поддерживает современные протоколы и механизмы: DNS‑over‑TLS (DoT), DNS‑over‑HTTPS (DoH), Query Name Minimisation, активное использование DNSSEC‑валидированного кэша и авторитативные зоны. Главный фокус Unbound — приватность и безопасность DNS без потери скорости.

Unbound активно разрабатывается NLnet Labs и распространяется под BSD‑лицензией. Он прошёл аудит безопасности, работает на Linux, BSD и macOS и доступен в репозиториях Debian/Ubuntu, что упрощает установку через пакетный менеджер.

В этом руководстве вы шаг за шагом настроите приватный локальный DNS‑сервер на Debian 11 и Debian 12. Мы настроим Unbound как:

• локальный рекурсивный резолвер с кэшем;
• опишем, как добавить авторитативную локальную зону и PTR‑записи;
• включим DNS‑over‑TLS для приватного обмена с внешними форвардерами;
• настроим ACL для ограничения доступа;
• настроим логирование через rsyslog и ротацию логов через logrotate;
• покажем, как настроить клиентов (Ubuntu, Debian) и как тестировать работу.

Что нужно заранее

• Сервер Debian 11 или Debian 12.
• Учетная запись с правами sudo или root.
• Базовые знания работы с терминалом и редактированием файлов (nano/vim).

Важно: все команды в статье предполагают выполнение с sudo, если не указано иное.

Установка Unbound

Пакет unbound доступен в стандартных репозиториях Debian и устанавливается через apt.

Обновите индекс пакетов:

sudo apt update

Проверьте информацию о пакете:

sudo apt info unbound

Установите Unbound:

sudo apt install unbound

После установки проверьте статус и включение сервиса:

sudo systemctl is-enabled unbound
sudo systemctl status unbound

Сервис должен быть включён и запущен автоматически.

Примечание: если на сервере отключён IPv6, Unbound может не стартовать. В таком случае добавьте do-ip6: no в секцию server файла /etc/unbound/unbound.conf.

Основная конфигурация Unbound

Главный конфигурационный файл: /etc/unbound/unbound.conf. Мы будем редактировать его и добавлять разделы.

Откройте файл редактором:

sudo nano /etc/unbound/unbound.conf

Ниже — пример минимальной, но практичной конфигурации для локальной установки. Комментарии поясняют параметры.

#Adding DNS-Over-TLS support  
server:  
    use-syslog: yes  
    username: "unbound"  
    directory: "/etc/unbound"  
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt      
    do-ip6: no  
    interface: 192.168.5.20  
    port: 53  
    prefetch: yes  
  
    root-hints: /usr/share/dns/root.hints  
    harden-dnssec-stripped: yes

Пояснения ключевых параметров:

• use-syslog — отправлять логи в syslog (rsyslog).
• username — пользователь для процесса unbound (обычно unbound).
• directory — рабочая директория Unbound.
• tls-cert-bundle — файл доверенных CA (на Debian: /etc/ssl/certs/ca-certificates.crt).
• do-ip6 — включить IPv6 (yes) или отключить (no).
• interface — IP или интерфейс, на котором слушать (можно указать IP@PORT).
• port — порт для DNS (по умолчанию 53).
• prefetch — предзагрузка почти истекающих записей кэша.
• root-hints — файл с root‑серверными адресами (поставляется пакетом dns-root-data).
• harden-dnssec-stripped — защита от DNSSEC‑обрыва цепочки.

Включение кэширования

Добавьте параметры кэширования:

    cache-max-ttl: 14400  
    cache-min-ttl: 1200

• cache-max-ttl и cache-min-ttl задаются в секундах. Минимальное TTL по умолчанию 0.
• Не ставьте слишком большой cache-min-ttl, чтобы не унаследовать устаревшие записи.

Параметры приватности и безопасности

Добавьте:

    aggressive-nsec: yes  
    hide-identity: yes  
    hide-version: yes  
    use-caps-for-id: yes

• aggressive-nsec — использовать цепочку NSEC для синтеза NXDOMAIN/отказов.
• hide-identity и hide-version — скрыть информацию о сервере.
• use-caps-for-id — включить 0x20‑кодирование в запросах для защиты от спуфинга.

Частные подсети и ACL

Определите private-address и access-control, адаптируя под вашу сеть:

    private-address: 192.168.0.0/16  
    private-address: 169.254.0.0/16  
    private-address: 172.16.0.0/12  
    private-address: 10.0.0.0/8  
    private-address: fd00::/8  
    private-address: fe80::/10  
  
    #control which clients are allowed to make (recursive) queries  
    access-control: 127.0.0.1/32 allow_snoop  
    access-control: ::1 allow_snoop  
    access-control: 127.0.0.0/8 allow  
    access-control: 192.168.5.0/24 allow

• private-address — указывает подсети, которые считаются частными. Только локальные записи могут указывать на эти адреса.
• access-control — управляет правами клиентов: allow даёт рекурсивные запросы, allow_snoop — также разрешает статистические запросы.

Локальная зона и записи

Пример локальной авторитативной зоны garden.lan с A‑ и PTR‑записями:

    # local zone  
    local-zone: "garden.lan." static  
  
    local-data: "firewall.garden.lan.  IN A 10.0.0.1"  
    local-data: "vault.garden.lan.    IN A 10.0.0.2"  
    local-data: "media.garden.lan.   IN A 10.0.0.3"  
    local-data: "docs.garden.lan.       IN A 10.0.0.4"  
    local-data: "wiki.garden.lan.     IN A 10.0.0.5"  
  
    local-data-ptr: "10.0.0.1  firewall.garden.lan"  
    local-data-ptr: "10.0.0.2  vault.garden.lan"  
    local-data-ptr: "10.0.0.3  media.garden.lan"  
    local-data-ptr: "10.0.0.4  docs.garden.lan"  
    local-data-ptr: "10.0.0.5  wiki.garden.lan"

• local-zone — тип зоны (static означает статические данные в конфиге).
• local-data — A/AAAA записи.
• local-data-ptr — PTR записи для обратной зоны.

Тонкая настройка производительности

Примеры параметров для серверов с несколькими ядрами и достаточным объёмом памяти:

    num-threads: 4  
    msg-cache-slabs: 8  
    rrset-cache-slabs: 8  
    infra-cache-slabs: 8  
    key-cache-slabs: 8  
    rrset-cache-size: 256m  
    msg-cache-size: 128m  
    so-rcvbuf: 8m

• num-threads — число потоков, обычно равно числу логических ядер.
• *_cache-slabs — число «слэбов» для соответствующих кэшей, влияет на конкуренцию и фрагментацию памяти.
• rrset-cache-size / msg-cache-size — объём памяти для кэшей (MB).
• so-rcvbuf — буфер сокета для UDP.

Настройка форвардинга и DoT

Чтобы Unbound использовался как резолвер с форвардингом через DoT, добавьте секцию forward-zone:

forward-zone:  
    name: "."  
    forward-ssl-upstream: yes  
    ## Also add IBM IPv6 Quad9 over TLS  
    forward-addr: 9.9.9.9@853#dns.quad9.net  
    forward-addr: 149.112.112.112@853#dns.quad9.net

• forward-ssl-upstream: yes — включает TLS при подключении к форвардерам.
• forward-addr — IP@PORT#NAME; имя указывает на сертификат (SNI) и помогает валидации TLS.

Сохраните изменения и проверьте конфигурацию:

sudo unbound-checkconf

Если всё в порядке, вы увидите: unbound-checkconf: no errors in /etc/unbound/unbound.conf

Перезапустите сервис:

sudo systemctl restart unbound

Настройка UFW — открыть порт DNS

Установите ufw и откройте порт 53/udp (и OpenSSH заранее, чтобы не потерять доступ):

sudo apt install ufw
sudo ufw allow OpenSSH
sudo ufw allow 53/udp
sudo ufw enable
sudo ufw status

После включения вы увидите, что OpenSSH и 53/udp разрешены.

Логирование Unbound через rsyslog и ротация логов через logrotate

По умолчанию Unbound логирует через syslog. Чтобы отделить его логи в отдельный файл, создайте конфигурацию rsyslog:

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

Добавьте:

# Log messages generated by unbound application   
if $programname == 'unbound' then /var/log/unbound.log  
# stop processing it further  
& stop

Перезапустите rsyslog:

sudo systemctl restart rsyslog

Создайте правило для logrotate:

sudo nano /etc/logrotate.d/unbound

Добавьте:

/var/log/unbound.log {  
  daily  
  rotate 7  
  missingok  
  create 0640 root adm  
  postrotate  
    /usr/lib/rsyslog/rsyslog-rotate  
  endscript  
}

Перезапустите logrotate (обычно systemd выполняет ротацию автоматически, но можно перезапустить службу):

sudo systemctl restart logrotate

После этого Unbound будет логировать в /var/log/unbound.log, и файлы будут ротироваться ежедневно.

Настройка DNS‑резолвера на клиентах

Рассмотрим два распространённых сценария: Ubuntu с NetworkManager и systemd‑resolved, и Debian с systemd‑resolved.

Ubuntu с NetworkManager и systemd‑resolved

1. Откройте /etc/NetworkManager/NetworkManager.conf и укажите backend dns:

sudo nano /etc/NetworkManager/NetworkManager.conf

Разкомментируйте или добавьте:

dns=systemd-resolved

Перезапустите NetworkManager:

sudo systemctl restart NetworkManager

2. Укажите адрес Unbound в /etc/systemd/resolved.conf:

sudo nano /etc/systemd/resolved.conf

В секции [Resolve] добавьте:

[Resolve]  
DNS=192.168.5.20

Запустите и включите systemd‑resolved:

sudo systemctl start systemd-resolved
sudo systemctl enable systemd-resolved

Проверьте статус:

sudo systemctl status systemd-resolved
resolvectl status

resolvectl покажет, что резолвер по умолчанию — ваш Unbound.

Debian (systemd‑resolved)

На Debian аналогично укажите в /etc/systemd/resolved.conf:

sudo nano /etc/systemd/resolved.conf

[Resolve]  
DNS=192.168.5.20

Запустите и включите сервис:

sudo systemctl start systemd-resolved
sudo systemctl enable systemd-resolved
sudo systemctl status systemd-resolved
resolvectl status

Тестирование Unbound

Проверка через dig. На сервере или клиенте выполните:

dig @192.168.5.20

В ответ вы должны получить ответ, приходящий от корневых серверов (если форвард не настроен), и заголовок может содержать флаг ad (authentic data), если DNSSEC был валиден.

Проверьте внешние домены:

dig github.com
dig duckduckgo.com

Если вы используете systemd‑resolved на клиенте, резолвер будет 127.0.0.53#53, а этот локальный резолвер уже перенаправляет запросы к Unbound.

При повторном запросе время ответа должно уменьшаться — подтверждение работы кэша.

dig github.com
dig duckduckgo.com

Проверьте локальные записи:

dig firewall.garden.lan +short
dig vault.garden.lan +short
dig media.garden.lan +short

Проверьте PTR:

dig -x 10.0.0.1 +short

Проверка DoT через tcpdump

Установите tcpdump и слушайте порт 853 (DoT):

sudo apt install tcpdump

Запустите на сервере (интерфейс и IP по вашему окружению):

tcpdump -vv -x -X -s 1500 -i eth0 'port 853'

На клиенте выполните dig google.com — в tcpdump вы увидите зашифрованные TLS‑сообщения на порту 853.

Отработка ошибок и рекомендации по устранению неполадок

• Unbound не стартует: проверьте /var/log/unbound.log и systemctl status. Частая причина — конфликт с другим сервисом на 53/udp (например, bind), или неверная конфигурация интерфейса. Также проверьте do-ip6, если IPv6 отключён.
• Клиенты не могут резолвить: проверьте ACL, firewall (UFW), и что systemd‑resolved или NetworkManager указаны правильно.
• DoT не работает: проверьте forward-addr формат, доступность форвардера по порту 853 и корректность tls-cert-bundle (доступ к CA‑файлу).
• DNSSEC выдал ошибку: проверьте harden-dnssec-stripped и время системы (NTP). Неверное время может ломать валидацию DNSSEC.

Безопасность и hardening (рекомендации)

1. Запускать Unbound под отдельным пользователем (username: unbound).
2. Ограничить доступ через ACL: разрешать только доверенным подсетям.
3. Использовать forward-ssl-upstream и проверку SNI для форвардеров.
4. Включить hide-version и hide-identity, use-caps-for-id.
5. Ограничить публичный доступ к порту 53, если сервер не предназначен для внешних клиентов.
6. Регулярно обновлять пакеты и следить за CVE для Unbound.
7. Включить мониторинг и оповещения на основе логов (/var/log/unbound.log).

Миграция с bind или другого локального резолвера

• Экспортируйте локальные зоны из bind и конвертируйте в local-data формат или создайте master‑зоны.
• Проверьте, что нет конфликтующих демонов на 53/udp.
• Тестируйте в тестовой сети перед заменой production‑резолвера.

Модель принятия решений (когда использовать Unbound)

• Нужен быстрый локальный кэш с DNSSEC и приватной связкой с внешними форвардерами → Unbound.
• Требуется полная авторитативная служба с динамическими зонами и множеством master‑файлов → возможно bind/NSD предпочтительнее.
• Нужен интегрированный DoH‑сервер с авторизацией по API → рассмотреть DoH‑специфические решения.

Сценарии отказа и когда Unbound не подходит

• Необходимо управлять большой авторитативной зоной с многочисленными динамическими изменениями — Unbound не предназначен как полноценный authoritative master с зонами динамического управления.
• Требуется GUI‑управление зонами для непрофессиональных администраторов — подойдёт специализированная панель поверх bind/PowerDNS.

Playbook: быстрый план развёртывания в проде

1. Подготовить сервер Debian 11/12, настроить доступ по SSH.
2. apt update && apt install unbound ufw rsyslog logrotate tcpdump.
3. Настроить /etc/unbound/unbound.conf по шаблону выше.
4. Настроить rsyslog и logrotate для /var/log/unbound.log.
5. Настроить ufw: allow OpenSSH; allow 53/udp для доверенной подсети.
6. Запустить и проверить unbound: unbound-checkconf && systemctl restart unbound.
7. На клиентах указать Unbound через systemd‑resolved или DHCP.
8. Прогоны тестов: dig локальные и внешние домены, проверка DoT tcpdump.
9. Включить мониторинг и бэкапы конфигурации.

Роль‑ориентированные чек‑листы

Администратор сети:

• Проверил доступность порта 53/udp локально и с клиента.
• Настроил ACL и private-address.
• Проверил кэширование (повторный dig уменьшает query time).

Инженер безопасности:

• Включил forward-ssl-upstream и tls-cert-bundle.
• Проверил hide-version и hide-identity.
• Настроил ротацию логов и мониторинг аномалий.

Оператор поддержи:

• Умеет воспроизвести проблему через dig и tcpdump.
• Знает, где искать логи (/var/log/unbound.log).
• Имеет доступ к unbound-checkconf и systemctl.

Критерии приёмки

• Unbound успешно стартует и остаётся в состоянии active (running).
• Рекурсивные DNS‑запросы из доверенной подсети возвращают ответы.
• Локальные A и PTR записи возвращаются корректно.
• DoT установлен: зашифрованные пакеты видны на порту 853 при подключении к форвардеру.
• Логи пишутся в /var/log/unbound.log и ротируются.

Набор тестов и критерии приёмки

1. Проверка стартового статуса: systemctl status unbound -> active.
2. Синтаксис конфигурации: sudo unbound-checkconf -> no errors.
3. Локальные имена: dig firewall.garden.lan +short -> 10.0.0.1.
4. PTR: dig -x 10.0.0.1 +short -> firewall.garden.lan.
5. Внешняя резолвация: dig github.com @192.168.5.20 -> ответ A/AAAA.
6. DoT: tcpdump показывает TLS‑handshake на порту 853 при выполнении dig внешнего домена.

Краткая терминология (1‑строчные определения)

• DNSSEC: механизм цифровой подписи DNS для проверки целостности и подлинности записей.
• DoT: DNS over TLS, шифрование DNS‑трафика поверх TLS на порте 853.
• DoH: DNS over HTTPS, другой способ шифрования DNS поверх HTTPS.
• ACL: access control list — список сетей/хостов с правами.
• local-zone/local-data: способ определить статические локальные записи в unbound.conf.

MerMaid диаграмма: базовый поток принятия решений

flowchart TD
  A[Нужен локальный кэш с DNSSEC?] -->|Да| B[Выбрать Unbound]
  A -->|Нет| C[Рассмотреть другие решения]
  B --> D{Требуется авторитативность?}
  D -->|Только статические зоны| E[Unbound с local-zone]
  D -->|Динамические зоны| F[Bind/PowerDNS]
  E --> G[Включить DoT/форвардинг]

Совместимость и рекомендации по миграции

• Unbound доступен в репозиториях Debian 11 и 12. Для более старых дистрибутивов рекомендуется собрать из исходников или использовать backports.
• Если вы переносите конфигурации с других резолверов, конвертируйте локальные зоны в local-data или используйте мастер‑файлы и внешние инструменты.

Социальный превью и анонс

OG title: Unbound на Debian: локальный DNS с DoT OG description: Настройте быстрый и безопасный локальный DNS‑сервер на Debian с кэшированием, DNSSEC и DNS‑over‑TLS.

Короткое объявление (100–200 слов):

Unbound — лёгкий и безопасный DNS‑резолвер, идеально подходящий для локальных сетей. В этом руководстве показано, как на Debian 11/12 установить Unbound, включить кэширование и DNSSEC, добавить локальные зоны, настроить форвардинг через DNS‑over‑TLS и организовать логирование. Вы получите рабочую конфигурацию для безопасного и приватного разрешения имён в вашей сети, готовую к использованию на Ubuntu и Debian клиентах через systemd‑resolved.

Заключение

Вы установили и настроили Unbound на Debian 11/12 как локальный DNS‑сервер с кэшем, защитой DNSSEC и поддержкой DoT. Мы рассмотрели:

• установку и базовую конфигурацию unbound.conf;
• включение приватности, ACL и локальных зон;
• оптимизацию производительности;
• настройку форвардинга через DoT;
• логирование и ротацию логов;
• настройку клиентов и тестирование.

Дальшие шаги: интегрировать мониторинг, автоматизировать бэкапы конфигурации и при необходимости масштабировать параметры кэша под нагрузку.

Wichtig: поддерживайте систему в актуальном состоянии и периодически проверяйте логи на предмет аномалий.