Windows DNS: есть ли способ разделить домен на основе подсетей

Windows DNS: есть ли способ разделить домен на основе подсетей

В нашей организации есть две отдельные группы, которые совместно используют сетевое адресное пространство и домен. Несколько фрагментов /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также было делегировано, и нет способа управлять им локально.

Связанный контент