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

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

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

Итак, 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 с разделенным туннелем.

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

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

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

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

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

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

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

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

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

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