У меня есть пул авторитетных DNS-серверов, на которых должны размещаться зоны для 5 пользователей, каждый из которых имеет от 2 до 10 зон.
Каждый пользователь может подключаться к серверам по ssh, используя аутентификацию с открытым ключом. Требования, с которыми я сталкиваюсь, говорят, что пока пользователь может подключиться к ssh-порту на сервере, он также должен иметь возможность обновлять свои собственные зоны, не полагаясь на какие-либо другие сетевые соединения..
Что я сделал до сих пор, так это настроил каждую зону для загрузки из домашнего каталога пользователя, владеющего зоной, как в этом примере:
zone "example.com" {
type master;
file "/home/example/zones/example.com";
};
Я не знаю, существуют ли какие-либо рекомендации по загрузке файлов зоны непосредственно из домашнего каталога пользователя. Я попробовал выполнить несколько поисков и не нашел никаких рекомендаций за или против этой практики.
Кажется, это работает, но изменения вступают в силу только после того, как я перезапущу или перезагружаю привязку, что в настоящее время я должен делать как root.
Дистрибутив, который я использую, содержит BIND 9.8 с исправлениями безопасности. Поэтому я загрузил «Справочное руководство администратора BIND 9» версии 9.8, чтобы найти способы, которыми пользователь может дать команду привязке для перезагрузки зоны.
Я нашел rndc
, однако кажется, что элементы управления доступом в BIND недостаточно детализированы, чтобы можно было использовать секрет только для перезагрузки определенных зон. Я могу указать комбинации IP-адресов и разрешенный доступ к секретам HMAC-MD5, но любой такой комбинации разрешенный доступ будет разрешен для вызова всех команд через rndc
.
Как разрешить пользователю перезагружать файлы зоны, не предоставляя им других прав администратора?
На данный момент я думаю, что могу использовать либо sudo
или command
вариант в .ssh/authorized_keys
чтобы предоставить пользователю доступ для вызова определенного rndc
команда.
Это рекомендуемый подход или мне следует заняться чем-то еще?
Я также рассмотрел возможность использования зональных трансферов. Но мое понимание того, как работает передача зоны, заключается в том, что принимающий DNS-сервер действует как клиент при зональной передаче, а отправляющий DNS-сервер действует как сервер. Если я правильно понимаю, это означает, что клиент не может предоставить серверу новую версию зоны. Так что, похоже, если бы я выбрал этот подход, мне пришлось бы использовать скрытую главную настройку с этим скрытым мастером, работающим на VPN-клиенте, что по причинам, которые я не могу полностью сформулировать, кажется неправильным.
я бы сделал это через sudo
user1 ALL=(root) /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2 ALL=(root) /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
Вы можете попросить своих клиентов использовать инструмент rcs, такой как git, для обновления своих файлов зон и отправки их на свои домашние компьютеры. Там создайте репозиторий git с обработчиком приема сообщений, который запускает эти команды с использованием правил sudo, указанных пользователем 1700494 (я бы также добавил named-checkzone и named-checkconf).
Для полноты изложения вот правила sudo, предложенные пользователем 1700494
user1 ALL=(root) /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2 ALL=(root) /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
Таким образом, вы сохраните все в системе контроля версий, чтобы вы могли легко вернуться в случае необходимости, и вашим пользователям не нужно входить в систему и изменять файлы на сервере, все можно делать в их собственной среде. Кроме того, вы перезагружаете сервер только после проверки правильности файлов.
Я бы посоветовал запускать каждый экземпляр привязки на LXC. У каждого пользователя есть собственный экземпляр Bind. Предоставьте им учетные данные их соответствующих экземпляров.