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? Ответы на эти и другие вопросы я постараюсь дать в настоящей статье.

Выбор 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, и за все это время ни разу не столкнулся с неполадками.

Это не означает, что DNS-сервер Windows 2000 не заслуживает внимания. В таких серверах реализованы удачные, хотя и нестандартные зоны, интегрированные с AD (AD-integrated zone). Зоны, интегрированные с AD, имеют две особенности: несколько ведущих машин в первичной зоне и безопасное динамическое обновление DNS (dynamic DNS, DDNS). Роль DDNS в Windows 2000 соответствует функциям WINS в NT 4.0: репозитария имен и IP-адресов компьютеров и центрального каталога типов серверов. Чтобы найти контроллер домена (DC) и зарегистрироваться в домене NT 4.0, рабочая станция обращается к WINS. Компьютер с Windows 2000 Professional, член домена AD, направляет запрос на поиск DC в DDNS. Затем сервер DDNS должен собрать информацию об именах и ролях машин в домене. Системы на базе Windows 2000 помогают DDNS выполнить эту задачу, регистрируя свои имена на сервере DDNS. Таким образом, машины Windows 2000, в сущности, представляются DDNS-серверу, пополняя его базу данных имен и адресов.

Но какому 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 (только безопасное обновление).

Использование серверов кэширования

Вспомним, как размещаются в intranet DNS-серверы для обслуживания пользователей. Многие DNS-серверы предназначены для хранения копий зональных файлов предприятия; это знает каждый администратор, которому приходилось устанавливать DNS-сервер. Но многие DNS-серверы не содержат зон и предназначены исключительно для преобразования имен Internet (какой IP-адрес соответствует имени www.microsoft.com?) или intranet (где находится ближайший DC в acme.com?). Такой DNS-сервер называется сервером кэширования (caching-only server). После того как образован беззональный DNS-сервер, указание на тип сервера кэширования содержится в журнале событий (событие с ID 708).

Достоинство сервера кэширования заключается, как видно из его названия, в возможности запоминать результаты предыдущих операций преобразования имен. Например, если кто-то из сотрудников вводит в браузере имя www.cnn.com, то браузер обращается к основному локальному DNS-серверу, чтобы узнать IP-адрес сервера www.cnn.com на DNS-сервере CNN.com. Основной локальный DNS-сервер обращается за этой информацией в Internet, что требует времени. Но второй сотрудник, запросивший на локальном DNS-сервере IP-адрес www.cnn.com, получит ответ почти мгновенно, так как сервер извлекает адрес из кэша, не обращаясь в Internet.

Однако в конечном итоге локальный DNS-сервер обратится к DNS-серверу CNN.com, чтобы выяснить, не изменился ли IP-адрес www.cnn.com. Повторное обращение необходимо, так как в ответе на первый запрос

содержится не только IP-адрес www.cnn.com, но и период времени, в течение которого данный адрес должен храниться в кэше локального DNS-сервера. Это время называется «время жизни» (Time to Live, TTL). TTL указывается в ответах на все запросы на разрешение имен. Появление очередного запроса после истечения TTL приводит к повторному обращению в Internet для преобразования имени.

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

Не вызывает сомнения, что кэширование преобразованных имен в DNS очень удобно. Если TTL домена CNN.com составляет два дня, то адрес можно хранить в течение этого срока, прежде чем локальному DNS-серверу кэширования придется вновь обратиться к DNS-серверу CNN.com.

К каким последствиям приведет добавление второго локального DNS-сервера кэширования? Назовем первый локальный DNS-сервер DNS1, а второй — DNS2. Информация, полученная DNS1, недоступна для DNS2. Например, если в DNS2 поступил запрос на IP-адрес www.cnn.com, то DNS2 должен обратиться за этой информацией на DNS-сервер CNN.com, даже если данный IP-адрес хранится в кэше DNS1. Иными словами, DNS2 и DNS1 не могут совместно использовать кэш.

Но если применить ретранслятор запросов, то серверы могут разделять кэш. Принцип работы ретранслятора запросов следующий: сначала назначается несколько локальных DNS-серверов кэширования для преобразования имен по запросам от рабочих станций и других серверов. Затем на отдельный сервер возлагаются функции своего рода DNS-сервера для DNS-серверов. В терминах DNS, этот сервер выполняет функцию ретрансляции запросов.

Получив запрос на преобразование имени, отсутствующего в кэше, локальный DNS-сервер кэширования не обращается в Internet, а передает запрос ретранслятору. Если ретранслятор — который расположен в той же локальной сети, что и локальный DNS-сервер кэширования, и может обмениваться с ним информацией на высокой скорости — располагает нужным адресом, то он быстро отвечает на поставленный вопрос. Если ретранслятор не дает ответа, то необходимая информация извлекается из Internet.

Предположим, что DNS1 обслуживает первого пользователя, обратившегося за IP-адресом для www.cnn.com. Не обнаружив ответа в кэше, DNS1 посылает запрос в ретранслятор. Ретранслятор также не располагает адресом, так как ранее никогда не получал такого запроса, поэтому обращается в Internet. После того как ретранслятор отыскивает IP-адрес для www.cnn.com, он записывает его в кэш, а затем пересылает информацию в DNS1.

Допустим, что второй пользователь, желающий получить IP-адрес для www.cnn.com, подключен к DNS2. Сервер DNS2 не может получить адрес из кэша, поэтому посылает запрос в ретранслятор. На этот раз ретранслятору известен IP-адрес для www.cnn.com, и он отвечает на запрос от DNS2 со скоростью работы локальной сети.

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

Зачем вводить лимит времени? Если ретранслятор перестанет работать, то DNS1 и DNS2 не смогут получить ответы на новые запросы преобразования имен. Данная ситуация разрешается с помощью тайм-аута. Если локальный DNS-сервер кэширования (DNS1 или DNS2) посылает запрос ретранслятору и не получает ответа в течение заранее определенного промежутка времени, то локальный сервер обращается в Internet и самостоятельно выполняет преобразование имени (как указано ниже, данная операция может привести к неприятным последствиям).

Разделенная DNS

Зоне DNS в домене AD свойственны две особенности. Во-первых, AD сохраняет в DNS очень много данных. Во-вторых, значительная часть этой информации носит конфиденциальный характер. В частности, в зоне домена AD хранятся имена и адреса контроллеров домена, и, по всей вероятности, администраторы пожелают скрыть их от посторонних глаз.

Один из способов повысить уровень защиты сети — создать две зоны DNS: открытую для внешнего мира и доступную только корпоративным пользователям. Некоторые специалисты называют такую структуру разделенной (split-brain) DNS. Она функционирует следующим образом.

Получив запрос на преобразование имени, основной DNS-сервер сначала обращается в кэш. Если имени в кэше нет, а DNS-сервер содержит зоны, то сервер пытается преобразовать имя, проверяя зоны. Сервер обращается к ретранслятору или в Internet лишь в том случае, если не может найти нужный адрес в кэше или в зонах. Главная особенность разделенной DNS заключается в том, что DNS-сервер больше доверяет информации из зон, чем данным, извлеченным из Internet.

В приведенном ниже примере показано, как организовать два раздельных набора данных. Пусть существует домен с именем acme.com. Несколько DNS-адресов в этом домене нужно сделать открытыми для внешнего мира — двух DNS-серверов (ns1.acme.com и ns2.acme.com), почтового сервера (mail.acme.com) и Web-сервера (www.acme.com). Таким образом, видимая извне зона acme.com узка и содержит примерно десять записей. Все они относятся к маршрутизируемым IP-адресам, доступным через Internet. Мы создали файл зоны и разместили его на двух видимых извне DNS-серверах, ns1.acme.com и ns2.acme.com (можно было бы обойтись без собственных DNS-серверов — многие фирмы просто передают эти файлы Internet-провайдерам). Адреса ns1.ac-me.com и ns2.acme.com хранятся в базе данных DNS-серверов провайдера Network Solutions, и любой сервер вне Acme — к которому может обращаться с запросом пользователь Internet — должен запросить у DNS-серверов Network Solutions информацию о местонахождении серверов acme.com. Следовательно, единственными серверами, видимыми извне, будут ns1.acme.com и ns2.acme.com.

Однако внутри Acme имеется intranet с немаршрутизируемыми адресами — возможно, сеть 10.x.x.x, в которой для соединения с Internet используется какой-нибудь механизм переназначения адресов портов. Любой внутренний пользователь Acme может инициировать сеанс связи с Internet, но посторонние пользователи из Internet не могут установить связь с внутренними адресами 10.x.x.x (ради простоты в данном примере переназначение адресов портов — единственный механизм защиты у Acme).

В intranet выделена группа DNS-серверов, выступающих в роли основных серверов для других компьютеров сети. Эти DNS-серверы используют DNS-серверы acme.com в качестве ретрансляторов, что позволяет пользователям корпоративной сети преобразовывать имена в IP-адреса и выходить в Internet. Внутренние DNS-серверы — не просто DNS-серверы кэширования; на них хранится копия файла зоны acme.com. Но эта зона — не та видимая извне зона acme.com, которая хранится на серверах ns1.acme.com и ns2.acme.com. На внутренних DNS-серверах хранится зона acme.com, построенная с помощью AD и DDNS. Если эта видимая изнутри зона acme.com представляет собой AD-интегрированную зону, то внутренние DNS-серверы являются контроллерами домена Windows 2000 для AD-домена acme.com.

Тем администраторам, которым прежде не приходилось организовывать разделенные структуры DNS, следует внимательно изучить эту схему. Ни одна из систем в intranet Acme не использует внешние DNS-серверы в качестве основных серверов преобразования DNS-имени — для этой цели служат DNS-серверы в корпоративной сети. На внутренних серверах хранятся копии зоны, названной acme.com. Но зона acme.com на внутренних серверах отличается от зоны acme.com, видимой извне (хотя предположительно зона на внутренних серверах включает те же записи, что и зона на внешних серверах, — записи, указывающие на Web и, вероятно, на почтовый сервер). Во внутренней зоне хранится информация, которую используют системы Windows 2000, для поиска контроллеров домена.

DNS-серверы intranet невозможно обнаружить или обратиться к ним из внешнего мира, так как DNS-серверы Network Solutions не знают о DNS-серверах корпоративной сети Acme. Поэтому пользователь, пытающийся преобразовать имя acme.com из Internet, никогда не выйдет на DNS-сервер intranet. Неудачной будет и попытка использовать извне внутренний DNS-сервер Acme, так как он имеет немаршрутизируемый IP-адрес.

Применение вспомогательных серверов для защиты серверов 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-домен.

Марк Минаси – редактор Windows NT Magazine, MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.