так что я действительно новичок в этом и следил за этот учебник чтобы настроить привязку, и до 4:50 у меня не было проблем, я мог пинговать, использовать nslookup и иметь подключение к Интернету с DNS-сервером, затем нам пришлось добавить зоны и создать файлы зон (просто создав их), отлично, я перезапускаю, чтобы увидеть, есть ли какие-нибудь проблемы (я использую виртуальную машину, кстати), тогда я больше не мог пинговать, использовать nslookup, и у меня даже не было подключения к Интернету. Это то, что я получил с помощью systemctl status
Redirecting to /bin/systemctl status -l named.service
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor prese$
Active: failed (Result: exit-code) since jue 2019-04-25 23:14:30 -04; 3min 3$
Process: 3355 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "y$
abr 25 23:14:30 linux bash[3355]: _default/0.168.192.in-addr.arpa/IN: bad zone
abr 25 23:14:30 linux bash[3355]: zone localhost.localdomain/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone localhost/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.$
abr 25 23:14:30 linux bash[3355]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial$
abr 25 23:14:30 linux bash[3355]: zone 0.in-addr.arpa/IN: loaded serial 0
abr 25 23:14:30 linux systemd[1]: named.service: control process exited, code=e$
abr 25 23:14:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain$
abr 25 23:14:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:14:30 linux systemd[1]: named.service failed.
Я думал, что это из-за пустых файлов зон, поэтому я заменил named.conf без зон, попытался перезапустить с перезапуском службы named, но получил (снова):
Failed to start BIND : Redirecting to /bin/systemctl start named.service Job
for named.service failed because the control process exited with error code.
See "systemctl status named.service" and "journalctl -xe" for details.
Так я и сделал
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since jue 2019-04-25 23:25:30 -04; 1min 3s ago
Process: 5557 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=1/FAILURE)
Process: 5552 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS)
abr 25 23:25:30 linux named[5559]: found 2 CPUs, using 2 worker threads
abr 25 23:25:30 linux named[5559]: using 2 UDP listeners per interface
abr 25 23:25:30 linux named[5559]: using up to 21000 sockets
abr 25 23:25:30 linux named[5559]: loading configuration from '/etc/named.conf'
abr 25 23:25:30 linux named[5559]: open: /etc/named.conf: permission denied
abr 25 23:25:30 linux named[5559]: loading configuration: permission denied
abr 25 23:25:30 linux systemd[1]: named.service: control process exited, code=exited status=1
abr 25 23:25:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
abr 25 23:25:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:25:30 linux systemd[1]: named.service failed.
Это проблема с разрешением, но раньше она работала отлично, поэтому я в растерянности.
Вот что я получаю, выполняя ls -l /etc/ named.conf:
-rw-r-----. 1 root root 1808 abr 25 15:13 /etc/named.conf
И это когда я делаю ls -Z /etc/ named.conf (если это имеет какое-то отношение к selinux):
-rw-r-----. 1 root root unconfined_u:object_r:etc_t:s0 /etc/named.conf
Не уверен, что это поможет, но вот named.conf
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
У меня также нет папки chroot в / etc / named /
Есть ли решение для этого? Спасибо.
когда я заменил named.conf контекст selinux испортился, при выполнении ls -Z он должен выглядеть так
-rw-r--r--. root root system_u:object_r:named_conf_t:s0 named.conf
Как видите, у меня все по-другому, для сброса я использовал
restorecon -RFv /etc/named.conf
Однако при этом выполнение ls -Z дало мне это
-rw-r-----. root root system_u:object_r:named_conf_t:s0 named.conf
Чтобы добавить последнюю букву "r", чтобы все могли ее прочитать, я сделал
chmod 644 /etc/named.conf
Остановил названную службу и перезапустил ее, и она снова работает.
В CentOS 7 привязка по умолчанию запускается как named пользователь, а не 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
То же самое: но с Debian 10 ISC Bind 9.11.5.
Я предоставляю контрольный список, чтобы убедиться, что остальная часть сообщения неприменима. Вы можете проверить следующие каталоги на наличие каких-либо ошибочных настроек конфигурации пути PID для Bind9 / named.
/etc/default/named (или /etc/default/bind9) для PIDFILE=/etc/named/named.conf (или любой include config файлы) для pid-file=PIDfile=Как только приведенный выше контрольный список будет выполнен ... вы можете перейти к концу этого TL; DR к Обходной путь раздел для мгновенного решения.
Сообщение журнала частичных ошибок "не удалось 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 named daemon есть -u bind вариант, который противоречит жестко запрограммированному «корню».
Мы знаем, что named_os_issingleton () не является вызывающим mkdirpath() поскольку в выходных данных журнала отсутствует этот второй журнал ошибок «не удалось создать: ...».
Остается одинокий абонент named_os_openfile() вызов `mkdirpath () '. И называется он в двух местах:
Мы знаем, что это не server.c, потому что в нашем файле журнала нет второго сообщения об ошибке.
На данный момент мы можем только предполагать, что у него проблемы с записью файла PID. Неудивительно, что Debian решил отказаться от /var порция от обычного /var/run/named.pid. Этого и следовало ожидать, учитывая новейший стандарт файловой системы Linux 3.0, подробности здесь.
Как и вы, я тоже изменил этот каталог файлов PID с '/run/named'к'/run/bind'(или, точнее,'/run/bind-public'потому что я запускаю несколько именованных демонов в режиме конфигурации хоста-бастиона). И КТО-ТО все еще застрял named в качестве имени подкаталога, хотя мы изменили его на 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 - -
После того, как сделали, надоедливое бревно исчезло.
Я прошу вас проверить журналы аудита, и если вы используете какую-либо дополнительную файловую систему acl, проверьте и эти журналы. Если вы считаете, что это проблема SELinux, отключите и попробуйте еще раз, если это сработает, вам нужно исправить политики selinux. пожалуйста, проверьте https://www.systutorials.com/docs/linux/man/8-bind_selinux/ для привязки ссылки selinux.