В CentOS 7 привязка запускается по умолчанию от имени пользователя с именем , а не от пользователя root , поэтому он не может прочитать ваш named.conf, поскольку он принадлежит root и доступен для чтения только root .

Как уже прокомментировал Хокан Линдквист, разрешения в CentOS 7 должны выглядеть следующим образом:

-rw-r-----. 1 root named 10672 04-09 20:02 /etc/named.conf

так и сделайте:

# chown root:named /etc/named.conf
# chroot 640 /etc/named.conf

Я бы попросил вас проверить журналы аудита, и если вы используете какую-либо дополнительную файловую систему acl, проверьте и эти журналы. Если вы думаете, что это проблема SELinux, отключите и попробуйте снова, если это сработает у вас необходимо исправить политики selinux. пожалуйста, проверьте https://www.systutorials.com/docs/linux/man/8-bind_selinux/ для ссылки на привязку selinux.

То же самое: но с Debian 10 ISC Bind 9.11.5.

Предварительный контрольный список

Я предоставляю контрольный список, чтобы убедиться, что остальная часть сообщения неприменима. Вы можете проверить следующие каталоги на предмет каких-либо ошибочных настроек конфигурации пути PID для Bind9 / named.

• / etc / default / named (или / etc / default / bind9 ) для PIDFILE =
• /etc/ named/ named.conf (или любого другого включают файлы конфигурации) для pid-file =
• /etc/systemd/system/bind9.conf для PIDfile =

Подробности, подробности, подробности

Один раз выше контрольный список готов ... вы можете перейти в конец этого TL; DR к разделу Временное решение для получения мгновенного решения.

Сообщение журнала частичных ошибок «could mkdir» найдено только в исходном файле bind9 / named / unix / os.c : ближайшая ссылка на строку находится в ISC Bind9 Github .

После ознакомления с исходным кодом для использования mkdirpath () и подтверждения того, что mkdirpath () используется только в bind9 / named / unix / os.c исходный код, я понял, что разработчики ISC не использовали более новый метод защиты разрешений групповых файлов без полномочий root ... но поскольку код все еще жестко запрограммирован для того, чтобы именованный демон работал только как ' root 'группа, а не в' bind '(или' named ') группе ... пока.

Это особенно верно в Debian при запуске демона tmpfiles (через systemctl start tmpfilesd ), где управление / var / run (точнее, / run ) управляется демоном tmpfiles (а не именованным демоном).

В параметрах CLI моего именованного демона есть опция -u bind , которая конфликтует с жестко запрограммированным «корнем».

Мы знаем, что named_os_issingleton () не является вызывающим для mkdirpath () , потому что в выводе журнала отсутствует тот второй журнал ошибок «не удалось создать: ...».

Остается одинокий вызывающий named_os_openfile () вызов mkdirpath (). И он вызывается в двух местах:

• server.c (для сохранения ключа в файл ключа)
• os.c (для записи файла PID)

Мы знаем, что это не server.c, потому что существует нет 2-го сообщения об ошибке в нашем файле журнала.

На данный момент мы можем только предполагать, что у него проблемы с записью PID-файла. Я не удивлен, что Debian решил убрать часть / var из своего обычного /var/run/ named.pid . Этого и следовало ожидать, учитывая новейший стандарт файловой системы Linux 3.0, подробные подробности можно найти здесь .

Как и вы, я тоже изменил этот каталог PID-файла с « / run / named » на « / run / bind » (или, точнее, « / run / bind-public ', потому что я запускаю несколько именованных демонов в режиме конфигурации хоста-бастиона). И КТО-ТО все еще застрял на с именем в качестве имени подкаталога, даже несмотря на то, что мы изменили его на bind .

На данный момент выполняется обратная трассировка вручную:

• mkdirpath ()
• named_os_openfile ()
• named_os_writepidfile ()

Повторно просматривая server.c , вы будете заметил, что определение named_g_defaultpidfile жестко запрограммировано на « / run / named », несмотря на все наши попытки перенастроить его на что-то другое. Он определен в globals.h ( здесь ).

Обходной путь

Обходной путь: ... создать подкаталог / run / named , чтобы подделать код привязки ISC во время запуска

   mkdir /run/named
   chown root:bind /run/named
   chmod u+rwx,g+rx-w,o-rwx /run/named

и «игнорировать его» на данный момент.

Но ... также, если вы запускаете демон tmpfiles при запуске, вам, вероятно, придется сделать это в /etc/tmpfiles.d/ named.conf (или bind.conf или, в моем случае, /etc/tmpfiles.d/bind-public.conf ):

#Type Path                 Mode User Group Age Argument

# We set the 2xxx part (g+s) of directories' chmod so
# that when the named/bind9 daemon creates 
# that PID file, its ownership would be bind:bind.
d  /run/bind           2770 root bind  - -

# Add the following line to suppress spurious log message    
d  /run/named          0750 root bind  - -

После создания надоедливый журнал пропал.

У меня была похожая проблема с некоторыми новыми скриптами, которые загружают обновления на локальные машины. Эти команды будут выполняться как «named» и позволят вам увидеть несколько простых ответов:

runuser -u named -- /usr/sbin/named-checkconf -z /etc/named.conf runuser -u named -- /usr/sbin/named-checkzone mydomain.internal /var/named/chroot/var/named/internal/mydomain.internal runuser -u named -- /usr/bin/ls -l /var/named/chroot/var/named/internal/

При необходимости вы можете изменить пути.