Работа с DNS — важнейшая часть планирования Active Directory (AD). Прежде чем организовать домен AD, необходимо установить DNS. Служба AD и создающая для нее основу служба DNS требуют более тщательного планирования, чем любой другой инструмент Microsoft. Действовать по принципу «сначала щелкни, а там видно будет» — верный способ навлечь на себя неприятности. Однако из-за ряда особенностей AD настроить DNS для работы с AD нелегко даже опытным администраторам, хорошо знакомым с DNS. В данной статье рассматриваются принципиальные условия, которые необходимо соблюдать при настройке DNS для работы с AD, а также полезные новые функции DNS, реализованные в Windows Server 2003.
Прежде чем создавать домен AD, требуется установить один или несколько DNS-серверов для размещения DNS-зоны с тем же именем. Следует обратить внимание на термины «домен» и «зона». Термин «домен» может иметь два значения. Можно говорить о DNS-домене с именем bigfirm.biz в смысле, не имеющем ничего общего с AD и любыми программами Microsoft. Но можно говорить об AD-домене с именем bigfirm.biz — такой домен не имеет большого отношения к DNS, зато тесно связан с безопасностью в программных системах Microsoft. Чтобы не путать DNS-домены с AD-доменами, я буду называть DNS-домен «зоной».
Предположим, что на DNS-сервере компании Bigfirm размещена зона bigfirm.biz. В зону входят Web-сервер и несколько почтовых серверов, и необходимо, чтобы заказчики могли иметь доступ к этим серверам. Но администраторы Bigfirm не хотят использовать данный DNS-сервер и размещенную на внешних машинах зону bigfirm.biz для реализации AD, так как в AD хранится конфиденциальная информация, которую опасно публиковать в Internet. Поэтому, как и большинство проектировщиков AD, администраторы Bigfirm формируют группу DNS-серверов, невидимых из общедоступной сети Internet, на которых размещается зона bigfirm.biz, отделенная от общедоступной зоны bigfirm.biz. Такой подход называется разделением (split-brain или split-horizon) DNS.
Основные сведения о разделенных зонах DNS
Организовать разделенную DNS довольно просто, и я рассказывал об этом в других статьях. Напомню коротко, что для организации разделенной DNS сначала нужно установить серверную службу DNS на нескольких серверах. Затем компании Bigfirm следует настроить конфигурацию каждой системы во внутренней сети (то есть сети, в которой необходимо отыскивать контроллеры домена AD), чтобы они могли получать информацию DNS от одного или нескольких внутренних серверов. Клиенты DNS внутри корпоративной сети никогда не должны запрашивать DNS-серверы в общедоступной Internet; в противном случае они никогда не смогут обнаружить контроллеров домена (DC). То же справедливо и для внутренних DNS-серверов: их следует настроить на преобразование имен только с использованием внутренних DNS-серверов. Хотя внутренние DNS-серверы обращаются друг к другу для преобразования имен, они могут преобразовывать имена Internet.
Bigfirm может назначить один из внутренних DNS-серверов первичным DNS-сервером для внутренней зоны bigfirm.biz и разрешить динамическое обновление этой зоны. Затем можно настроить все остальные DNS-серверы сети для работы в качестве вторичных DNS-серверов зоны bigfirm.biz; каждый из них получает экземпляры зоны bigfirm.biz с первичного сервера bigfirm.biz. Такой простой подход позволяет разместить разделенную DNS для одного домена AD.
Добавление зон, интегрированных с AD
Приведенное описание — недостаточно полное для многих администраторов, так как оно не охватывает зоны, интегрированные с AD. Использование первичных и вторичных DNS-серверов для данной зоны — стандартный способ применения DNS-серверов. Впервые этот метод был использован в широко распространенной серверной программе BIND DNS; аналогичный способ применяется и во встроенных DNS-серверах Windows 2000 Server и Windows 2003. Эта модель предусматривает наличие в зоне одного первичного сервера DNS и неограниченного числа вторичных. Любые изменения в зоне должны производиться на первичном DNS-сервере, который затем копирует измененные параметры на вторичные серверы. В терминах Windows 2000 этот подход можно назвать моделью с одним мастером, так как принимать изменения может только один ответственный за зону DNS сервер.
Модель с одним мастером — слабое звено архитектуры с первичным и вторичными DNS-серверами. В Windows 2003, Windows XP и 2000 используется динамическая служба DNS (DDNS), поэтому каждая рабочая станция и сервер должны перерегистрировать свои имя и адрес в зоне DNS каждый день в процессе начальной загрузки (это упрощенное представление: на самом деле процедуру перерегистрации запускают пять различных событий). В модели первичный/вторичный только первичный DNS-сервер зоны может принимать изменения для этой зоны. Если компания располагает несколькими тысячами машин, то в течение считанных минут после начала рабочего дня на первичный DNS-сервер могут обрушиться тысячи запросов на DNS-регистрацию.
В зонах DNS, интегрированных с AD, может быть не один, а несколько первичных DNS-серверов — информация о DNS-зоне хранится не в файле на DNS-сервере, а становится частью базы данных AD. Windows 2000 тиражирует базу данных AD на все DC домена, и каждый DC видит и даже может изменить информацию в DNS.
Кроме того, интеграция зоны DNS с AD повышает безопасность сети, так как регистрацию DDNS могут выполнить только члены домена. В простой первичной зоне DNS, принимающей динамическую регистрацию, любая машина может регистрировать DNS-записи. Поэтому теоретически любая посторонняя машина может регистрировать записи, выдавая себя за DC. Сам факт появления системы, выдающей себя за DC, не приведет к нарушению информационной безопасности сети, но такое положение нельзя считать нормальным — за этим может скрываться попытка кражи паролей. Однако в зоне, интегрированной с AD, посторонней машине гораздо труднее присвоить чужую роль. Прежде чем принять регистрацию DNS, интегрированные с AD серверы DNS проверяют, является ли регистрируемая машина членом домена.
Островная DNS
Зоны, интегрированные с AD, и разделенная DNS могут породить конфликт, известный под названием «островная DNS» (island DNS). В случае с островной DNS два или несколько DC выполняют роль DNS-серверов домена, и на них, как обычно, размещается зона, интегрированная с AD. Но каждый DC располагает своей информацией. Каждый DC регистрирует идентификационную информацию о своем экземпляре зоны DNS, но никогда не реплицирует эту информацию на другие DC/DNS-серверы (то есть серверы, которые играют двойную роль DC и DNS-серверов). Поэтому каждый DC/DNS-сервер считает себя единственным на планете.
Островная DNS возникает только в корневом домене леса, только если используются зоны, интегрированные с AD, применяется разделенная DNS (каждый DNS-сервер настроен на разрешение запросов DNS лишь у себя) и только если в корневом домене имеется более одного DC/DNS-сервера. Насколько мне известно, возникновение островной DNS возможно в DNS-серверах на базе Windows 2003 и Windows 2000.
Чтобы избежать появления островной DNS, следует изменить конфигурацию DC/DNS-сервера. Во-первых, нужно назначить одну систему DC/DNS «ведущим» DNS-сервером зоны. Этот сервер не будет настоящим мастером. Регистрацию DNS по-прежнему станут выполнять несколько мастеров, но я пользуюсь этим термином для простоты изложения. Ведущий DNS-сервер должен по-прежнему указывать на себя (поле Preferred DNS server в окне TCP/IP Properties этой системы должно содержать только собственный IP-адрес данного сервера). Поле Alternate DNS server остается пустым. Затем нужно настроить другие DNS-серверы таким образом, чтобы они использовали IP-адрес мастера в качестве основного DNS-сервера, а какой-нибудь другой DNS-сервер — в качестве альтернативного. За исключением мастер-сервера, никогда не следует настраивать систему на обращение к самой себе как основной или альтернативной.
Предположим, у нас имеется три контроллера с именами DC1, DC2 и DC3. Все три DC являются DNS-серверами, расположены в корневом домене леса и хранят информацию о зоне DNS данного домена в интегрированной с AD зоне. Произвольно назначив DC1 ведущим, я настроил DC1 таким образом, чтобы в его поле Preferred DNS server содержался IP-адрес DC1, и оставил поле Alternate DNS server пустым. Я вставил IP-адрес DC1 в поле Preferred DNS server контроллера DC2, а в поле Alternate DNS server контроллера DC2 указал IP-адрес DC3. В поле Preferred DNS server контроллера DC3 я ввел IP-адрес DC1, а в поле Alternate DNS server контроллера DC3 — IP-адрес DC2.
Рассмотрим еще два DC (MYDC1 и MYDC2), связи между которыми организованы по тому же принципу. Если произвольно выбрать MYDC1 в качестве мастера, то в поле Preferred DNS server контроллера MYDC1 следует указать IP-адрес MYDC1 и оставить поле Alternate DNS server пустым. В контроллере MYDC2 требуется указать IP-адрес MYDC1 в поле Preferred DNS server. Но что делать с полем Alternate DNS server контроллера MYDC2? Это поле нужно оставить пустым.
Добавление доменов
Предположим, что в bigfirm.biz необходимо иметь два AD-домена — исходный домен bigfirm.biz и домен с именем bigfirm.com. Как в этом случае организовать разделенную DNS? Компании Bigfirm достаточно создать первичную зону с именем bigfirm.com на одном из внутренних DNS-серверов. Все остальные внутренние DNS-серверы компании следует сделать вторичными DNS-серверами зоны bigfirm.com. Таким образом, в распоряжении компании будет вся инфраструктура, необходимая для двухдоменного леса AD.
Если Bigfirm использует зоны, интегрированные с AD, то очевидный следующий шаг — интегрировать с AD как зону bigfirm.biz, так и bigfirm.com и установить DNS на некоторых DC. В результате DNS-серверы каждого домена должны видеть зоны друг друга. Однако данный метод не срабатывает из-за странной особенности зон, интегрированных с AD. Данные о зоне, интегрированной с AD, направляются только на контроллеры домена этой зоны — DC/DNS-серверам bigfirm.com будут видны только данные bigfirm.com. Это ограничение в Windows 2003 можно обойти, но в многодоменные леса на базе Windows 2000 придется внести некоторые изменения, чтобы обеспечить работу DNS, интегрированной с AD. Все DNS-серверы bigfirm.biz необходимо настроить в качестве вторичных DNS-серверов для bigfirm.com, а все DNS-серверы bigfirm.com — в качестве вторичных DNS-серверов для bigfirm.biz. Внутри доменов можно по-прежнему использовать зоны, интегрированные с AD, но в каждом домене должна содержаться вся необходимая информация для обнаружения контроллеров bigfirm.com, и наоборот.
При использовании DNS-серверов на базе Windows 2003 у администраторов Bigfirm будет более широкий выбор. Эти возможности мы рассмотрим в следующей статье.
Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com