Должна ли инженерия иметь собственную DNS-зону, делегат или поддомен?

У нас есть основной домен нашей организации (с AD) example.com. В прошлом предыдущие администраторы создавали несколько других зон, таких как dmn.com, lab.example.com, dmn-geo.com и т. Д., А также субдомены и делегаты, все из которых предназначены для различных инженерных групп. Наш DNS сейчас немного беспорядок. И, конечно, это вызывает проблемы, когда кому-то на рабочей станции в example.com необходимо подключиться к системе в любой из этих других зон / поддоменов, или наоборот (частично потому, что передача зоны и делегирование неправильно настроены для большинства из них) ,

Наш производственный DNS интегрирован с Active Directory, но инженерные системы должны быть изолированы от AD.

Мы обсуждаем способы реорганизации DNS и объединения всех этих разных записей. Я вижу три различных пути, по которым мы можем пойти:

• Создайте новую зону, т.е. dmn.eng. Это может либо управляться ИТ-отделом с использованием наших DNS-серверов, либо с помощью их серверов имен.
• Создайте новый делегат eng.example.com, объедините инженерный DNS в этот поддомен и позвольте инженерам управлять сервером имен для делегата.
• Создайте новый поддомен eng.example.com без делегирования и сами управляйте DNS для этого поддомена.

Я предпочитаю создание поддомена делегата и предоставление инженерам полного контроля над собственной структурой DNS в этом поддомене. Преимущество в том, что если их DNS не работает, то, скорее всего, это не моя вина;). Тем не менее, существует некоторая неопределенность в отношении ответственности, когда что-то не работает, и для настройки, настройки и администрирования потребуется координация с инжинирингом.

Если мы не делегируем поддомен, это означает, что для производственных ИТ-отделов будет непросто работать с непроизводственными DNS (что мы, по сути, уже проделали). Преимущество заключается в том, что мы имеем полный контроль над всеми DNS, и когда что-то не работает, нет сомнений в том, чья ответственность это исправить. Мы также можем добавить делегатов, таких как geo.eng.example.com, чтобы предоставить инженерам больше гибкости и контроля, когда им это нужно.

Я действительно не уверен в необходимости или преимуществах создания новой зоны, dmn.eng.

Итак, каковы лучшие отраслевые практики и рекомендации для подобных ситуаций? Какое решение было бы проще всего реализовать и обеспечить плавное разрешение имен между проектированием и производством? Каковы некоторые потенциальные выгоды или недостатки каждого решения, которое я могу упустить?

Чтобы добавить немного больше информации, мы довольно крупная производственная компания. Эти инженеры работают в области R & D, Development и QA. Лаборатории часто имеют свои собственные подсети или целые сети, DHCP и т. Д. Что касается организации и технологий, они являются своего рода маленьким миром.

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

У существующих делегатов уже есть DNS-серверы, управляемые инжинирингом, но между инженерами в разных лабораториях, где установлены эти серверы, отсутствует связь, поэтому наиболее распространенной проблемой является неудачное разрешение имен между поддоменами. Поскольку инженерам принадлежат эти серверы делегатов, я не могу исправить записи NS, чтобы они общались друг с другом - отсюда и преимущество не делегированного DNS, полностью принадлежащего ИТ. Но управление DNS для производства и проектирования - это головная боль, тем более что инженерия может вносить изменения в DNS ежедневно. Но, как BigHomie упомянул в своем ответе, это, вероятно, означает, что инженерам придется нанять (или назначить) настоящего администратора DNS; и этот человек, и я должен стать довольно хорошо знакомым.

Мне не обязательно нравится идея создания новой зоны с произвольным доменным именем или суффиксом верхнего уровня, но у нас уже есть 5 других зон с произвольными именами, поэтому объединение в одну все еще является улучшением. Я знаю, что существуют другие компании, которые имеют отдельные зоны верхнего уровня для разных групп в своей организации, поэтому мне интересно, когда это уместно и каковы преимущества / недостатки этого подхода.

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

В современном мире я не рекомендую создавать новые зоны с произвольными доменами верхнего уровня , поскольку они могут в любой момент превратиться в «официальный днс».

Я лично предпочел бы сценарий делегирования поддоменов, поскольку он, кажется, соответствует тому, что вы пытаетесь сделать. (Консолидация, но контроль над разработкой)

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

Прежде всего, убедитесь, что у вас есть домен domain.tld, который вы планируете использовать (mit.edu). Даже если это никогда не подключится к Интернету, это не главное.

Есть огромная выгода от наличия иерархии DNS, которая хотя бы в некоторой степени соответствует организации. Я видел это только тогда, когда есть кто-то / люди, которые управляют этим отделом с точки зрения ИТ-поддержки. Это касается наличия отдельных зон для целей нашей эры. Веб-адреса и т. Д. Являются отдельной темой, и это не относится к этому. Я не знаю или не знаю жестких и быстрых правил для иерархии DNS, я полагаю, что потребности вашей организации будут диктовать это. В некоторых зонах может потребоваться поддомен (eng.mit.edu), а в некоторых - нет (например, hr.mit.edu). Конечно, для согласованности должен быть только один домен верхнего уровня.

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

Я бы переоценил каждую зону и определил

1. Если это все еще даже актуально. Есть ли еще серверы или рабочие станции, указывающие на что-либо в этой зоне?

2. Кто будет управлять новой зоной. Само собой разумеется, что зону нужно будет перенести в новую иерархию, но вы просто внедрили информацию о адресе / сервере имен переадресации для зоны или будете активно управлять зоной?

Какие системы «изолированы» от AD? Не потребует ли это сетевой аутентификации и / или управления? В чем причина их разделения с точки зрения DNS? Чтобы подтвердить ваши подозрения, это все о простоте управления. Если инженерные потребности , что много администрации Dns, они должны получить себе DNS администратор.

Чтобы добавить информацию, основанную на вашем обновлении, я бы лично предоставил им свой собственный поддомен eng.spacelysprockets.com, а также подсеть. Это должно быть защищено от остальной части сети с соответствующим пропущенным трафиком. Если они хотят уйти и творить, eng.eng.localили eng.bikesвы не можете их остановить, и вы не должны быть вынуждены поддерживать это *.

Если они играют хорошо, используйте подзону и решите, что они хотят разорвать lab.eng.spacelysprockets.comи часть подсети, это на них. Вероятно, следует проявить профессиональную вежливость, чтобы вы знали, чтобы вы также могли сегментировать этот трафик, но все так не думают.

Реальное доменное имя для вашей инфраструктуры серьезно даст вам преимущество в управлении, вы должны это учитывать.

* Если вы и будете вы это две разные вещи, но я отвлекся.