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

Сподіваємось , всі ми знаємо, що таке рекомендації щодо іменування лісу Active Directory , і вони досить прості. А саме, це можна підсумувати в одному реченні.

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

Є надзвичайно вагомі причини уникати використання "фальшивих" tlds або однодоменних доменних імен , але мені важко знайти аналогічні переконливі причини, щоб уникнути використання кореневого домену ( hopelessn00b.com) як мого доменного імені та використовувати піддомен, такий як corp.hopelessn00b.comзамість цього . Дійсно, єдине обґрунтування, яке я можу знайти, - це те, що для доступу до зовнішнього веб-сайту потрібен запис A nameDNS і введення www.браузера перед назвою веб-сайту у веб-переглядачі, що досить "мех", наскільки це стосується проблем.

Отже, чого я пропускаю? Чому так набагато краще використовувати ad.hopelessn00b.comмоє ім'я лісу Active Directory hopelessn00b.com?

Для того, щоб записати, справді мій роботодавець потребує переконливості - людина-начальник повертається назад, і після того, як я дав мені змогу створити новий ліс AD, названий corp.hopelessn00b'semployer.comдля нашої внутрішньої мережі, він хоче дотримуватися AD лісу з назвою hopelessn00b'semployer.com( те саме, що і наш зовнішньо зареєстрований домен). Я сподіваюсь, що я можу отримати певну вагому причину або причини, що найкраща практика - кращий варіант, тому можу переконати його в цьому ... тому що це здається легше, ніж скасувати відмову і / або знайти нову роботу, принаймні для момент. Зараз "найкращі практики Microsoft" та внутрішній доступ до загальнодоступного веб-сайту нашої компанії, схоже, не врізають це, і я дуже , дуже , дуже сподіваюся, що хтось тут має щось більш переконливе.

Стільки респ не було. Приходьте до мене дорогоцінний.

Гаразд, так що Microsoft досить добре зафіксував, що ви не повинні використовувати розділений горизонт або складений 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. Перед іменем веб-сайту у браузері" не відповідає дійсності.

Це означає, що вам потрібно зберігати копію всіх своїх публічних записів на серверах AD DNS, що може спричинити проблеми, особливо якщо ви не зробите це належним чином - пропустіть деякі тощо. Якщо хтось хоче потрапити на ftp.company. com, але ви забули створити псевдонім у внутрішній DNS (або не автоматизували його належним чином), власні люди взагалі не можуть потрапити на загальнодоступний FTP-сайт.

Це досить добре зрозуміло у питанні, з яким ви пов’язані: Windows Active Directory називає кращі практики?

Якщо підтримка декількох копій ваших DNS-зон - це легка проблема, яку ви зможете вирішити правильно, назавжди, тоді я припускаю, що ви можете робити все, що завгодно. Поки MS не змінить щось, що порушує її. Ви можете просто слідувати їх рекомендаціям.

Мені недостатньо хвилюється представник, щоб створити довгу відповідь сьогодні ... тому я буду тримати його коротко.

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

Багато років тому для мене з’явилися дві конкретні речі, які тверділи НЕ використовуючи:

1. Як ви вказали у своєму запитанні, ви просто не можете дозволити внутрішнім користувачам зайти на ваш зовнішній веб-сайт за допомогою лише доменного імені. Не запитуйте, чому це було такою великою справою, але у нас були внутрішні користувачі, які зрозуміли, що введення простого доменного імені в браузер без того wwwне призведе до фактичного веб-сайту, оскільки запис домену відповідає домену AD і не все для того, щоб дістатися до wwwта НЕ МОЖЕ бути внутрішньо
2. Проблеми з обміном - Exchange AutoDiscover не може отримати сертифікати, і сповістить про помилку. Це може статися як внутрішньо, так і зовні. Це стало ще більш очевидним, коли ми почали мати "Зовнішні лісові поштові скриньки" на нашому Exchange Org, і вони не бачили того самого внутрішнього DNS, як у нас.

Сподіваюся, що це допомагає.