BIND9: рекурсивные запросы запрещены для внутренней сети

#Что произошло и как распознать неисправность

Внутренние пользователи отправляют DNS-запросы на собственный BIND9, но внешние домены не разрешаются: ответ REFUSED, отсутствует флаг RA или клиент видит отказ службы. При этом записи зон, за которые сервер отвечает авторитетно, могут открываться нормально. Причина часто в recursion, allow-recursion, allow-query-cache или сетевом доступе. Рекурсия нужна клиентам доверенной сети, но публичный рекурсор без ограничений опасен: его могут использовать для атак с усилением трафика. Исправлять нужно только допуск конкретной внутренней подсети и прослушивание на её интерфейсе, а не разрешать запросы всем.

#Причины и отличительные признаки

#Пошаговая диагностика и исправление

1. Проверьте отказ именно из проблемной сетиНа компьютере внутри нужной подсети откройте терминал и выполните dig @192.0.2.53 example.org A +recurse, заменив адрес DNS-сервера и домен. Если сервер отвечает status: REFUSED без RA, вероятно запрет. Если TIMEOUT — проверьте сеть и порт 53. Если NOERROR — настройка уже разрешает запрос, а проблема может быть в устройстве, которое использует другой DNS.
2. Сравните результат непосредственно с DNS-сервераВойдите по SSH на Linux-сервер и выполните dig @127.0.0.1 example.org A +recurse. Если localhost успешно отвечает, а клиентам отказано, запишите обе пары адресов и результаты. Если локальный запрос тоже REFUSED, проверьте отключённую рекурсию, view и обработку localhost. Не пытайтесь исправлять отказ изменением публичной зоны домена.
3. Определите реальную подсеть клиентовНа клиенте Linux выполните ip -br addr, на Windows откройте PowerShell и введите ipconfig. Запишите локальный IPv4 и маску; отличайте адрес устройства, адрес VPN и внешний IP. Если запрос приходит через NAT, BIND видит адрес транслятора, а не конечного пользователя. Для добавления разрешения нужен фактический адрес источника запроса, подтверждённый журналом или сетевой схемой.
4. Прочитайте активные правила и viewsНа DNS-сервере с SSH запустите sudo named-checkconf -p и найдите recursion, allow-recursion, allow-query-cache, allow-query-cache-on, view, match-clients. Вывод может содержать TSIG-ключи: не публикуйте его. Для чтения без раскрытия секретов используйте вывод с поддерживаемой вашей версией опцией скрытия ключей. Проверьте также, не включено ли recursion no в нужной view.
5. Подготовьте ограниченное изменениеСоздайте копию named.conf.options либо файла, в котором на вашей системе находятся параметры рекурсии. Добавьте только доверенный диапазон, например в acl "trusted_lan" { 192.0.2.0/24; localhost; }; и используйте его в allow-recursion и при необходимости allow-query-cache. Это учебный диапазон: замените его реальной внутренней подсетью, избегайте any; и не копируйте ACL в неправильную вложенность.
6. Проверьте синтаксис и примените настройку без отключения защитыПо SSH выполните sudo named-checkconf и убедитесь, что ошибок нет. Если named-checkconf возвращает строку с ошибкой, не перечитывайте конфигурацию; устраните строку или верните копию. Затем выполните sudo rndc reconfig для перечитывания конфигурации BIND. При отказе rndc сначала проверьте управляющее соединение и журналы, не перезапускайте всю сеть.
7. Проверьте внутреннего и постороннего клиента отдельноПовторите dig @192.0.2.53 example.org A +recurse из доверенной сети. Ожидается корректный рекурсивный ответ с RA. Если есть возможность, проверьте с постороннего адреса: рекурсия должна оставаться запрещённой. Отдельно убедитесь, что авторитетные публичные зоны отвечают независимо от доступа к кешу. Никогда не отправляйте из открытой сети тестов больше необходимого.
8. Если результат не меняется, выясните источник конфигурацииПроверьте, что у BIND действительно выбран нужный view, клиент не использует DNS-over-HTTPS в обход локального сервера, а firewall не меняет исходный IP. Сверьте журналы и состояние службы. Для отката восстановите копию ACL, затем sudo named-checkconf и sudo rndc reconfig. До устранения причины не делайте DNS-сервер открытым рекурсором.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1На клиенте без sudo.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   На клиенте без sudo. Замените 192.0.2.53 на IP своего BIND9; example.org на проверочный существующий домен.

   dig @192.0.2.53 example.org A +recurse

   Вариант 2На Linux-сервере BIND9 после изменения ACL: проверка синтаксиса, sudo обязательно.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   На Linux-сервере BIND9 после изменения ACL: проверка синтаксиса, sudo обязательно.

   sudo named-checkconf

   Вариант 3На сервере с доступом rndc: перечитывает конфигурацию после успешного теста, требует sudo.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   На сервере с доступом rndc: перечитывает конфигурацию после успешного теста, требует sudo.

   sudo rndc reconfig

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

#Как проверить результат и что делать при неуспехе

Успех означает корректное разрешение внешних имён из доверенной сети при сохранении запрета рекурсии для остальных. При невозможности подтвердить ограничения не публикуйте сервер как публичный DNS до проверки доступа.