Вибір імені домена завдання нескладне, але як показує життя досить часто після запуску 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 Ілля Рудь