Назад | Перейти на главную страницу

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

В нашей организации есть две отдельные группы, которые разделяют сетевое адресное пространство и домен. Пара сегментов / 24 выделена моей группе, а остальное - нашей внутренней ИТ-команде.

Мы не хотим иметь возможность управлять DNS для их части пирога, но нам нужно иметь возможность управлять им для нашей части.

Проблема в том, что по политическим / историческим причинам, которые предшествовали моему пребыванию в должности, мы установили DNS-сервер на базе Linux, вели собственные записи и направили все наши серверы и оборудование на этот сервер. Тем временем пользователи и разработчики в организации обращаются к DNS-серверу ИТ-специалистов.

Чтобы убедиться, что все работает во всех ситуациях, мы должны ввести записи DNS на нашем сервере, а затем отправить заявки нашей ИТ-группе на создание записей в среде Active Directory. Это произошло из-за паритета и стало кошмаром для менеджмента.

Кроме того, у нас есть сотни серверов и приложений, которые используют общие domain.com и создание subdomain.domain.com а обновлять сотни серверов и приложений не желательно.

Таким образом, есть ли способ предоставить доверие и разрешение на обновление записей в domain.com всего за несколько / 24сек внутри / 16? Сторонние решения, которые подключаются к Active Directory, приемлемы.

Вы наверняка уже заметили, что DNS не заботится о подсетях, когда дело касается управления. Типичная единица управления в инфраструктуре DNS - это «зона», которая соответствует по крайней мере одному домену. Поэтому, если вы хотите делегировать задачи управления, вы должны делегировать администрирование всей зоне, по крайней мере, всему домену.

DNS-серверы Windows AD предлагают некоторые дополнительные возможности управления доступом и делегирования для отдельных записей, то есть вы сможете настроить права «изменять» для данного пользователя или группы для каждой отдельной записи в зоне без делегирования всего управления зоной. Но ни одна из функций делегирования и ACL не включает что-то вроде «подсети» в качестве единицы управления, если вам нужно отразить это в ACE, вам нужно будет исправить их извне.

При этом, вероятно, это не так плохо, как кажется, поскольку списки управления доступом Windows DNS также имеют концепцию «создателя» записи вместе с возможностью делегировать только создание новых записей в зоне без необходимости получения разрешений на изменить другие данные, относящиеся к зоне, или другие записи. «Создатель» становится владельцем записи и неявно получает право изменять свои разрешения, таким образом косвенно он получает «полный контроль». Кроме того, ACE для «CREATOR-OWNER», который должен быть унаследован при создании новой записи, при желании может быть явно определен в контейнере (но неявное право на изменение разрешений не может быть отозвано). Итак, основная схема проекта может выглядеть так:

  • попросите команду AD DNS предоставить права на создание новых записей в зоне для вашей группы
  • попросите команду AD DNS делегировать права на изменение для записей ресурсов, принадлежащих вашей группе
  • начать создавать и изменять записи ресурсов для своей группы в AD DNS самостоятельно
  • предложить создание часто выполняемого сценария управления, который будет проверять, что записи, созданные вашей группой, соответствуют политике делегирования (т.е. указывают на хосты в ваших доменах)
  • перенастройте свой DNS-сервер Linux, чтобы он либо просто перенаправлял запросы на DNS-серверы AD, либо действовал в качестве вторичного, извлекая данные зоны из одного из первичных серверов AD DNS (если зона DNS интегрирована в AD, все серверы AD DNS будут действовать как праймериз)

Возможно, я неправильно это читаю, но похоже, что запланированное задание, запускаемое один или два раза в день, подойдет.

  • Читать в записях DNS
  • Если IP-адрес записи соответствует критериям
  • проверить ACL безопасности для ACE группы безопасности, которая управляет адресом
  • Добавьте ACE, если он не существует.

Вот один пример кода доступа к зоне и выполнения обновлений:

http://www.adamtheautomator.com/fix-dynamic-dns-record-permissions-automagically/

Этот код предназначен для исправления потерянных динамических записей DNS, но он должен указать вам правильное направление.

Я не могу говорить о том, как будет настроена 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.
  • Поскольку контроллер домена обычно выступает в роли смешанного DNS-сервера (как рекурсивного, так и авторитетного), запросы на www и ftp вызовет рекурсию и вызовет ns1.example.com нужно проконсультироваться для ответа. Это будет успешным при условии, что есть брандмауэр, разрешающий трафик от контроллеров домена. ns1.

Это по-прежнему проблема: вы не избавляетесь от необходимости определять записи на удаленном сервере. Что ты являются выполнение - это владение отдельными записями. Если IP-адрес одной из этих записей нужно изменить, это изменение не нужно делать по обе стороны забора. Это будет работать, по крайней мере, пока кто-то не захочет определить sub.ftp.example.com на ДЦ. поскольку ftp был делегирован, sub.ftp также был делегирован, и нет возможности управлять им локально.