У нас есть основной домен нашей организации (с AD) example.com. В прошлом предыдущие администраторы создали несколько других зон, таких как dmn.com, lab.example.com, dmn-geo.com и т. Д., А также поддомены и делегаты, каждая из которых предназначена для разных инженерных групп. Наш DNS сейчас немного запутался. И, конечно же, это вызывает проблемы, когда кому-то на рабочей станции в example.com необходимо подключиться к системе в любой из этих других зон / поддоменов или наоборот (частично потому, что для большинства из них передача и делегирование зон не настроены должным образом) .
Наш производственный DNS интегрирован с Active Directory, но инженерные системы должны быть изолированы от AD.
Мы обсуждаем способы реорганизации DNS и объединения всех этих различных записей. Я вижу три пути, которыми мы можем воспользоваться:
Я предпочитаю создать поддомен делегата и дать инженерам полный контроль над своей собственной структурой DNS внутри этого поддомена. Преимущество в том, что если их DNS не работает, скорее всего, это не моя вина;). Однако по-прежнему существует некоторая двусмысленность в отношении ответственности, когда что-то не работает, и для установки, настройки и администрирования потребуется согласование с инженерными работниками.
Если мы не делегируем поддомен, это означает, что производственным ИТ-специалистам потребуется гораздо больше работы, связанной с непроизводственным DNS (что мы, по сути, уже много сделали). Преимущество состоит в том, что у нас есть полный контроль над всеми DNS, и когда что-то не работает, нет сомнений в том, кто несет ответственность за это. Мы также можем добавить делегатов, таких как geo.eng.example.com, чтобы дать инженерам больше гибкости и контроля, когда они в этом нуждаются.
Я действительно не уверен в необходимости или преимуществах создания новой зоны, dmn.eng.
Итак, каковы отраслевые передовые практики и рекомендации для подобных ситуаций? Какое решение было бы проще всего реализовать и обеспечить бесшовное разрешение имен между разработкой и производством? Каковы некоторые потенциальные преимущества или недостатки каждого решения, которого мне может не хватать?
Чтобы добавить немного дополнительной информации, мы - довольно крупная производственная компания. Эти инженеры работают в отделах НИОКР, разработки и контроля качества. Лаборатории часто имеют свои собственные подсети или целые сети, DHCP и т. Д. Что касается организации и технологий, они представляют собой своего рода свой маленький мир.
Мы хотим поддерживать определенный уровень сетевой изоляции для инженерных лабораторий и сетей, чтобы защитить нашу производственную среду (ссылка предыдущий вопрос относительно инженеров, которые добавили инженерные DHCP-серверы в качестве авторитетных DHCP-серверов AD - этого не должно быть). Однако пользователю на рабочей станции в лаборатории потребуется доступ к ресурсу в нашей производственной сети, или пользователю на рабочей станции в нашей производственной сети потребуется подключиться к лабораторной системе, и это происходит с достаточной частотой, чтобы оправдать сортировку. - единого DNS.
У существующих делегатов уже есть DNS-серверы, управляемые инженерно-техническими специалистами, но нет связи между инженерами в разных лабораториях, где эти серверы установлены, поэтому наиболее распространенной проблемой является неудачное разрешение имен между поддоменами. Поскольку эти делегированные серверы принадлежат инженерам, я не могу исправить записи NS, чтобы они разговаривали друг с другом - отсюда и преимущество неделегированного DNS, полностью принадлежащего ИТ. Но управление DNS для производства и проектирование - это головная боль, особенно потому, что инженеры могут вносить изменения в DNS ежедневно. Но, как сказал BigHomie в своем ответе, это, вероятно, означает, что инженерам придется нанять (или назначить) настоящего администратора DNS; и нам с этим человеком придется достаточно хорошо познакомиться.
Мне не обязательно нравится идея создания новой зоны с произвольным доменным именем верхнего уровня или суффиксом, но у нас уже есть 5 других зон с произвольными именами, поэтому объединение в одну все еще является улучшением. Я знаю, что существуют другие компании, которые имеют отдельные зоны верхнего уровня для разных групп в своей организации, поэтому мне любопытно, когда это уместно и каковы преимущества / недостатки этого подхода.
К вашему сведению, я работаю в этой компании всего несколько месяцев, а предыдущий администратор AD / DNS покинул компанию, поэтому мне не на что ссылаться на то, почему существует какая-либо существующая структура DNS.
Прежде всего, убедитесь, что вы своя домен .tld, который вы планируете использовать (mit.edu). Даже если он никогда не подключается к Интернету, дело не в этом.
Есть огромные преимущества в иерархии DNS, которая хотя бы в некотором роде соответствует орг. Я видел это только тогда, когда есть кто-то / люди, которые управляют этим отделом с точки зрения ИТ-поддержки. Это касается наличия отдельных зон для целей AD. Веб-адреса и т. Д. - отдельная тема, и к этому это не относится. У меня нет и нет никаких жестких правил для иерархии DNS, я считаю, что потребности вашей организации будут диктовать это. Для некоторых зон может потребоваться субдомен (eng.mit.edu), а для некоторых - нет (например, hr.mit.edu). Конечно, должно быть только один домен верхнего уровня для согласованности.
При этом, что определяет, нужен ли отдел субдомен или нет? Если это для рабочих станций, есть ли у них собственная ИТ-поддержка или люди, способные управлять такой системой? Если нет, на самом деле нет смысла использовать зону DNS, чтобы указать, что машина находится в определенном отделе, есть множество других методов, которые отлично справятся с этой задачей. Это просто вопросы, которые вам просто нужно задать себе.
Я бы переоценил каждую зону и определил
Если это еще актуально. Есть ли серверы или рабочие станции, все еще указывающие на что-нибудь в этой зоне?
Кто будет управлять новой зоной. Само собой разумеется, что зона должна быть перенесена в вашу новую иерархию, но вы просто реализуете адрес пересылки / информацию о сервере имен для зоны, или вы активно управляя зона?
какой системы "изолированы" от AD? Не потребуется ли для этого сетевая аутентификация и / или управление? В чем причина разделения их с точки зрения DNS? Чтобы подтвердить свои подозрения, все дело в простоте управления. Если инженерные нужды который много администрирования DNS, они должны получить себе администратора DNS.
Чтобы добавить информацию на основе вашего обновления, я лично предоставил бы им их собственный поддомен, eng.spacelysprockets.com, а также подсеть. Он должен быть изолирован от остальной сети с соответствующим пропускным трафиком. Если они хотят уйти и создать eng.eng.local или eng.bikes вы не можете их остановить, и вас не следует заставлять их поддерживать *.
Если они хорошо играют, используйте подзону и решите, что они хотят прерваться. lab.eng.spacelysprockets.com и часть подсети, которая находится на них. Вероятно, это должно быть профессиональной любезностью, чтобы сообщить вам, чтобы вы также могли сегментировать этот трафик, но все так не думают.
Настоящее доменное имя для вашей инфраструктуры серьезно даст вам преимущество при управлении, вы должны это учитывать.
* Если вы и воля вы разные вещи, но я отвлекся.
В современном мире, Не рекомендую создавать новые зоны с произвольными доменами верхнего уровня, так как они могут попасть в "официальный DNS" в любой момент.
Я лично предпочел бы сценарий делегирования поддомена, поскольку он кажется подходящим для того, что вы пытаетесь сделать. (Консолидируйте, но дайте контроль инженерам)
Возможно, вы даже сможете найти веб-интерфейс для MS DNS, где инженеры могли бы добавлять / удалять записи, так что сам сервер по-прежнему принадлежит производственной ИТ-службе, а единственное, чем «они» управляют, - это записи DNS.