Присвоение имени новому лесу 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" и внутренний доступ к общедоступному веб-сайту для нашей компании, кажется, не сокращают его, и я действительно, действительно, очень надеюсь, что у кого-то здесь есть что-то более убедительное.
3 ответа
Так много повторений будет. Приди ко мне, дорогой.
Итак, Microsoft довольно хорошо задокументировала, что вы не должны использовать split-horizon или выдуманный TLD, на который вы ссылались много раз (кричите в мой блог!). Есть несколько причин для этого.
wwwпроблема, которую вы указали выше. Раздражает, но не прерыватель сделки.Это заставляет вас поддерживать дубликаты записей для всех общедоступных серверов, которые также доступны внутри, а не только
www,mail.hopelessnoob.comэто общий пример. В идеальном случае у вас будет отдельная сеть периметра для таких вещей, какmail.hopelessnoob.comили жеpublicwebservice.hopelessnoob.com, В некоторых конфигурациях, таких как ASA с внутренним и внешним интерфейсами, вам в любом случае необходим либо внутренний NAT, либо DNS с разделенным горизонтом, но для более крупных организаций с легитимной сетью по периметру, где ваши веб-ресурсы не находятся за границей NAT - это вызывает ненужную работу.Представьте себе этот сценарий - Вы
hopelessnoob.comвнутренне и внешне. У вас есть корпорация, с которой вы сотрудничаете, называетсяexample.comи они делают то же самое - разделяют горизонт своими AD и общедоступным пространством имен DNS. Теперь вы настраиваете VPN типа "сеть-сеть" и хотите, чтобы внутренняя аутентификация для доверия проходила через туннель, а доступ к их внешним общедоступным ресурсам выходил через Интернет. Это практически невозможно без невероятно сложной политики маршрутизации или хранения собственной копии их внутренней зоны DNS - теперь вы только что создали дополнительный набор записей DNS для обслуживания. Таким образом, вам придется иметь дело с закреплением на вашем конце и на его конце, политикой маршрутизации / NAT и всеми другими хитростями. (Я был фактически в этой ситуации с AD, который я унаследовал).Если вы когда-либо развернете DirectAccess, это значительно упростит ваши политики разрешения имен - это, вероятно, также верно и для других технологий VPN с разделенным туннелем.
Некоторые из них - крайние случаи, некоторые нет, но их все легко избежать. Если у вас есть возможность сделать это с самого начала, вы можете сделать это правильно, чтобы не столкнуться с одним из них в течение десятилетия.
Это утверждение: "Действительно, единственное оправдание, которое я могу найти, состоит в том, что для доступа к внешнему веб-сайту из внутреннего источника требуется запись DNS SRV и ввод www. Перед именем веб-сайта в браузере", не соответствует действительности.
Это означает, что вам нужно хранить копии всех ваших общедоступных записей на ваших DNS-серверах AD, что может вызвать проблемы, особенно если вы делаете это неправильно - пропустите некоторые и т. Д. Если кто-то захочет попасть на ftp.company. com, но вы забыли создать псевдоним во внутреннем DNS (или не смогли должным образом его автоматизировать), сотрудники компании вообще не могут получить доступ к общедоступному FTP-сайту.
Это довольно хорошо отражено в вопросе, с которым вы связались: передовые практики именования в Windows Active Directory?
Если ведение нескольких копий DNS-зон является простой задачей для вас, чтобы решить правильно, навсегда, тогда, я полагаю, вы можете делать то, что вы хотите. Пока MS не изменит что-то, что сломает это. Вы можете просто следовать их рекомендациям.
Меня не волнует мнение представителя, чтобы создать длинный ответ сегодня... поэтому я буду коротким.
Раньше я разбирался в split-dns и реализовывал его несколько раз, пока Эван и Марк не убедили меня в обратном. Честно говоря, это НЕ то, что это не может быть сделано... это возможно, и некоторые могут быть просто в порядке (несмотря на накладные расходы и проделанную работу).
2 года назад для меня возникли две специфические вещи, которые НЕ использовались:
- Как вы указали в своем вопросе, вы просто не можете позволить внутренним пользователям получить доступ к вашему внешнему веб-сайту только через доменное имя. Не спрашивайте, почему это было так важно, но у нас были внутренние пользователи, которые бы разозлились, если просто набрать в браузере только доменное имя без
wwwне будет открывать реальный веб-сайт, так как запись домена соответствует домену AD и не является универсальной для доступа кwwwи не может быть внутренне. - Проблемы с Exchange - Exchange AutoDiscover может не получить сертификаты и выдаст сообщение об ошибке. Это может происходить как внутри, так и снаружи. Это стало еще более очевидным, когда мы начали использовать "Внешние лесные почтовые ящики" в нашей организации Exchange, и они не увидели тот же внутренний DNS, что и мы.
Надеюсь, это поможет.