DNS та Active Directory

Active Directory (AD) - чудова технологія (особливо якщо врахувати, що перед нами - версія 1.0), якій в останні два роки приділялася велика увага в літературі по Windows 2000. Однак для коректної роботи Active Directory необхідний власний каталог: список серверів та робочих станцій, відомий як DNS. Перш ніж розпочати планування AD, потрібно підготувати DNS, інакше навіть бездоганно організована AD функціонуватиме незадовільно.

Працюючи з Windows NT 4.0, більшість адміністраторів познайомилися з основними елементами DNS – зонами DNS, записами SOA (System Object Access – доступ до системних об'єктів), NS (Name Server – сервер імен) та MX (mail exchanger – система поштового обміну), A (хост), первинними та вторинними серверами тощо — і, ймовірно, навіть будували простий DNS-сервер. Але для організації надійної структури DNS, що повністю відповідає вимогам AD, необхідні додаткові знання. Наприклад, чи слід використовувати DNS-сервер, що постачається у складі Windows 2000, або DNS-сервер незалежного постачальника, такий, як широко застосовувана UNIX і Linux програма BIND? Де розмістити ретранслятори запитів (forwarder) та допоміжні (slave) DNS-сервери – і взагалі, що означають ці терміни? Що таке розділена (split-brain) DNS і як поєднати AD з існуючою інфраструктурою DNS? Відповіді на ці та інші питання я намагатимусь дати у цій статті.

Не слід вважати необачним кроком рішення поєднати AD з DNS-сервером BIND (або Lucent QIP фірми Lucent Technologies або іншим продуктом незалежної компанії). BIND цілком підходить для роботи з AD і застосовується для цього з часу появи Windows 2000.

Щоб переконатися у сумісності AD таBIND, я одного разу присвятив цілий день тому, щоб розформувати тридоменний ліс AD і знову побудувати його, не використовуючи DNS-сервери Microsoft. Я замінив їх системою Linux-Mandrake 7.1 фірми Mandrake-Soft і версією BIND, яка була на той час. Ліс AD був побудований бездоганно і навіть трохи швидше, ніж за допомогою DNS-сервера на базі Windows 2000. Після цього протягом декількох місяців я використовував структуру DNS на базі BIND разом з AD, і за цей час жодного разу не зіткнувся з неполадками.

Але якому DDNS-серверу надсилають інформацію про себе Windows 2000? У стандартній системі DDNS, наприклад на базі комп'ютера, що працює з BIND або DDNS-сервером Windows 2000 у режимі первинної зони (замість режиму інтеграції з AD), прийняти реєстрацію може лише первинний сервер DDNS. Інтернаціональна компанія може мати тисячі машин по всьому світу, які щоранку виконують операцію перереєстрації: всі вони повинні перереєструватися на одному комп'ютері — єдиному, уповноваженому проводити реєстрацію. Навпаки, в інтегрованій з AD зоні будь-які або всі контролери можуть бути наділені функціями первинних серверів DDNS і виконувати реєстрацію. Машини можуть реєструвати свої DNS-імена на локальних контролерах, зменшуючи трафік повільними мережами WAN.

Реєстрація критична лише для серверів та контролерів домену. Тому проблему реєстрації через WAN можна вирішити інакше, скасувавши реєстрацію машин із Windows 2000 Pro. Цей режим можна встановити на закладці DNS сторінки властивостей TCP/IP Advanced Properties. Інша відмінність DDNS від WINS полягає в тому, що термін реєстрації в DDNS не закінчується через кілька днів - за замовчуванням, реєстрація DDNS в зоні DDNS не має терміну закінчення. Тому в DDNS зберігається запис машини, яка у минуломузареєструвалася хоча б одного разу, навіть якщо машина не може перереєструватися щодня.

Ще одна корисна функція AD-інтегрованих зон – захищена реєстрація DDNS. Якщо зона DDNS за замовчуванням організована на DNS-сервері BIND або Windows 2000, зареєструвати машину в цій зоні може будь-який користувач, який має можливість встановити з'єднання з цим сервером. BIND дозволяє заборонити реєстрацію машин, що знаходяться поза певними підмережами: якщо на BIND-сервері складено реєстраційний список підмереж, сервер ігноруватиме всі інші комп'ютери. В AD-інтегрованій зоні передбачено інший механізм обмеження реєстрації DDNS: попередньою умовою може бути реєстрація машини в домені AD. Реалізувати даний підхід трохи простіше, ніж метод BIND, — достатньо клацнути на закладці General сторінки Properties зони, а потім на списку Allow dynamic updates, що розкривається? (дозволити динамічне оновлення?) і вибрати Only secure updates (тільки безпечне оновлення).

Використання серверів кешування

Централізований кеш із ретранслятором запитів

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

Щоб призначити DNS-сервер ретранслятором для іншого DNS-сервера, достатньо відкрити оснастку DNS консолі керування Microsoft Mana-gement Console (MMC) і клацнути правою кнопкою миші на піктограмі, що представляє DNS-сервервиконуватиме ретрансляцію. Вибравши Properties, перейдіть до закладки Forwarders, показаної на Екрані 1. На закладці Forwarders можна призначити один або кілька ретрансляторів і вказати ліміт часу.

Екран 1. Закладка Forwarders оснащення DNS консолі MMC.

Навіщо вводити ліміт часу? Якщо ретранслятор перестане працювати, DNS1 та DNS2 не зможуть отримати відповіді на нові запити перетворення імен. Ця ситуація дозволяється за допомогою тайм-ауту. Якщо локальний DNS-сервер кешування (DNS1 або DNS2) надсилає запит ретранслятору і не отримує відповіді протягом заздалегідь визначеного проміжку часу, то локальний сервер звертається до Internetу і самостійно виконує перетворення імені (як зазначено нижче, ця операція може призвести до неприємних наслідків).

Один із способів підвищити рівень захисту мережі – створити дві зони DNS: відкриту для зовнішнього світу та доступну лише корпоративним користувачам. Деякі спеціалісти називають таку структуру розділеної (split-brain) DNS. Вона функціонує так.

Тим адміністраторам, яким раніше не доводилося організовувати розділені структури DNS, слід уважно вивчити цю схему. Жодна із систем в intranet Acme не використовує зовнішні DNS-сервери як основні сервери перетворення DNS-імені - для цієї мети служать DNS-сервери в корпоративній мережі. На внутрішніх серверах зберігаються копії зони acme.com. Але зона acme.com на внутрішніх серверах відрізняється від зони acme.com, видимої ззовні (хоча, ймовірно, зона на внутрішніх серверах включає ті ж записи, що і зона на зовнішніх серверах, — записи, що вказують на Web і, ймовірно, на поштовий сервер) . У внутрішній зоні зберігається інформація, яку використовують системи Windows2000, для пошуку контролерів домену.

Застосування допоміжних серверів для захисту серверів intranet

Перш ніж закінчити опис прикладу з Acme, я хочу сказати кілька слів про загрозу безпеці. Як згадувалося, DNS-сервери intranet використовують зовнішні DNS-сервери як ретрансляторів запитів. Але якщо ретранслятор не відповідає на запит про перетворення імені досить швидко, DNS-сервер intranet намагається знайти відповідь на DNS-серверах Internet. На думку фахівців з безпеки, ця операція пробиває пролом у системі захисту. DNS-сервер intranet може просто встановити з'єднання з комп'ютером, який видає себе за DNS-сервер. Зв'язок DNS-сервера корпоративної мережі з помилковим DNS-сервером може стати джерелом різних неприємностей.

Щоб уникнути небезпечних контактів із зовнішнім світом, можна заборонити серверам intranet робити самостійні спроби перетворення імен у разі мовчання зовнішніх DNS-серверів. Для конфігурування внутрішнього сервера слід перейти до закладки Forwarders оснастки DNS у MMC та встановити прапорець Do not use recursion. В результаті в розпорядженні адміністратора виявиться сервер, який називається Micro-soft допоміжним (slave).

Узгодження з існуючою структурою DNS

Як бути, якщо компанія Acme вже має структуру DNS — можливо, кілька комп'ютерів з операційною системою, яка відрізняється від Windows 2000, на яких люди працювали зі структурою DNS протягом багатьох років, не знаючи проблем, пов'язаних із Windows 2000 і NT? Навряд чи їм сподобається, що AD розміщує у зонах таку кількість інформації. Існуюча інфраструктура DNS Acme може бути несумісною з DDNS або документом RFC 2782 SRV RRs (service resource records - записи службових ресурсів) робочої групи IETF і непридатною дляроботи з AD. Що робити, якщо інфраструктура погано узгоджується з AD?

Найпростіший вихід - побудувати піддомен. Замість того, щоб присвоювати домену AD таке ж ім'я, як у домену верхнього рівня (Top-Level Do-main, TLD) організації, наприклад acme.com, можна створити піддомен з таким ім'ям, як win2k.acme.com або ds.acme .com де ds — скорочення від directory service (служба каталогів). Перевага цього підходу полягає в тому, що він не має сильного впливу на зону TLD. Для створення дочірнього домену, наприклад ds.ac-me.com, acme.com потребує лише кілька записів у файлі зони acme.com: записи NS і A для кожного DNS-сервера в піддомені. Запис NS вказує на систему Windows 2000, яка виконує роль DNS-сервера для піддомену ds.acme.com.

В цілому очевидно, що для коректної роботи AD необхідний добрий фундамент DNS. Але методи проектування DNS не такі вже й складні, вони просто в новинку більшості адміністраторів. Використовуючи рекомендації цієї статті, можна успішно побудувати надійний AD-домен.