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

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

С надеждой, мы все знают что за рекомендации по именованию леса Active Directory:, и они довольно простые. А именно, это можно выразить одним предложением.

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

Есть очень веские причины избегать использования "поддельные" TLD или однокомпонентные доменные имена, но мне трудно найти столь же веские причины избегать использования корневого домена (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. Если вы когда-нибудь развернете Прямой доступ, это значительно упрощает ваши политики разрешения имен - это, вероятно, также верно и для других технологий VPN с раздельным туннелем.

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

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

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

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

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

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

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

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

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

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