В pfSense Plus 26.07 подтверждена ошибка CoreDNS, из-за которой DHCP-серверы после переключения с Unbound могут автоматически использовать DNS-адреса из System > General Setup вместо внутреннего адреса самого шлюза. Статус проблемы #17054 в официальном баг-трекере pfSense был изменён на Confirmed 29 августа 2026 года; до появления исправления конфигурацию DNS для DHCP рекомендуется проверять вручную.
Ошибка подтверждена в pfSense Plus 26.07
В официальном баг-трекере pfSense 29 августа изменён статус ошибки #17054 с New на Confirmed. Проблема имеет приоритет Normal, относится к категории CoreDNS и указана как затрагивающая pfSense Plus 26.07. Целевая версия с исправлением пока не назначена.
Сценарий проявляется после настройки CoreDNS. При его включении Unbound отключается, а CoreDNS становится локальным DNS-компонентом системы. Однако DHCP-серверы, которые до этого по умолчанию направляли клиентов на локальный DNS pfSense, могут начать использовать адреса, заданные в System > General Setup.
В результате клиенты получают через DHCP не внутренний IP-адрес pfSense, а DNS-серверы из глобальных системных настроек. Если там указаны внешние резолверы, запросы клиентов могут идти напрямую к ним вместо локального CoreDNS.
| Параметр | Статус |
| Затронутая версия | pfSense Plus 26.07 |
| Компонент | CoreDNS |
| Статус ошибки | Confirmed |
| Приоритет | Normal |
| Целевая версия исправления | Не указана |
| Временный обход | Явно задать внутренний адрес pfSense в DNS Server 1 для DHCP |
Почему это важно для CoreDNS и Netgate Nexus
CoreDNS появился в pfSense Plus 26.07 как один из новых компонентов Netgate Nexus. В описании релиза 26.07 Netgate указывает, что CoreDNS интегрирован с Nexus и использует собственный плагин rexdns. Вместе с ThreatGate он предназначен для высокопроизводительной обработки DNS и больших списков доменов и адресов.
Из-за ошибки значение имеет не сам факт отключения Unbound — это ожидаемая часть перехода на CoreDNS, — а то, какой DNS затем получают DHCP-клиенты. pfSense должен направлять их на внутренний интерфейс шлюза, чтобы локальный DNS-компонент продолжал обслуживать запросы. В текущем сценарии вместо этого могут подставляться серверы из System > General Setup.
Похожее поведение описано и в отдельной заявке #17051, где при активном CoreDNS Kea DHCP подставляет системные DNS вместо LAN-адреса pfSense. Эта заявка пока остаётся в статусе New, тогда как #17054 уже официально подтверждена.
Практический эффект зависит от конфигурации. Если в System > General Setup указаны публичные или корпоративные внешние DNS-серверы, клиенты могут обходить локальную обработку запросов CoreDNS. Для сетей, где CoreDNS используется совместно с ThreatGate или локальными DNS-политиками, это способно привести к неожиданному изменению маршрута DNS-запросов и поведения фильтрации.
Как проверить конфигурацию и обойти проблему
До выпуска исправления администратору стоит проверить DHCP-настройки сразу после включения CoreDNS, особенно если ранее клиенты автоматически использовали локальный Unbound.
- Открыть настройки DHCP для используемого интерфейса.
- Проверить значения DNS Server, которые будут выдаваться клиентам.
- Убедиться, что вместо внешних адресов из System > General Setup используется внутренний адрес соответствующего интерфейса pfSense.
- При необходимости явно задать этот адрес в поле DNS Server 1 и применить конфигурацию.
- Обновить DHCP-аренду на тестовом клиенте и проверить фактически полученный DNS-сервер.
Именно такой ручной обход указан в подтверждённой заявке: внутренний адрес интерфейса можно явно прописать как DNS Server 1. После этого DHCP не будет полагаться на некорректное значение по умолчанию.
Дополнительно стоит проверить реальное направление DNS-трафика с клиентского устройства. Одного визуального просмотра настроек недостаточно, если аренды DHCP были получены до изменения конфигурации.
Резюме
Ошибка не обозначена как отдельная уязвимость безопасности и не имеет собственного CVE; в баг-трекере ей присвоен обычный приоритет Normal. Тем не менее для сетей, где pfSense Plus 26.07 использует CoreDNS как локальный резолвер и точку применения DNS-политик, проблема имеет прямое эксплуатационное значение.
На 30 августа исправление или целевая версия для #17054 не указаны. Администраторам pfSense Plus 26.07, включившим CoreDNS, стоит проверить, какие DNS-адреса фактически выдаются DHCP-клиентам, и при необходимости явно назначить внутренний адрес pfSense до появления штатного исправления.
