Присвоение имени новому лесу Active Directory - почему DNS с разделенным горизонтом не рекомендуется?

23

Надеемся , мы все знаем, каковы рекомендации по именованию леса Active Directory , и они довольно просты. А именно, его можно суммировать в одном предложении.

Используйте поддомен существующего зарегистрированного доменного имени и выберите тот, который не будет использоваться внешне. Например, если я должен был включить и зарегистрировать hopelessn00b.comдомен, мой внутренний лес AD должен иметь имя internal.hopelessn00b.comили ad.hopelessn00b.comили corp.hopelessn00b.com.

Существуют чрезвычайно убедительные причины, по которым следует избегать использования «поддельных» tlds или доменных имен с одной меткой , но мне трудно найти аналогичные убедительные причины, чтобы не использовать корневой домен ( hopelessn00b.com) в качестве имени моего домена и использовать поддомен, например corp.hopelessn00b.comвместо , На самом деле, единственное оправдание, которое я могу найти, заключается в том, что для доступа к внешнему веб-сайту из внутреннего источника требуется A nameзапись DNS и ввод www.имени браузера в браузере перед именем веб-сайта, что довольно «ме», если говорить о проблемах.

Итак, что мне не хватает? Почему гораздо лучше использовать имя ad.hopelessn00b.comмоего леса Active Directory поверх hopelessn00b.com?

Просто для справки, это действительно мой работодатель, который нуждается в убеждении - босс тянет деньги назад, и после того, как я дал разрешение на создание нового леса AD, названного corp.hopelessn00b'semployer.comдля нашей внутренней сети, он хочет придерживаться леса AD с именем hopelessn00b'semployer.com( так же, как наш внешне зарегистрированный домен). Я надеюсь, что смогу найти убедительную причину или причины, по которым лучшая практика - лучший вариант, поэтому я могу убедить его в этом ... потому что это кажется проще, чем бросить ярость и / или найти новую работу, по крайней мере, для момент Прямо сейчас, «лучшие практики Microsoft» и внутренний доступ к общедоступному веб-сайту для нашей компании, похоже, не сокращают его, и я действительно , действительно , очень надеюсь, что кто-то здесь найдет что-то более убедительное.

HopelessN00b
источник
1
Незначительная коррекция - для этого потребуется внутренняя запись A, а не запись SRV для www.
MDMarra
@ HopelessN00b - Марк на месте со всем, что я бы сказал, и даже больше. Его «партнерский» сценарий - обледенение на торте. У меня не было «удовольствия» столкнуться с этим сценарием с разделенным горизонтом DNS. Я бы только что упомянул о разрешении имен в VPN-отстой, но я не думал о DirectAccess, в частности.) Если я что-нибудь придумаю, я его выброшу. Я просто в ужасе от рутинной работы и потенциальных ошибок, которые она создает. Одной этой причины достаточно, чтобы оправдать не делать этого. Больше всего меня все еще раздражают люди, которые говорят, что «крупные компании делают это, так что все в порядке» в качестве оправдания.
Эван Андерсон

Ответы:

24

Так много повторений будет. Приди ко мне, дорогой.

Итак, Microsoft довольно хорошо задокументировала, что вы не должны использовать split-horizon или выдуманный TLD, на который вы ссылались много раз (кричите в мой блог!). Есть несколько причин для этого.

  1. wwwПроблема , которую вы указали выше. Раздражает, но не прерыватель сделки.

  2. Это заставляет вас поддерживать дубликаты записей для всех общедоступных серверов, которые также доступны внутри, а не только www. mail.hopelessnoob.comэто общий пример. В идеальном случае у вас будет отдельная сеть периметра для таких вещей, как mail.hopelessnoob.comили publicwebservice.hopelessnoob.com. В некоторых конфигурациях, как в ASA с интерфейсами внутренних и внешних , вам необходимо либо внутри, внутри NAT или сплит-горизонт DNS в любом случае , но и для крупных организаций с законной сети периметра , где ваши веб-облицовочный ресурсы не за шпилька границей NAT - это вызывает ненужную работу.

  3. Представьте себе этот сценарий - вы hopelessnoob.comвнутренне и внешне. У вас есть корпорация, с которой вы сотрудничаете, example.comи она делает то же самое - разделяет горизонт внутри своей AD и общедоступного пространства имен DNS. Теперь вы настраиваете VPN типа «сеть-сеть» и хотите, чтобы внутренняя аутентификация для доверия проходила через туннель, а доступ к их внешним общедоступным ресурсам выходил через Интернет. Это практически невозможно без невероятно сложной политики маршрутизации или хранения собственной копии их внутренней зоны DNS - теперь вы только что создали дополнительный набор записей DNS для обслуживания. Таким образом, вы должны иметь дело с заколкой в ​​конце иих конец, политика маршрутизации / NAT и всякие другие хитрости. (Я был фактически в этой ситуации с AD, который я унаследовал).

  4. Если вы когда-либо развернете DirectAccess , это значительно упростит ваши политики разрешения имен - это, вероятно, также верно и для других технологий VPN с разделенным туннелем.

Некоторые из них - крайние случаи, некоторые нет, но их все легко избежать. Если у вас есть возможность сделать это с самого начала, вы можете сделать это правильно, чтобы не столкнуться с одним из них в течение десятилетия.

MDMarra
источник
1
Awesomesauce. Я думаю, что 3 и 4 могут заключить сделку ... но я оставлю это открытым, чтобы узнать, есть ли у кого-нибудь еще что-нибудь. И, надеюсь, поощрять больше препятствий на вашем пути. Два ответа за этот ответ довольно слабые ... давай, люди. Нужно рыдать!
HopelessN00b
2
+1 - я люблю это Продолжай борьбу.
Эван Андерсон
8

Это утверждение: «Действительно, единственное оправдание, которое я могу найти, состоит в том, что для доступа к внешнему веб-сайту из внутреннего источника требуется запись DNS SRV и ввод www. Перед именем веб-сайта в браузере», не соответствует действительности.

Это означает, что вам нужно хранить копии всех ваших общедоступных записей на ваших DNS-серверах AD, что может вызвать проблемы, особенно если вы делаете это неправильно - пропустите некоторые и т. Д. Если кто-то захочет попасть на ftp.company. com, но вы забыли создать псевдоним во внутреннем DNS (или не смогли должным образом его автоматизировать), сотрудники компании вообще не могут попасть на общедоступный FTP-сайт.

Это довольно хорошо отражено в вопросе, с которым вы связались: передовые практики именования в Windows Active Directory?

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

mfinni
источник
Хорошая точка зрения. Конечно, у нас нет таких общедоступных сервисов, и мы производим наш веб-хостинг на стороне, так что ... не уверен, насколько это будет важно, но я могу добавить его в список. Спасибо.
HopelessN00b
1
Как я уже писал, то, как общедоступная интернет-идентификация вашей компании используется сегодня, может не совсем точно отражать, как она будет использоваться через 5 лет.
mfinni
Да, будущее доказательство ... еще один хороший. Хотел бы я дать тебе еще +1. :)
HopelessN00b
5

Меня не волнует мнение представителя, чтобы создать длинный ответ сегодня ... поэтому я буду коротким.

Раньше я разбирался в split-dns и реализовывал его несколько раз, пока Эван и Марк не убедили меня в этом. Честно говоря, это НЕ то, что это не может быть сделано ... это возможно, и некоторые могут быть просто в порядке (несмотря на накладные расходы и проделанную работу).

2 года назад для меня возникли две специфические вещи, которые НЕ использовались:

  1. Как вы указали в своем вопросе, вы просто не можете позволить внутренним пользователям получить доступ к вашему внешнему веб-сайту только через доменное имя. Не спрашивайте, почему это было так важно, но у нас были внутренние пользователи, которые бы разозлились, что ввод простого доменного имени в браузер wwwне приведет к открытию реального веб-сайта, так как запись домена соответствует домену AD и не является универсальным для получения wwwи не может быть внутри.
  2. Проблемы с Exchange - Exchange AutoDiscover может не получить сертификаты и выдаст сообщение об ошибке. Это может происходить как внутри, так и снаружи. Это стало еще более очевидным, когда мы начали использовать «Внешние лесные почтовые ящики» в нашей организации Exchange, и они не увидели тот же внутренний DNS, что и мы.

Надеюсь, это поможет.

Очиститель
источник
1
Хе-хе ... В конце концов @MDMarra и я заставлю тебя думать так же, как мы.
Эван Андерсон
2
Сопротивление бесполезно ... ваша AD будет ассимилирована в поддомен вашего основного домена!
Опека - Восстановите Монику
Кроме того, я обошел проблему WWW, установив IIS на все контроллеры домена и создав страницу перенаправления ASP на www. Это на самом деле работает довольно хорошо, несмотря на несколько легкомысленное использование IIS.
cscracker