Unbound в Ubuntu может стать проверяющим DNSSEC рекурсивным резолвером небольшой доверенной LAN без публичного сервиса. Здесь используется Ubuntu 24.04 LTS amd64 и сопровождаемый пакет, проверенный 11 октября 2026 года как 1.19.2-1ubuntu3.10. Обновления меняют ревизию: проверяйте свои репозитории Ubuntu, не закрепляя устаревшую сборку. Полного сквозного авторского испытания не проводилось.［1］

Ключевые выводы

Начните с loopback, затем привяжите один настоящий LAN-адрес и минимальную разрешённую подсеть.

Сохраните доверенный корневой якорь, служебную идентичность и chroot пакета Ubuntu.

DNSSEC проверяет подписанные данные, но не шифрует DNS и не фильтрует рекламу.

Сначала делайте явные запросы, затем переключайте одного клиента, сохранив прежние настройки.

Подходит ли Unbound в Ubuntu для вашей задачи?

Вы должны владеть хостом и сетью и обслуживать рекурсивный резолвер. Руководство по ответственности за самостоятельное размещение распределяет обновления, журналы, политику доступа и восстановление. Если нужен выходной адрес или другой путь трафика, сначала сравните роли DNS и VPN: резолвер отвечает на имена, не передаёт весь прикладной трафик.

Unbound автоматически не блокирует рекламу: DNS-фильтрация требует отдельной политики. Если разрешение уже нарушено, сначала проверьте цепочку резолвера Ubuntu. Общая последовательность диагностики устройств разделяет ошибки приложений и DNS.

Это небольшой рекурсивный резолвер, не forwarding-профиль, установка на маршрутизаторе или публичная DNS-служба. Рекурсия требует разрешённого исходящего UDP и TCP 53 к авторитетным серверам. Если сеть запрещает это, нужен согласованный альтернативный способ, не отключение сетевого контроля. Зарезервируйте стабильный LAN-адрес существующим процессом владельца сети.

Запишите пакеты, конфигурацию Unbound и includes, unit и drop-in, автозапуск, firewall, адреса, маршруты и владельца системного DNS. Приватные копии храните вне активных includes. Сохраните независимое управление. Если путями владеет действующий Unbound или автоматизация, согласуйте изменение с владельцем, не вставляя второй конфликтующий server-блок.

Шаг 1: проверьте порт 53 и пакет Ubuntu

До установки изучите привязки и системный DNS. systemd-resolved может слушать loopback-stub 127.0.0.53, отличный от 127.0.0.1. Wildcard-слушатель способен конфликтовать с обоими. Не отключайте системный резолвер и не переписывайте /etc/resolv.conf ради свободного порта.［6］

sudo ss -lntup 'sport = :53'
resolvectl status
ip -4 address
ip -6 address
sudo apt-get update
sudo apt-get install unbound dnsutils
apt-cache policy unbound
unbound -V
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl status unbound.service --no-pager

Установка может запустить службу: сразу проверьте её состояние и слушатели. При неожиданной широкой привязке остановитесь и разберитесь. Если пакет уже был установлен, сохраните исходное состояние. apt-cache policy показывает установленную и доступную пакетные версии; unbound -V — сборку программы, не обязательно полную ревизию Ubuntu.

До нового файла прочитайте /etc/unbound/unbound.conf, include-директивы и /etc/unbound/unbound.conf.d/. Проверьте предоставленный пакетом root trust anchor и доступный каталог состояния, оставив их на месте. Не дублируйте auto-trust-anchor-file, не инициализируйте второй якорь вслепую, не задавайте username: "" и не убирайте chroot для подавления ошибки доступа. Исправляйте права и пути в рамках устройства пакета.［2］［6］

Актуальное upstream-руководство объясняет концепции, но его примеры и версия могут отличаться от Noble. Поля и стандартные значения здесь следуют руководству Ubuntu. Пакет продолжает отвечать за hardening и якорь доверия, если существующий администратор осознанно не настроил иначе.［2］［3］

Шаг 2: запустите частный DNS-резолвер Unbound на loopback

После согласования существующих interface и ACL создайте ранее отсутствовавший /etc/unbound/unbound.conf.d/reader-lan.conf привилегированным редактором, владелец root, права 644. Убедитесь, что основной файл включает этот каталог. Добавьте только следующий блок, сохранив остальные файлы пакета:

server:
    interface: 127.0.0.1
    port: 53
    access-control: 127.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    access-control: ::/0 refuse
    hide-identity: yes
    hide-version: yes
    verbosity: 1
    log-queries: no

Широкие IPv4- и IPv6-ACL отказывают клиентам; это не адреса привязки. Более конкретное loopback-разрешение приоритетнее. Только явный IPv4-loopback в этом дополнении не запрашивает входящий IPv6-слушатель. Однако другие includes могут добавлять интерфейсы или ACL: проверяйте объединённую конфигурацию и реальные сокеты.［2］

До перезапуска проверьте эффективный файл. unbound-checkconf должен завершиться с кодом ноль, но не подтверждает ответы, сеть, DNSSEC или безопасность firewall.［4］

sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound.service
sudo systemctl status unbound.service --no-pager
sudo ss -lntup 'sport = :53'
dig @127.0.0.1 example.com A

Посмотрите ограниченную диагностику: sudo journalctl -u unbound.service -n 30 --no-pager. Явный loopback-запрос должен получить DNS-ответ от нужного процесса. Статус и ответ интерпретируйте отдельно: NOERROR без запрошенной записи может быть допустимым. При bind-ошибке устраните настоящий конфликт адресов, при ошибке доступа изучите пакетные пути. Не подставляйте 0.0.0.0 как обход.

Шаг 3: ограничьте контроль доступа Unbound одной LAN

Заменяйте файл упражнения только после исправной loopback-проверки. Подставьте реальный стабильный LAN IPv4 хоста вместо 192.168.50.2 в конфигурации и командах. Вместо 192.168.50.0/24 укажите минимальную настоящую разрешённую подсеть; не считайте все частные адреса своей LAN.

server:
    interface: 127.0.0.1
    interface: 192.168.50.2
    port: 53
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.50.0/24 allow
    access-control: 0.0.0.0/0 refuse
    access-control: ::/0 refuse
    hide-identity: yes
    hide-version: yes
    verbosity: 1
    log-queries: no

Привязка возможна только к назначенным адресам. Избегайте 0.0.0.0, ::, широких частных разрешений и port forwarding маршрутизатора. Доступ определяет наиболее конкретный ACL. Пример не добавляет IPv6-интерфейс или клиентское разрешение. Если они нужны, отдельно спроектируйте фактический интерфейс, минимальный префикс и политику. Входящие слушатели, исходящие IPv6-запросы и ответы AAAA — разные свойства.［2］

Повторно проверьте файл, перезапустите службу и изучите UDP- и TCP-слушатели. Изменение интерфейсов требует restart; не предполагайте, что reload создаст сокет. Сохраните текущего управляющего firewall. При необходимости разрешите только UDP и TCP 53 от разрешённой подсети к LAN-адресу хоста. Запишите изменения, сохраните управление, не очищайте и не отключайте общий firewall. ACL Unbound и firewall ограничивают разные слои.

Для уже активной политики, которой владеет UFW, узкие добавления выглядят так:

sudo ufw allow proto udp from 192.168.50.0/24 to 192.168.50.2 port 53 comment 'unbound-lan'
sudo ufw allow proto tcp from 192.168.50.0/24 to 192.168.50.2 port 53 comment 'unbound-lan'

Замените пример адреса и подсети заранее. Не включайте UFW ради выполнения этих команд. Если firewall имеет другого владельца, используйте его эквивалентную процедуру.

Шаг 4: проверьте ответы, DNSSEC, кэш и отказ

На одном разрешённом LAN-клиенте с dig делайте явные запросы до изменения системного DNS:

dig @192.168.50.2 example.com A
dig @192.168.50.2 example.com A +tcp
dig @192.168.50.2 example.com AAAA
dig @192.168.50.2 com. SOA +dnssec
dig @192.168.50.2 dnssec-failed.org A +dnssec
dig @192.168.50.2 dnssec-failed.org A +dnssec +cdflag

Читайте адрес сервера, статус, тип и флаги. Подписанный положительный запрос вроде com. SOA при успешной валидации должен дать аутентифицированные данные с ad. Намеренно сломанный dnssec-failed.org должен вернуть SERVFAIL, пока остаётся bogus. Иной результат с +cdflag помогает различить отказ валидации и доступность. CD используйте только диагностически, не как обычную клиентскую политику. Это ожидаемые наблюдения, не утверждение о текущих живых результатах.［2］［5］

Проверка читателя	Ожидаемое наблюдение	Что проверить при расхождении
Явные UDP и TCP запросы разрешённого клиента	Ответы приходят с выбранного LAN-адреса	Слушатели и firewall каждого транспорта
Подписанный положительный ответ	Успешная проверка и `ad` для аутентифицированных данных	Время, якорь, журналы и актуальную подпись выбранного имени
Известный bogus без CD	`SERVFAIL`, пока условие bogus сохраняется	Эффективный валидатор и состояние домена; не отключайте проверку
Повтор кэшируемого ответа до истечения TTL	TTL кэшированного ответа может уменьшаться	Prefetch, истечение и разные пути кэша меняют наблюдение
Контролируемый источник вне подсети достигает слушателя	Этот ACL возвращает `REFUSED`	Firewall может вместо этого дать тайм-аут; проверьте настоящий источник
Инвентаризация IPv4 и IPv6 сокетов	Только запланированные слушатели	Все includes и семейства firewall до вывода о границе
Новый запрос после restart	Разрешение имён для разрешённого клиента снова работает	Восстановите безопасный файл, если исходное состояние не вернулось

Источник для проверки отказа должен быть действительно отдельным и разрешённым. Тайм-аут из одной сети не доказывает исключение всех посторонних сетей. Не открывайте публичный доступ и не расширяйте разрешения ради ответа отказа. Если контролируемого источника нет, отметьте эту проверку невыполненной.

Для наблюдения кэша повторите те же имя, тип и класс вскоре после успеха и сравните TTL с указанным сервером. Меньшее время запроса не является benchmark: планирование, сетевые кэши, prefetch и upstream влияют на результат. DNSSEC защищает подлинность подписанных данных, не секретность запросов. Query logs в примере выключены, но диагностика всё ещё может содержать адреса: храните её приватно.

Шаг 5: переключите одного клиента и отработайте восстановление

После явных проверок сохраните прежние DNS-значения одного клиента и их владельца: DHCP, NetworkManager, networkd, VPN или иной поддерживаемый менеджер. Измените DNS через его штатный интерфейс на фактический LAN-адрес резолвера. Маршрутизатор и остальные клиенты остаются без изменений. Проверьте эффективный резолвер и обычные приложения. Приложение с собственным DoH может обходить системный DNS; исправный браузер не доказывает использование Unbound системой.

Для восстановления сначала верните точные прежние DNS-настройки клиента через того же владельца и проверьте обычное разрешение. Удалите только записанные добавления firewall упражнения, затем верните исходную конфигурацию Unbound. Если ранее отсутствовавший reader-lan.conf создан упражнением, удалите только его, сохранив якорь и другие includes. Проверьте эффективный исходный файл, перезапустите либо остановите службу согласно прежнему состоянию, восстановите автозапуск. Проверьте слушатели, системный резолвер, ответы и управление.

Если существующая процедура меняла unit или drop-in, восстановите их и выполните sudo systemctl daemon-reload перед перезапуском. Пакет удаляйте только если он добавлен упражнением и других зависимостей нет. Не удаляйте состояние якоря действующей установки и не переписывайте /etc/resolv.conf вслепую. При сомнении прекратите изменения и используйте независимый канал управления.

Чтобы добавить фильтрацию перед этим резолвером, AdGuard Home с раздельными апстримами может направлять выбранные домены в Unbound.

Итоги

Подтвердите loopback-разрешение до добавления выбранного LAN-слушателя.
Отдельно проверяйте оба транспорта, валидацию, отказ и реальный DNS клиента.
Сначала верните клиент, затем узко восстановите службу и политику хоста.

Часто задаваемые вопросы (FAQ)

Получится открытый публичный резолвер?

Цель привязана к конкретным частным интерфейсам и одной разрешённой подсети. Проверьте объединённые includes, сокеты, семейства firewall и upstream NAT: одного фрагмента недостаточно для доказательства всей границы.

Нужно отключить systemd-resolved?

Нет. Изучите фактические привязки и цепочку. Разные явные loopback-адреса могут сосуществовать; настоящий конфликт исправляется с учётом владельца.［6］

DNSSEC шифрует запросы?

Нет. Он проверяет подписанные DNS-данные. Этот рекурсивный UDP/TCP-вариант не добавляет клиентское шифрование и не скрывает запросы от сети.

Зачем проверять TCP вместе с UDP?

DNS использует оба транспорта. Успех UDP не доказывает работу TCP при большом ответе или другом поддерживаемом обмене.

Ответ AAAA доказывает наличие IPv6-слушателя?

Нет. Тип записи, семейство входящего транспорта и исходящая доступность — разные свойства; проверяйте сокеты непосредственно.

Быстрый второй запрос доказывает выигрыш скорости?

Нет. Наблюдайте кэш в контролируемых условиях, но одна разница времени не является надёжным benchmark или сравнением.

Сразу менять DNS маршрутизатора?

Нет. Сначала проверьте одного клиента и восстановление. Распространение на сеть вне этой процедуры и требует отдельного плана обслуживания и отката.

Отказ от ответственности: Используйте только разрешённые хосты и сети, соблюдая закон и политику. Это документированные шаги и ожидаемые проверки, не авторский отчёт, сертификат совместимости или гарантия производительности.

Источники:

Ubuntu noble-updates Unbound package — https://packages.ubuntu.com/noble-updates/unbound
Ubuntu noble unbound.conf manual — https://manpages.ubuntu.com/manpages/noble/man5/unbound.conf.5.html
NLnet Labs home resolver guide — https://unbound.docs.nlnetlabs.nl/en/latest/use-cases/home-resolver.html
NLnet Labs configuration checker — https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound-checkconf.html
Google Public DNS: DNSSEC failure example — https://developers.google.com/speed/public-dns/docs/troubleshooting/domains
NLnet Labs resolver configuration — https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Unbound в Ubuntu: частный DNS для доверенной LAN