Коротко — такое поведение обычно не «магия Unbound», а либо сетевой/драйверный/аппаратный глюк (пакеты до/от 53‑го порта теряются на уровне NIC/switch/firewall), либо проблема с конфигурацией резолвера (ограничения на исходящие запросы/пул сокетов, форвардинг и upstream, DNSSEC, длительные таймауты), либо исчерпание ресурсов/ограничения pf. Ниже пошагово — что проверить, как диагностировать и какие параметры менять.
1) Подготовка — собрать базовые данные
- Когда происходит простой — запишите точное время, периодичность и длительность.
- Обновите OPNsense + плагины до актуальной стабильной версии (бывают багфиксы для Unbound/драйверов).
- Убедитесь, что только Unbound слушает 53 порт: в консоли OPNsense:
- netstat -an | grep '\.53 ' (или sockstat -4l | grep 53)
- если видите 2 процесса — возможен конфликт (например dnsmasq/another resolver).
2) Проверки в момент сбоя (очень важно — собирать во время простоя)
- Проверить доходят ли запросы до маршрутизатора:
- tcpdump -n -i <lan_if> port 53
- если пакеты с клиентов доходят до box, но ответа нет -> проблема в Unbound/OS.
- если пакеты не доходят -> сеть/файрвол/switch/клиент.
- Проверить, отвечает ли Unbound локально:
- dig @127.0.0.1 example.com
- dig @<LAN_IP> example.com (с клиента)
- Поведение «локально не отвечает, а внешние запросы ?» укажет на проблему процесса/параметров Unbound.
- Логи:
- tail -f /var/log/system.log и /var/log/unbound.log (или через UI: System > Log Files)
- Включить временно подробный лог/отладку для Unbound (в UI Debug/Advanced).
- Статистика Unbound:
- unbound-control status
- unbound-control stats_noreset
- unbound-control dump_cache
Эти команды покажут, есть ли рост ошибок, очередей, перекрытие лимитов.
- Состояния PF / лимиты:
- pfctl -s info
- pfctl -s states | wc -l
- pfctl -sr (правила)
Если таблицы состояний переполняются — PF может начать сбрасывать пакеты.
3) Частые причины и как их проверить/устранить
A) Пакеты теряются/задерживаются на NIC/драйвере/оффлоадинге
- Симптом: tcpdump видит запросы в интерфейсе, но Unbound не отвечает; или скачки задержек, периодические пропадания.
- Решение: отключить аппаратное оффлоадирование на проблемном интерфейсе(ах):
- ifconfig <if> -rxcsum -txcsum -tso -lro -gso
- В OPNsense: Interfaces > Settings > отключить hardware checksum offloading, Large Receive Offload и т.п. (или сделать через /etc/rc.conf tunables)
- Проверить dmesg на сообщения драйвера: dmesg | egrep -i 'err|fail|ix|em|igb|i40e'
- Если используются 2.5Gb NICs (i225/Marvell), убедитесь, что драйверы актуальны и отключите агрессивные оффлоады — эти чипы на FreeBSD иногда проблемны.
B) Форвардинг к upstream провайдеру / проблемы с upstream
- Симптом: Unbound в режиме forwarder/обычно ожидает upstream; если провайдер пакеты не отвечает — клиенты получают таймауты.
- Проверка: временно отключить «Forwarding Mode» (делать Unbound полнофункциональным рекурсором) или сменить/добавить надёжные upstream (например публичные 1.1.1.1, 9.9.9.9) для теста.
- Если у вас включён форвардинг и upstream иногда недоступен, это объясняет краткие паузы.
C) Ограничения Unbound (число исходящих запросов, TCP/UDP лимиты)
- Симптом: при всплесках запросов (множество клиентов, IoT) Unbound может упираться в лимит исходящих сокетов/очередей.
- Что смотреть: значения outgoing-range, msg-cache-size, rrset-cache-size, num-threads; статистика unbound-control stats (timeouts, servfail, etc).
- Решение: если у вас много устройств и частые запросы — увеличить outgoing-range/num-threads/кэши. В OPNsense в Advanced Unbound — поставить num-threads ≈ числу ядер, включить prefetch, настроить кэши согласно памяти (но не ставьте гигантские значения без проверки).
- Если не уверены, тест: временно перезапустить Unbound при простое — восстанавливается ли работа (если да — возможно переполнение внутренних структур).
D) DNSSEC / проверки подписи / долгие таймауты
- Симптом: проверки DNSSEC для некоторых зон могут тормозить (особенно при нестабильном интернет-соединении).
- Проверка: временно отключить DNSSEC в Unbound и посмотреть, исчезают ли паузы.
- Долгие автообновления root hints/unbound-anchor обычно редки, но стоит проверить.
E) PF / state timeouts / rate limit / блокировки в правилах
- Симптом: пакеты до сервера не доходят или ответы блокируются.
- Проверка: podcast правилф, проверьте не установлен ли в pf правило лимитирования (max-src-conn, max-src-conn-rate).
- Посмотрите firewall logs (может быть блокировка из-за GeoIP, aliases или limit).
F) Аппаратные/энергосберегающие режимы CPU/питания
- На некоторых мини‑ПК агрессивные C‑states/еще энергосбережение могут вызывать краткие «подвисания» — проверьте BIOS/firmware, отключите глубокие C‑states или включите режим производительности для теста.
4) Рекомендации по настройке для домашней сети (практические)
- В общем виде для персонального/домашнего использования:
- Number of threads = количество логических ядер (или 1–2 для простых сетей). На i3/двухъядерных — 2.
- Включить Prefetch (Prefetch support) — помогает при частых повторных запросах к истекающим записям.
- Кеш: msg-cache-size и rrset-cache-size — выставьте умеренно (например, rrset 16–64MB, msg-cache 4–8MB) в зависимости от общей памяти; OPNsense по умолчанию обычно адекватен.
- Если не требуется — выключите Forwarding Mode и работайте как корректный рекурсор (меньше зависимостей от upstream).
- Включить DNSSEC, если хотите проверку, но для диагностики временно отключайте.
- Ограничьте «Outgoing interfaces» корректно — если указываете конкретный интерфейс, убедитесь, что он стабилен (лучше оставить пустым, чтобы Unbound сам выбирал).
- Не ставьте чрезмерно маленькие таймауты — Unbound имеет свои таймауты для повторных запросов; меняйте только с пониманием.
5) Мониторинг и длительная диагностика
- Включите временно детализированный лог (debug) и соберите логи в момент сбоя.
- Делайте tcpdump на порту 53 и сохраняйте pcap для анализа в Wireshark (посмотреть, приходят ли запросы, уходят ли ответы, есть ли ICMP или RST).
- Используйте unbound-control stats polling (скрипт/сборщик) для графиков QPS, cache-hits, timeouts, servfails.
- Если проблема повторяется регулярно — соберите:
- /var/log/unbound.log (вокруг события)
- вывод unbound-control status & stats
- tcpdump pcap (в момент сбоя)
- pfctl -s info & dmesg
и приложите — можно будет разбирать детальнее.
6) Быстрые тесты/фиксы, которые часто помогают
- Перезапустить Unbound при проявлении проблемы: service unbound restart — если это временно решает, значит проблема на стороне процесса (ресурсы/внутренний deadlock).
- Отключить оффлоады NIC.
- Отключить Forwarding — перейти на прямую рекурсию.
- Временно отключить DNSSEC для теста.
- Включить debug лог Unbound и собрать данные.
Если хотите, помогу конкретно: пришлите (или вставьте сюда) выводы в момент проблемы:
- unbound-control status
- unbound-control stats_noreset
- tail -n 200 /var/log/unbound.log
- результат netstat/sockstat для 53
- краткий pcap (или описание: приходят ли UDP пакеты, ответы?)
С этими данными смогу указать более точную причину и точечные настройки.