ITband.ru »Як не потрібно називати домени Active Directory

Вибір імені домена завдання нескладне, але як показує життя досить часто після запуску dcpromo ім'я домену генерується випадковим чином Вибір імені домена завдання нескладне, але як показує життя досить часто після запуску dcpromo ім'я домену генерується випадковим чином. Начебто і нічого страшного, домен працює, принтери друкують, 1С відкривається. Але на жаль є ряд ситуацій, коли генерація випадковим чином імені, якщо не вийде вам боком, то клопоту однозначно додасть. У цій невеликій замітці я спробую розповісти про те, як не варто називати ваші домени і чому. Інформація хоч і відома, але реальне життя показує, що помилки в іменуванні просто повальні. А оскільки процедура перейменування домену це ит-шное садо-мазо, краще все робити спочатку правильно.

1. Ситуація перша. Ім'я домену - domainname.local

Напевно найпоширеніший варіант це використання закінчення .local або будь-якого іншого домену першого рівня, що не використовується IANA. (А-ля .msk або .test або .loc і.т.д) Звідки це пішло зараз важко сказати, є кілька варіантів. Один говорить про те, що в 2000-му коли AD з'явилася на конференції в демонстрації доповідач зробив такий домен.
Ну і народ сприйняв це як заклик до дії. Друга гіпотеза, хоч і не виключає першу схиляється до того, що швидше за все MSFT сама написала явно рекомендацію в літературі, після чого .local і пішов в народ. Чим же поганий такий варіант?

Сценаріїв декілька, але я розповім і наболіле. Припустимо ви встановлюєте всередині організації Exchange Server, якому потрібні сертифікати для шифрування клієнтських підключень. Сертифікат хочеться від комерційного центру, все як у людей. Природно в сертифікаті повинні бути вказані всі імена сервера за якими сервер буде доступний. І якщо зовнішній домен належить нам і легко пройде валідацію, то внутрішній домен а-ля super-firma.moscow не існує і при спробі пояснити центрам сертифікації, що вам в SAN потрібно запхати FQDN - exchange.super-firma.moscow отримаєте відповідь:

It's not possible, we issue only certificates for real domain names.

На поточний момент запихати в SAN сертифіката всякі непристойні слова дозволяє Comodo Certificate Authority, що значно звужує вибір постачальника сертифікатів, та й гарантії, що вони будуть вирішувати це і далі немає.

2. Ситуація друга. Ім'я домена AD збігається з зовнішнім інтернет ім'ям домену.

Теж частий варіант, але при ньому проблеми з сертифікатами не буде. Зате виникають проблеми з дозволом імен. Виходить ситуація, коли зовнішні і внутрішні DNS сервера не пов'язані між собою, але при цьому обслуговують незв'язані зони з однаковими іменами. У такій ситуації кожен внутрішній сервер логічно вважає себе авторитативним для зони і при незнанні про яке-небудь хості авторитетно заявляє - НІ! Оскільки ви маєте якісь зовнішні ресурси, саме банальне веб-сайти, природно записи типу А додаються в зону на зовнішньому DNS сервері. Тепер коли внутрішній клієнт спробує дозволити ім'я зовнішнього ресурсу, його запит потрапить на внутрішній DNS сервер, (природно, це ж доменний клієнт) а той у відповідь "не знаю, немає такого і можеш не шукати", т.к бачить, що він авторитативні для цієї зони сервер.

Для вирішення цієї проблеми вам доведеться прописувати зовнішні записи в двох зонах, а це неминуче приведений до плутанини і додаткової рутині. Якщо вас це не лякає, то спробуйте при такому сценарії дозволити внутрішнім користувачам відкривати корпоративний сайт без префікса www. Загалом поганий варіант і не треба його використовувати.

Особливий привіт тим адміністраторам, які назвали свої внутрішні домени іменами чужих знаменитих публічних доменів. Думаю який геморой в такому випадку вам забезпечений пояснювати не потрібно.

3. Ситуація третя. Плоске ім'я домену складається з одного слова.

Якщо перші два варіанти ще можна пережити, то за плоскі імена доменів пора ввести адміністративне покарання. Single-label domain (однорівневий домен, SLD) - це домен, що містить тільки одну іменну складову. Звідки пішла манія їх використовувати, я не знаю, але вже давно офіційно визнано, що SLD домени не повинні використовуватися при побудові ІТ-інфраструктур.

При цьому дана інформація такий канадський баян, що залишається тільки дивуватися звідки SLD домени беруться. http://support.microsoft.com/kb/300684 .

Чим загрожує? Відсутністю підтримки з боку продуктів Microsoft такій конфігурації. Зі свіжого. Спробуйте встановити Exchange 2010 SP1 в домені з плоским ім'ям, отримаєте повідомлення про те, що така конфігурація більше не підтримується.

Як же правильно назвати домен?

Відповідь проста. Робити узгоджене простір імен. Тобто маючи домен itband.ru в реальному світі, домен Active Directory робити суб-доменом типу corp.itband.ru. При такому розкладі всі проблеми відпадають. І зовсім не обов'язково робити делегування DNS суб-домену на зовнішньому DNS сервері. Хоча якщо ви це зробите, можна домогтися дозволу імен в обидві сторони. (З внутрішньої мережі зовнішніх імен, з Internet внутрішніх імен)

Для тих, хто не подумав спочатку є "хороша" посилання: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx Приємних Вам ввечері за читанням даного твору.

MCP / MCT Ілля Рудь

Чим же поганий такий варіант?
Чим загрожує?
Як же правильно назвати домен?
IRC (Internet Relay Chat)