bind9 не работает при запуске службы bind9, но работает при явном запуске named.

Вопрос или проблема

У меня очень странная ситуация, которую я не до конца понимаю. У меня есть основной и резервный DNS, я проверил конфигурацию, и ошибок не возвращается. Если я пытаюсь запустить bind9 как сервис, он не синхронизируется с резервным:

sudo service bind9 start

Я также пытался включить его с помощью:

sudo systemctl enable bind9

Опять же, основной и резервный серверы не синхронизируются. Я копался в этом, и кто-то предложил запустить named в переднем плане, чтобы посмотреть, что выводят логи. Как ни странно, когда я выполняю service bind9 stop, а затем запускаю named -fg на основном и резервном серверах, они внезапно начинают синхронизироваться и передавать необходимую информацию о зонах.

Почему они переносятся, когда я явно запускаю named, но не когда я запускаю bind9 как сервис? Я думал, что named и bind являются просто псевдонимами друг для друга, так что я не уверен, что понимаю разницу между тем, что происходит в одном случае по сравнению с другим.

Редактировать:

Использую Raspberry Pi: Raspbian Lite Вывод статуса systemctl bind9 выглядит следующим образом:

> shutting down: flushing changes stopping command channel on
> 127.0.0.1#953 dumping master file: /etc/bind/tmp-ew7u3atsWd: open: permission denied dumping master file: /etc/bind/tmp-CAP7c5Elmn: open:
> permission denied no longer listening on 127.0.0.1#53 no longer
> listening on 192.168.0.105#53 no longer listening on 10.1.10.29#53
> exiting bind9.service: Succeeded. Stopped BIND Domain Name Server.

Второе редактирование

Я не думал, что это было связано с разрешениями, потому что я установил владение группой и пользователем bind:bind для всего, кроме rndc.key, но оказалось, что это так.

После того как меня указали на возможные проблемы с разрешениями, я сделал следующее:

  • chown bind:bind /etc/bind/named.conf
  • chown root:root /etc/bind/rndc.key
  • chmod 755 rndc.key
  • chown bind:bind /var/cache/bind/
  • chmod g+w /var/cache/bind/
  • chmod g+w /etc/bind/

С тех пор кажется, что он теперь правильно обновляется.

Я не думал, что это было связано с разрешениями, потому что я установил владение группой и пользователем bind:bind для всего, кроме rndc.key, но оказалось, что это так.

После того как меня указали на возможные проблемы с разрешениями, я сделал следующее:

  • chown bind:bind /etc/bind/named.conf
  • chown root:root /etc/bind/rndc.key
  • chmod 755 rndc.key
  • chown bind:bind /var/cache/bind/
  • chmod g+w /var/cache/bind/
  • chmod g+w /etc/bind/

С тех пор кажется, что он теперь правильно обновляется.

Похоже, вы разместили свой основной файл в /etc/bind/, тогда как его следует разместить в /var/lib/bind/.
Сервис bind не имеет разрешения на запись в /etc/bind/, в то время как процесс bind должен записывать бинарную версию вашего файла зоны (jnl файл) в ту же папку.
Поэтому переместите ваш основной файл зоны в /var/lib/bind/ и обновите файл, который вы поместили в named.conf.local

Ответ или решение

Рассмотрим проблемы с Bind9 и почему запуск через named -fg решает ваши проблемы, в отличие от запуска Bind9 как службы. Основной причиной вашему сценарию является проблема с правами доступа и размещением файлов конфигурации и журналов зоны.

Проблема прав доступа

Когда вы запускаете named напрямую, вы, вероятно, запускаете его с теми же привилегиями, которые позволяют ему успешно читать и писать файлы зон. Между тем, запуск через service bind9 start или systemctl может использовать другой контекст безопасности или более ограниченные права доступа. Это может проявляться в ошибках доступа, таких как:

dumping master file: /etc/bind/tmp-ew7u3atsWd: open: permission denied

Так как служба Bind9 запускается с определенными правами, важно, чтобы все используемые файлы и каталоги имели корректные права доступа. Как вы отметили, вы решили проблему, изменив права на:

  • /etc/bind/named.conf
  • /var/cache/bind/

Таким образом, вы позволили пользователю bind получить необходимые разрешения для записи изменений и работы с временными файлами.

Рекомендуемое решение

  1. Проверка прав доступа: Убедитесь, что пользователь, под которым запускается служба (обычно bind), имеет надлежащие права на каталоги и файлы, такие как /etc/bind/, /var/cache/bind/, и соответствующие файлы зон.

  2. Размещение файлов зон: Переместите файлы зон из /etc/bind/ в /var/lib/bind/, так как последний каталог по умолчанию предназначен для временных файлов и обеспечивает возможность записи для службы.

  3. Обновление конфигурации: После перемещения рекомендуется обновить пути к файлам зон в named.conf.local, чтобы они указывали на новые расположения в /var/lib/bind/.

Заключение

Исходя из вышеизложенного, проблемы начинались с недостаточных прав доступа, которые смогли бы блокировать запись и синхронизацию зон DNS при запуске через системные службы. Отладка с использованием foreground-запуска помогла выявить эти проблемы. Исправление прав доступа и расположение файлов зон может улучшить работу и обеспечить надлежащий запуск службы bind9.

Оставайтесь внимательными к правам пользователя bind и расположению файлов, и это поможет минимизировать возможные риски в будущем. Это не только повысит надежность работы DNS-сервера, но и предотвратит возможные административные простои.

Оцените материал
Добавить комментарий

Капча загружается...