Вопрос или проблема
У меня очень странная ситуация, которую я не до конца понимаю. У меня есть основной и резервный 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
получить необходимые разрешения для записи изменений и работы с временными файлами.
Рекомендуемое решение
-
Проверка прав доступа: Убедитесь, что пользователь, под которым запускается служба (обычно
bind
), имеет надлежащие права на каталоги и файлы, такие как/etc/bind/
,/var/cache/bind/
, и соответствующие файлы зон. -
Размещение файлов зон: Переместите файлы зон из
/etc/bind/
в/var/lib/bind/
, так как последний каталог по умолчанию предназначен для временных файлов и обеспечивает возможность записи для службы. -
Обновление конфигурации: После перемещения рекомендуется обновить пути к файлам зон в
named.conf.local
, чтобы они указывали на новые расположения в/var/lib/bind/
.
Заключение
Исходя из вышеизложенного, проблемы начинались с недостаточных прав доступа, которые смогли бы блокировать запись и синхронизацию зон DNS при запуске через системные службы. Отладка с использованием foreground-запуска помогла выявить эти проблемы. Исправление прав доступа и расположение файлов зон может улучшить работу и обеспечить надлежащий запуск службы bind9.
Оставайтесь внимательными к правам пользователя bind
и расположению файлов, и это поможет минимизировать возможные риски в будущем. Это не только повысит надежность работы DNS-сервера, но и предотвратит возможные административные простои.