Unbound с DoT/DoH апстримами: шифруем DNS и включаем валидацию DNSSEC

Задача: поднять свой локальный кеширующий резолвер на базе Unbound, включить валидацию DNSSEC и увести апстримный трафик в шифрованный канал через DoT (DNS-over-TLS) или DoH (DNS-over-HTTPS). Это улучшает приватность, защищает от подмены ответов и даёт предсказуемую производительность на VDS и в офисных/LAN-сетях.

Зачем шифровать DNS и включать DNSSEC

Обычный DNS идёт в чистом виде по UDP/TCP 53, его легко посмотреть, а иногда и подменить в пути. Шифрование апстримов (DoT/DoH) решает проблему конфиденциальности и затрудняет вмешательство провайдеров и промежуточных устройств. Валидация DNSSEC обеспечивает криптографическую проверку целостности ответов: если подпись не сходится, резолвер пометит ответ как недействительный. В тандеме DoT/DoH и DNSSEC закрывают сразу две задачи — приватность и целостность.

DoT vs DoH: что выбрать

Оба протокола шифруют DNS-запросы, но применяются по-разному:

• DoT работает поверх TLS на 853 порту, проще для сетевых политик и даёт предсказуемую производительность. В Unbound поддерживается нативно как апстрим.
• DoH инкапсулирует DNS в HTTPS, удобен там, где разрешён только веб-трафик. Для Unbound чаще используют локальный DoH-прокси как апстрим.

Если у вас есть контроль над сетью, начните с DoT: минимальная прослойка и меньше накладных расходов. DoH оставляйте как план Б — через локальный прокси, чтобы не ломать валидацию и кеш Unbound.

Целевая архитектура

Мы ставим Unbound на сервер (часто это VDS), включаем кеширование и DNSSEC-валидацию, и направляем все запросы пользователей/сервисов на локальный Unbound. Для апстрима выбираем:

• Вариант A: прямой DoT к доверенным провайдерам DNS.
• Вариант B: локальный DoH-прокси, к которому Unbound ходит по loopback, а прокси уводит запросы в HTTPS к апстримам.

Оба варианта совместимы с IPv4/IPv6, легко масштабируются горизонтально и укладываются в корпоративные политики безопасности.

Подготовка окружения

Понадобится современная ОС (Debian/Ubuntu/Alma/Rocky), обновлённые сертификаты корневых УЦ и сам Unbound. На VDS убедитесь, что порт 53 доступен клиентам вашей сети (если резолвер не только локальный), а 853 наружу, как правило, не требуется — мы шифруем исходящие, а не принимаем DoT от клиентов.

apt update
apt install unbound ca-certificates

Создаём/обновляем корневой якорь DNSSEC (root trust anchor). Обычно пакет делает это сам в post-install, но явно выполнить полезно:

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

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Базовая конфигурация Unbound с DNSSEC

Начнём с общего конфига, включающего валидацию, защитные и производительные опции. Создадим файл в каталоге include, чтобы не трогать основной:

# /etc/unbound/unbound.conf.d/00-base.conf
server:
  username: "unbound"
  directory: "/etc/unbound"
  tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

  # Интерфейсы: локально (и/или ваш LAN)
  interface: 127.0.0.1
  interface: ::1
  # Пример для LAN (подставьте свою сеть):
  # access-control: 192.168.0.0/16 allow
  # access-control: 10.0.0.0/8 allow
  access-control: 127.0.0.0/8 allow
  access-control: ::1 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

  # DNSSEC и жёсткие настройки
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  val-permissive-mode: no
  harden-glue: yes
  harden-dnssec-stripped: yes
  harden-below-nxdomain: yes
  qname-minimisation: yes
  aggressive-nsec: yes

  # Размеры и кеш
  msg-cache-size: 64m
  rrset-cache-size: 128m
  cache-min-ttl: 60
  cache-max-ttl: 86400
  prefetch: yes
  prefetch-key: yes
  serve-expired: yes
  serve-expired-ttl: 3600
  serve-expired-client-timeout: 1800

  # Сетевые параметры и MTU
  edns-buffer-size: 1232
  max-udp-size: 1232
  so-reuseport: yes
  num-threads: 2
  outgoing-range: 512
  unwanted-reply-threshold: 10000

  # Приватность
  hide-identity: yes
  hide-version: yes
  use-caps-for-id: yes

remote-control:
  control-enable: yes
  control-interface: 127.0.0.1

Проверяем синтаксис и запускаем:

unbound-checkconf
systemctl enable --now unbound
systemctl status unbound --no-pager

Вариант A: апстримы DoT (DNS-over-TLS)

DoT в Unbound настраивается нативно через forward-zone с явным указанием SNI-имени для TLS-верификации. Создадим отдельный файл:

# /etc/unbound/unbound.conf.d/10-forward-dot.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes

  # Cloudflare DoT (пример)
  forward-addr: 1.1.1.1@853#cloudflare-dns.com
  forward-addr: 1.0.0.1@853#cloudflare-dns.com

  # Quad9 DoT (пример)
  forward-addr: 9.9.9.9@853#dns.quad9.net
  forward-addr: 149.112.112.112@853#dns.quad9.net

  # Google DoT (пример)
  forward-addr: 8.8.8.8@853#dns.google
  forward-addr: 8.8.4.4@853#dns.google

  # Жёсткая стратегия: только шифрованный апстрим
  forward-first: no

Ключевые моменты:

• forward-tls-upstream: yes включает TLS к апстриму.
• @853#hostname задаёт порт и имя для SNI и проверки сертификата.
• forward-first: no запрещает откат на нешифрованный DNS при ошибке апстрима.

Ещё раз проверяем конфиг и перезапускаем:

unbound-checkconf
systemctl restart unbound

Проверка работы и DNSSEC

Проверим, что ответы идут через наш резолвер, а флаг AD (Authenticated Data) выставляется при валидации DNSSEC:

dig +dnssec +multi +ad example.com @127.0.0.1

В корректном ответе для домена, подписанного DNSSEC, вы увидите ad среди флагов. Для негативного теста запросите домен с заведомо «битой» подписью, и резолвер должен отказать:

dig +dnssec +cdflag dnssec-failed.org A @127.0.0.1

Если AD не появляется, убедитесь, что включены auto-trust-anchor-file и опции harden, а апстрим действительно возвращает DNSSEC-данные. Также проверьте синхронизацию времени на сервере (TLS и DNSSEC чувствительны к сдвигу часов).

Вариант B: апстримы DoH через локальный прокси

Unbound остаётся валидирующим кеширующим резолвером, а DoH реализуем отдельным локальным процессом-прокси, который слушает на loopback и уводит запросы в HTTPS. Для Unbound это обычный апстрим на 127.0.0.1:порт.

Подойдёт любой надёжный DoH-прокси. Ниже — пример systemd-юнита для dnsproxy (как одного из вариантов). Предполагается, что бинарь установлен в /usr/local/bin/dnsproxy и доступен пользователю dnsproxy:

# /etc/systemd/system/dnsproxy.service
[Unit]
Description=DNSProxy DoH forwarder
After=network-online.target
Wants=network-online.target

[Service]
User=dnsproxy
Group=dnsproxy
AmbientCapabilities=CAP_NET_BIND_SERVICE
ExecStart=/usr/local/bin/dnsproxy --listen 127.0.0.1:5054 --upstream https://dns.google/dns-query --upstream https://cloudflare-dns.com/dns-query --bootstrap 8.8.8.8 --bootstrap 1.1.1.1 --cache --http3
Restart=on-failure
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectKernelLogs=yes
MemoryDenyWriteExecute=yes
LockPersonality=yes
SystemCallFilter=@system-service

[Install]
WantedBy=multi-user.target

Запускаем прокси и настраиваем Unbound forward на него:

systemctl daemon-reload
systemctl enable --now dnsproxy

# /etc/unbound/unbound.conf.d/11-forward-doh.conf
# Используйте этот файл вместо 10-forward-dot.conf (не одновременно)
forward-zone:
  name: "."
  forward-first: no
  forward-addr: 127.0.0.1@5054

Проверки те же — dig к 127.0.0.1 и контроль флага AD. Важно: DoH-прокси должен быть надёжным, а на уровне Unbound остаётся валидация DNSSEC и кеширование. Если прокси недоступен, Unbound корректно зафейлит запрос (благодаря forward-first: no не будет попыток уйти на нешифрованный DNS).

Интеграция с системой

Чтобы все приложения использовали локальный резолвер, пропишите 127.0.0.1 (и ::1 для IPv6) в /etc/resolv.conf или настройте ваш DHCP/DNS на раздачу IP узла с Unbound как основного рекурсора. Если в системе работает systemd-resolved со «стабом» на 127.0.0.53, отключите его stub-listener и направьте resolved на 127.0.0.1:53, либо вовсе используйте только Unbound.

Не допускайте, чтобы Unbound стал открытым резолвером в Интернет. Явно ограничивайте access-control сетями, которые вы контролируете.

Если параллельно настраиваете почтовые политики, пригодится материал про записи SPF, DKIM и DMARC: записи DNS для email-аутентификации.

Тюнинг производительности

Unbound отлично масштабируется на многопроцессорных конфигурациях. Основные точки:

• Память кеша: увеличивайте msg-cache-size и rrset-cache-size под ваш профиль трафика.
• Потоки: подбирайте num-threads по числу CPU, но без фанатизма. Часто 2–4 потока быстрее одного большого.
• Prefetch: prefetch и prefetch-key повышают hit-rate за счёт проактивного обновления горячих записей.
• MTU: edns-buffer-size: 1232 снижает риск фрагментации и проблем на «узких» каналах.
• Serve-expired: позволяет выдавать слегка устаревшие ответы при кратковременных сбоях апстримов.

Если нагрузка разнородная (веб-приложения, CI, базы), вынесите Unbound в выделённую ВМ и держите рядом с вебом/бэкендом, чтобы сократить RTT. Это даёт ощутимый прирост производительности, особенно при холодном кеше.

Безопасность конфигурации

• Ограничьте доступ: access-control для нужных подсетей, остальным refuse.
• Отключите рекурсию для «чужих» сетей, не публикуйте публичный 53 наружу без необходимости.
• Включите жёсткие опции: harden-*, qname-minimisation, aggressive-nsec.
• Следите за временем системы: синхронизация через NTP/Chrony обязательна для TLS и DNSSEC.
• Регулярно обновляйте корневой якорь: пакет и unbound-anchor решают это автоматизацией, но мониторинг не помешает.

Наблюдение и статистика

Unbound умеет отдавать метрики через unbound-control. Сгенерируйте ключи для удалённого управления и проверяйте counters:

unbound-control-setup
unbound-control -c /etc/unbound/unbound.conf stats_noreset
unbound-control -c /etc/unbound/unbound.conf list_local_zones
unbound-control -c /etc/unbound/unbound.conf lookup example.com

На практике важно следить за долей кеш-хитов, временем ответа, количеством SERVFAIL (часто это проблемы DNSSEC/апстрима) и ретраями к апстримам.

Диагностика частых проблем

• Нет флага AD: проверьте auto-trust-anchor-file, синхронизацию времени, параметры harden-*, и что апстримы не режут DNSSEC.
• TLS-ошибки к DoT: убедитесь, что tls-cert-bundle указывает на актуальные корневые сертификаты, а SNI-имя (#hostname) соответствует апстриму.
• Фрагментация: уменьшите edns-buffer-size и max-udp-size до 1232 или ниже и перепроверьте.
• Высокий latency: добавьте несколько географически близких апстримов, включите prefetch, увеличьте кеши, разместите резолвер ближе к потребителям.
• Открытый резолвер: проверьте access-control и firewall, закройте 53/UDP и 53/TCP снаружи, если резолвер только для внутренней сети.

Мини-чеклист внедрения

1. Поставьте Unbound и сертификаты УЦ, сгенерируйте root key через unbound-anchor.
2. Включите DNSSEC и защитные опции, настройте интерфейсы и ACL.
3. Выберите апстрим: DoT (нативно) или DoH (через локальный прокси).
4. Проверьте unbound-checkconf, перезапустите и протестируйте dig +dnssec +ad.
5. Интегрируйте в систему: resolv.conf/DHCP, убедитесь, что клиенты ходят через локальный резолвер.
6. Подкрутите кеш и потоки под вашу нагрузку, включите мониторинг.

Итоги

Unbound с DoT/DoH апстримами — практичный способ повысить безопасность и приватность DNS без жертв в производительности. Локальный кеш снижает задержки, DNSSEC гарантирует целостность, а шифрование апстрима защищает от пассивного наблюдения и подмены. На VDS такая схема легко разворачивается, масштабируется и переносится между окружениями, оставаясь прозрачной для приложений и пользователей.

Для большинства задач достаточно DoT: минимум сложностей и высокая предсказуемость. DoH оставляйте как доп. вариант через локальный прокси — полезно там, где только HTTPS-трафик «поднимается». В обоих сценариях Unbound остаётся точкой контроля: кеш, политика безопасности, DNSSEC и наблюдаемость у вас под рукой.