В нашей организации есть две отдельные группы, которые совместно используют сетевое адресное пространство и домен. Несколько фрагментов /24 выделены для моей группы, а остальное выделено для нашей внутренней ИТ-команды.
Мы не хотим иметь возможность управлять DNS для их куска пирога, но нам нужно иметь возможность управлять им для нашего куска.
Проблема в том, что по политическим/историческим причинам, которые предшествовали моему сроку, мы настроили DNS-сервер на базе Linux и вели собственные записи, а также направили все наши серверы и оборудование на этот сервер. Между тем пользователи и разработчики по всей организации направляются на DNS-сервер ИТ-команд.
Чтобы убедиться, что все работает во всех ситуациях, нам нужно ввести записи DNS на нашем сервере, а затем отправить тикеты нашей ИТ-команде, чтобы создать записи в среде Active Directory. Это вышло из-под контроля и стало кошмаром для управления.
Кроме того, у нас есть сотни серверов и приложений, которые используют общий ресурс domain.com
, и необходимость создавать subdomain.domain.com
и обновлять сотни серверов и приложений нежелательна.
Таким образом, есть ли способ предоставить доверие и разрешение на обновление записей domain.com
только для нескольких /24 внутри /16? Приемлемы сторонние решения, которые прикрепляются к Active Directory.
решение1
Возможно, я неправильно понял, но мне кажется, что запланированное задание, запускаемое один или два раза в день, подойдет.
- Прочитать записи DNS
- Если IP-адрес записи соответствует критериям
- проверьте список контроля доступа безопасности на предмет ACE группы безопасности, которая управляет адресом
- Добавьте ACE, если его нет.
Вот пример кода, как получить доступ к зоне и выполнить обновления:
http://www.adamtheautomator.com/fix-dynamic-dns-record-permissions-automagically/
Этот код предназначен для исправления потерянных динамических записей DNS, но он должен указать вам правильное направление.
решение2
Вы наверняка уже заметили, что DNS не заботится о подсетях, когда дело доходит до управления. Типичная единица управления в инфраструктуре DNS — это «зона», которая будет соответствовать как минимум одному домену. Поэтому, если вы хотите делегировать задачи управления, вы делегируете администрирование полной зоны, то есть как минимум всего домена.
Windows AD DNS-серверы предлагают некоторые дополнительные возможности управления доступом и делегирования для записей отдельных записей - т. е. вы сможете установить права "изменить" для определенного пользователя или группы для каждой отдельной записи в зоне без делегирования всего управления зоной. Но ни одна из функций делегирования и ACL не включает что-то вроде "подсети" в качестве единицы управления, если вам нужно отразить это в ACE, вам нужно будет исправить их извне.
При этом, вероятно, это не так плохо, как кажется, поскольку в списках управления доступом Windows DNS также есть концепция «создателя» записи, а также возможность делегировать только создание новых записей в зоне без необходимости в разрешениях на изменение других данных, специфичных для зоны, или других записей. «Создатель» становится владельцем записи и неявно получает право изменять свои разрешения, таким образом, он косвенно получает «полный контроль». Кроме того, ACE для «СОЗДАТЕЛЯ-ВЛАДЕЛЬЦА», который будет унаследован при создании новой записи, может быть явно определен в контейнере, если это необходимо (но неявное право изменять разрешения не может быть отозвано). Таким образом, базовая схема проекта может выглядеть следующим образом:
- запросите у команды AD DNS права на создание новых записей в зоне для вашей группы
- попросите группу AD DNS делегировать права на изменение записей ресурсов, принадлежащих вашей группе
- начните самостоятельно создавать и изменять записи ресурсов для своей группы в AD DNS
- предложить создать часто запускаемый скрипт управления, который будет проверять, что записи, созданные вашей группой, соответствуют политике делегирования (т.е. указывают на хосты в ваших доменах)
- перенастройте свой DNS-сервер Linux так, чтобы он либо просто пересылал запросы на DNS-серверы AD, либо действовал как вторичный, извлекая данные зоны из одного из основных DNS-серверов AD (если DNS-зона интегрирована с AD, все DNS-серверы AD будут действовать как основные)
решение3
Я не могу сказать, как можно настроить Active Directory, чтобы вы могли удаленно управлять доменом и автоматизировать его с помощью nsupdate
.
Что яможетмогу сказать, что вы можете несколько уменьшить головную боль, делегируя NS
друг другу полномочия по отдельным записям и никогда не определяя статические данные A
или CNAME
записи для данных, которыми ваша команда не управляет.
Представьте, что в Active Directory у вас есть следующее:
example.com. SOA dc1.example.com. hostmaster.example.com. 2015022400 28800 7200 604800 300
IN NS dc1.example.com.
IN NS dc2.example.com.
IN MX 10 mail.example.com.
www IN NS ns1
ftp IN NS ns1
mail IN A 198.18.0.10
dc1 IN A 198.18.0.150
ns1 IN A 198.18.0.250
mail
,ns1
, иdc1
являются статически определенными записями.www
иftp
были делегированыns1.example.com.
, который мы скажем как авторитетный DNS-сервер Linux.- Поскольку DC обычно действует в смешанной роли DNS-сервера (как рекурсивного, так и авторитетного), запросы на
www
иftp
вызовут рекурсию и вызовутns1.example.com
обращение за ответом. Это будет успешно выполнено, при условии, что есть брандмауэр, позволяющий трафику от DC достигатьns1
.
Это все еще больно: вы не избегаете необходимости определять записи на удаленном сервере. Что выявляютсядостижение — это владение отдельными записями. Если IP-адрес для одной из этих записей необходимо изменить, это изменение не обязательно должно быть сделано с обеих сторон забора. Это будет работать, по крайней мере, пока кто-то не захочет определить sub.ftp.example.com
на DC. Поскольку ftp
было делегировано, sub.ftp
также было делегировано, и нет способа управлять им локально.